Audio Files

Handling audio files is another critical technology that we need to master for our Tikkun app. Our app must support user creation of audio content, and subsequent storing and sharing of that content. The audio files must be compatible with both Android and iOS devices, which is best accomplished by using the AAC codec with an MPEG-4 container format. We have started by first adding an audio recording and playback feature to our apps. Next, we will be using our Google Drive file storage and sharing code to store and share audio recordings.

Once we have worked out all the details for handling audio files, we will be ready to: (1) design the user interface controls for creating, sharing and playing audio files, and (2) develop our own file format for the study materials that users will create, save and share. These two work areas are intertwined. When a user creates a recording of a Torah passage (or of any other content included in the app), we want to capture not just the recording, but also the Torah passage (or other content) that was the basis of the recording, as well as metadata such as the date/time of the recording, who created it, and perhaps other relevant information such as the date of the Shabbat or other occasion for which the reading is being prepared, or notes about specific parts of the reading that need special attention. The additional data stored with a recording will provide for a richer user experience. For example, a user who prepared a reading once before would be able to search for that reading and find the information about it when preparing again to do that reading at a future date. Or a tutor could organize a collection of study materials for easy sharing with students. We will need to think about how to flexibly add metadata to recordings, without excessively burdening users with data input.

{ Comments are closed }

Storing Application Data

As we design our Tikkun app, we are thinking about all of the content that will be user-generated. In the simplest situation, user-generated content will be stored on the user’s device, to be accessed there as needed. Today, however, it is very common to have both a phone and a tablet, and also to upgrade to a new device every few years. In those cases, users will want to seamlessly continue their studies via the app on another device. The app will support this by storing their content on Google Drive as well as on their device. In terms of data privacy, Google Drive includes a special hidden folder that can only be accessed by the app that is used to create the data. When a user signs in to Google Drive, our app will save or sync the user’s data on the device with the user’s data in the hidden folder on Google Drive. It will do this automatically over unmetered Internet connections, and also when the user explicitly requests to sync. This will ensure that the user’s data is available within the app whenever and wherever the user needs it. And this is all cross-platform: if you have both an Android and an iOS device (as I do), it will all just work.

To share content with another user, the data will need to be present in the sharer’s “My Drive” area of Google Drive. The app will handle this, and make use of Google Drive’s sharing mechanisms to handle the request. The app will, on initial set-up, create a folder in the user’s “My Drive” to store all of the app’s data which is being shared. The user who is receiving the shared content will be able to access it within their copy of the app, and will also see it in the “Shared with me” folder in their Google Drive.

With today’s concerns about data security, we believe that use of Google Drive for sharing and syncing is the best solution at no additonal cost. This FAQ page from Google answers various questions about what Google does to protect data in its cloud services, like Google Drive.

We are always happy to hear from you. Write to me directly at marsha@zigzagworld.com

{ Comments are closed }

Sheva Na / Qamats Qatan

In addition to laying out the Torah text according to a standard set of columns, line breaks and internal breaks, and accurately displaying all of the vowels and trop (cantillation marks), we also want to distinguish between the two different pronunciations of the sheva and kamatz vowels. A sheva can either be a sheva na (moving sheva) or a sheva nach (resting sheva). The sheva na is pronounced as a short “e”, while the sheva nach is not pronounced at all. A qamats can either be a qamats qatan (small qamatz) or a qamatz gadol (big qamatz). The qamats qatan is pronounced as the “o” in boring while the qamats gadol is pronounced as the “a” in father. To support a Torah reader’s accuracy, it is very helpful if the study text that the reader is using visually distinguishes among these forms.

As you probably know, there is no single standard way to display these different sheva and qamats forms, and many texts do not concern themselves with doing so at all. Also, even those Hebrew fonts that include vowels and cantillation marks often do not support additional sheva and qamats forms, either. Today, most fonts that are being developed are Unicode fonts; Unicode is now the standard for representing and handling text in the world’s many languages and writing systems. In 2005, Unicode added the qamats qatan as a distinct character, as well as three other Biblical Hebrew characters (lower dot, nun hafukha, and atnah hafukh). Because the qamats qatan is now part of the standard, it is being supported in more fonts, and in many fonts is shown as a qamats gadol but with a longer and perhaps modified vertical stem. However, the sheva na is not a separate Unicode character, so it is sometimes indicated as a bolder, bigger sheva nach or alternately by a mark of some sort above the letter it serves. There are many who would like to see the sheva na added to Unicode, to allow for standardization. For example, see this proposal from last year.

