Month: כ״ה באב ה׳תשע״ז (August 17, 2017)

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 }