General
Due to the flash memory industry's rapid pace of development, the size of flash memory chips that can be obtained is increasing rapidly. For example, while we may see 128M flash memory manufactured today at a certain price point, next year we may see the same price buys 256M flash chip. Even more importantly, not only does capacity goes up for a given price, but availability of the older generation chip will be scarce as all manufacturer move on to the next capacity level. Thus it may actually cost more next year to buy a large batch of 128M chips than the 256M chip, if they are available at all. This is a bit counterintuitive, but anyone having to buy old RAM for an old computer can testify to this market effect.
The impact is that, depending on when a run of Talking Book is being manufactured, a run of Talking Book may well have much more memory than the previous run of Talking Book. This is both a benefit, as it can store more content, as well as a challenge to the design of the device. It's important to think about the scalability of many aspect of Talking Book's design, whether it is storage, navigation, or transfer. For example, while a simple seletion UI for content modules may work fine for a small number of content modules (e.g. 15-30 modules), will it still function well for a much larger set of modules?
Storage Size and Form
Storage Type
User content and system content (e.g. System Audio Files) will be stored in a replaceable SD card stored near the batteries. We need investigate whether standard SD, mini SD, or more likely due to cell phones, micro SD cards are the cheapest and most likely to be available for the next five years. Cost should be the primary driver for this version (future versions may have a bias towards micro SD cards).
Size
Based on the General discussion above, the device requires the cheapest SD card available over 32 MB. We expect that the cheapest SD card available during our initial manufacturing run will be closer to 256 or 512 MB. So, price is our priority.
Content and System Storage
User Content Storage
- Since the same card will include system storage (e.g. System Audio Files), the user content must be grouped within its own directory.
- Within the user content directory, a separate directory will contain all audio files comprising the content module, possibly within another hierarchy of directories. At the top level of each content module directory will be found the content's metadata, as compiled down from the set of elements represented in elements-package.
System Storage
- The primary use of system storage is "System Audio Files", which are recorded voice and sound prompts and messages.
- SAFs are all spoken in the same language.
- In Version 1, only one language can be loaded on single device at one time.
- SAFs can be swapped out as one package at a kiosk or content authoring product. The kiosk product will need to specify how a user discovers what other SAF languages are available on a kiosk and what process is needed to change out the SAF set. Ideally, these SAF files just appear like any other set of files when the device is connected to a laptop and viewed as a USB drive.
- SAFs come in pairs, a brief and verbose version. One of the user configuration options will allow the user to set their device to "not talk so much". We may also want the system to prompt for this to be set after a specified number of content modules are loaded (implying a level of user experience).
- The SAFs are simply a series of audio files that make up the system module. They also need a system metadata file that is a special case of the standard metadata used for user content. This combination should make up a large portion of the system menus, selection procedure, and navigation defaults.