Since we are doing our own font development, we have included both the qamats qatan and sheva na in our Traditional Hebrew font. Here is how we display them:

In our tikkun app, we plan to include the sheva na and qamats qatan in all of the Torah text initially, and will add that information to other parts of our library of texts as we go along.

{ Comments are closed }

User Interface / Sharing

We have now begun to design and implement the first elements of the user interface for the functions related to sharing content between users. As I have written about earlier, we are integrating Google Drive services into our iOS and Android apps, allowing users to keep their content in their own personal Google Drive accounts. They will then be able to share their content with others through our apps. We developed and tested the protocols for storing and retrieving Google Drive files, and are now working on the user interface elements for signing in and out of Google Drive. As usual, things work differently on iOS and Android. We also found that various built-in user interface elements behave differently on iPhones and iPads. So, as we have done many times before, we are writing custom code to provide a consistent user interface across the various platforms we want to support.

We currently have something acceptable working on iPhones and iPads, and have developed an Android equivalent. Once we have the sign in/out done, we can move on to the design for how to display and interact with a list of the user’s files.

{ Comments are closed }

Yemenite Traditions

As I was reading about various b’nai mitzvah practices and customs (there are lots of links out there), I took an interesting detour and learned a bit about Yemenite Torah reading traditions. I thought I would share some of what I learned this week.

At the Mechon Mamre web site, I read that “Yemenite Jews always allowed even children of five or six to take an aliyah.” And the Wikipedia article  on Yemenite Jews adds that “Children under the age of Bar Mitzvah are often given the sixth aliyah. Each verse of the Torah read in Hebrew is followed by the Aramaic translation, usually chanted by a child. Both the sixth aliyah and the Targum have a simplified melody, distinct from the general Torah melody used for the other aliyot.” So Torah reading (leining) was taught from a very young age. The article also notes that “In the Yemenite tradition each person called to the Torah scroll for an aliyah reads for himself.”

I also came across an article by Ephraim Stulberg on the division of aliyot in the weekly parashiyot. He references some research that indicates that the aliyah divisions did not become standardized until some time in the eighteenth century, and that the Yemenite community has its own division that differs in places from the division we see in most books today. I have looked for a table or listing of the Yemenite aliyah divisions, but so far have not yet found that information. Relating this to the Tikkun app that we are developing, this does bring up the need to support the user in selecting any range of verses as a reading to practice; this flexibility will allow the app to serve any user’s tradition.

{ Comments are closed }

Google Drive Integration

As I wrote a few weeks ago, we were working on integrating Google Drive into our Tikkun app. We had all of the key capabilities working for the Android version of the app, and were next diving into doing the same for iOS. Since we are relatively new to iOS and Swift programming, we are always on a learning curve as we start the next part of the project there. And, of course, the way that Android/Java accesses Google Drive differs significantly from the way that iOS/Swift does.

In particular, although calls to Google Drive occur asynchronously, they are handled in Android/Java in a way that basically results in things happening in order, without having to do any special programming. In iOS/Swift, the asynchronous nature of the interactions must be accounted for by the programmer. This led to learning how to use PromiseKit, a third-party Swift library for simplifying asynchronous code.

We are almost done now with bringing the iOS app’s functionality up to the same level as the we already had in the Android app. Next up: designing how user files should be represented in the app, and then how to arrange the user interface to simplify the sharing of files.

{ Comments are closed }

B’nai Mitzvah Tutors & Students

B’nai Mitzvah tutors have a lot of material to cover with their students. They usually work with students for at least six months and often up to a year, typically meeting once per week. The student is expected to practice the weekly lesson diligently, but a week is a long time for a student, and it can be difficult to practice consistently. So we feel that making it easier for students to stay current with the required level of practice should be a key goal of the app we are designing.

How can this be achieved? We have several ideas. First, we would like to make it easy for the student and tutor to check in with each other during the week between lessons, without this becoming burdensome. Tutors often create recordings for students to practice from, and we would like for them to be able to do this directly in the app; tutors would share recordings with their students through the students’ own instances of the app on their phones or tablets. The students would then be able to listen to these recordings wherever they might be, record their own practices of the required material using the app, and then share those practice recordings back with the tutor. The tutor could check for new recordings from their students each day, and contact a student or a student’s family with a friendly reminder to practice if needed.

Second, as the tutor listens to the shared practice recordings from students, the tutor will be able to hear whether the student is on track, or whether the student needs some additional pointers, without waiting until the next meeting. The tutor could, as needed, make another recording for or just send a message to the student to reinforce the lesson. Again, these interactions would happen through the app in a simple way, allowing the tutor and the student to interact between tutoring sessions. Another possibility would be to add a notifications feature to the app that would alert a student if they had not practiced on a day where they should have done so.

As we move forward in the design of the app, we will be looking at which features will best assist students in being regular about their practice between lessons, as well as features that will enhance communication between students and tutors.

{ Comments are closed }

Leining (Torah reading)

We are building a Tikkun app to help Torah readers. To make it worth using, it needs to support the ways that Torah readers (leiners) like to study. I found a good discussion about how leiners practice at the judaism.stackexchange.com website. In case you are not familiar with it, this website (also called “mi yodeya”) is a very interesting discussion group for all Judaism-related topics.

Here are some of the recommendations from that discussion:

Chunking: Break the reading up into chunks, and master one chunk at a time. The size of the chunks depends on the reader’s skill level, the section being read, and perhaps other factors.

Understand Hebrew grammar and vocabulary: The more that the reader knows, the easier it will be to get the vowels correct.

Understand the trop system: Knowing the trop patterns and how they are typically used simplifies memorization.

Record/listen: Recording yourself (after you have practiced for a while), and then listening to yourself, can help identify tricky problems.

Schedule: Set up a practice schedule and stick to it.

As we look at what features to build into the app, we will be thinking about how to support as many of these approaches as we can, in addition to the file sharing features that we have been working on to support tutors and their students.

{ Comments are closed }

Deeper into Google Drive

This week I want to update you on our efforts in integrating Google Drive into our Tikkun app. As I wrote last month, we decided that Google Drive provided the best solution at present for giving iOS and Android users a way to share content with each other directly through our app. It will also give users a way to sync their own content and app preferences across multiple devices. In order to make sharing and syncing “just work” for our app, we needed to get a deep understanding of how Google Drive operates, and then how to program the desired functionality. So we have been doing a lot of reading and experimenting, learning how to securely log in and out of Google Drive, create, find or delete a particular folder or file, how to use our own custom file types, and so on. (For those with a technical background, we are using the Google Drive REST API.) We have been able to log in and out of Google Drive on both the iOS and Android versions of our app. We have so far only tested out the various file and folder operations on Android. We will soon move on to doing the same operations of iOS.

Another critical aspect of integrating Google Drive into our app is handling any error conditions that might occur. In particular, the app will need to respond reasonably if a file or folder that is requested is not available. This could be because the item was deleted, or because there is no network connection. Further, if a network connection is metered (i.e., it uses data on a data plan), the app should not make that connection without the explicit permission from the user.

Once we have the level of control that we need in both iOS and Android, we will start looking at how to present information about the user’s content on various sizes of screens. We also need to refine exactly what data we need to store for the user, and how best to organize it. User data management is at the core of what will make the app really useful, and it will, undoubtedly, take some time to get it right.

{ Comments are closed }

Unusual Letter Forms in Tanach

As I wrote about in my previous blog post, one of the reasons that we are developing our own STaM fonts is to better handle the various unusual letter forms in Tanach. Examples include the enlarged bet that begins the Torah, the enlarged ayin in the word שמע, the small alef in the word ויקרא, and the inverted nuns in Numbers 35. It would, of course, be a lot of work for me to research all of these unusual letter forms, were it not for a number of very thorough papers that have been published on the subject. So if you are interested in the subject, here are the links to resources that I have been using:

Typographic details in the Hebrew Bible (Andries E. Brouwer): This paper collects examples from many different sources, and provides extensive, categorized lists of unusual letter forms.

Typesetting the Holy Bible in Hebrew, with TEX (Yannis Haralambous): This paper is concerned with typesetting Biblical text, and provides lists of typographical oddities and how to typeset them using the TEX system.

Also, this chart list all of the unusual letter forms just in Torah: טבלת השינויים בספר תורה (הראל לוי)‏‏

{ Comments are closed }