Device Features



This page describes the various device contexts, which affect the functionality triggered by a button action.

System Module Contexts

Contexts define the behavior of keys in specific locations. The Select Context will be active in the Home Location and many others, as it will be an often used keypad profile, i.e. Context. The Home Location is the location the user is taken to when he/she presses the Home Key, or when the device is turned on. This location uses the Select Context for key behaviors.


Select is the default context, it is active when the device is turned on. It is a menuing and navigation interface that allows selection of content modules for playback or any one out of a number of options from the main menu. See selection for details.

Edit My Categories

This allows the user to add or delete a category, which is used to organize their content modules.

Share (previously called Copy)

  • As long as the device-to-device cable is connected, the devices are in share context.
  • To go back to single user/device context, the device cable needs to be physically disconnected.

See d2d-copy and future kiosk specs on copying to/from the device.


The record context does not refer to the behavior of keys once record mode is activated and related options become available for navigation and selection. The record context refers to the behavior of keys when the device is actually recording. See record for details.

Set Time and Date


Set Reminder

This is effectively an alarm application that allows user to set reminders for every day, every given weekday, or every year on a given day.

Record my Name


Content Module Contexts

Each content module can create many adjacent and nested contexts (called "containers" in the contentschema spec) that affect operation of the buttons other than those that the System Module (or maybe the "device package") does not allow to be overridden.



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).


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.

Selection and Navigation

Content Selection

Status of this Section

  • Semi-stable Draft


The content selection interface, which includes the Home Location, is best described as a pair of columns, Column A and Column B.

The Home Location on the device will be Column A, which will contain a list
of Content Modules. Once the user presses the right arrow or the Select
button on one of the titles, he/she is taken to column B where a list of
audio segments that belong to the selected Content Module is displayed. If
the user pressed Play when at Column A, the device would simply start
playback at the beginning of the Content Module selected or, if the Content
Module was played in the past, the device would begin playing at the
location the user stopped the last time that module was heard.

All Content Modules are shown on Column A in the order they were downloaded
or saved to the device. The order is reverse chronological with most recent
at the top of the list.

When the user taps Home, he/she is taken to Column A, the same location the
user is placed at when the device is turned on. When the user holds Home,
he/she is told:

"Tap Play for previous Content Module, up or down arrow to choose from

Non-verbose: "Home to switch or arrows for categories"

The non-verbose version of voice prompts does not have to be extremely brief
since the user can always interrupt prompts by just pressing the desired

Categories are simply tags that can be associated with Content Modules.
There are user and factory-defined tags and they are both treated and
displayed equally. They are shown when Home is held and up or down arrow
keys are pressed. Categories are displayed in the order they are created in
reverse chronological order from top to bottom just like Content Modules on
column A, i.e. at the Home Location. For this initial version we will only
have a Category called "All". Once category creation and assigning is
described and programmed, we wil continue to have "All" as an option but
will also be able to display by any of the other categories.


  • Note that this page has been substantially updated. (Cliff pasted in the text from a Fernando email.)
  • Note that I started a discussion topic for this section, as I didn't want to mark up this section. Please check and respond there.

Navigating within Content


This location is where users can listen to content modules and where they will spend most of their time. This location is used for listening to content modules designed for literacy learning and knowledge access.

Getting into this Location:

A user selects either a content module or a particular audio segment of a content module. See selection.

Getting out of this Location:

A user must take one of the following actions to exit this location:

  • hold the Help/Home button. See behavior below.
  • tap the Record button. See behavior below.
  • slide the power switch to off. The device resumes with the Home location after power is reapplied. However, the content module will be easy to get back to, because it will have been registered at the top of the "most recently played" list once the content module was selected. See power.

Initial Actions within this Location

Once user content module has been selected, the device will:

  • register the content module at the top of the "most recently played" list.
  • play the content module from its beginning (Package OnStart)

Button Behavior in this Location

Of the ten buttons of this device buttons, five of them have a fixed behavior and five of them can be reprogrammed by the content module's metadata.

Fixed Behavior Buttons

  • Tapping this button will alternatively play and pause the currently selected content module. When paused, tapping this button will cause the content to be played, from where it was last paused (whether by user action or by a content-embedded pause, such as may occur at a segment break). If the last paused point is at the end of the content, the playback will begin at the start of the content module (Package OnStart). If the device is woken from sleep mode, play will resume just as if there was no sleep mode (Last Point Played is remembered).
  • Holding this button at any time (during playback or when paused) will cause the device to jump to the speed control menu. From there, another tap will return to the playback or pause condition that existed before this action. See speed for more information.
Volume Up/Down:
  • Tapping and holding these have the same function at all times as in system module locations, as described in volume.
  • Tapping this button at any time (during playback or when paused) takes user into the Help location (during playback or when paused). This will also then allow the user to easily return to where they were (Last Point Played), to jump to the Home location, or to explore the help content, i.e. to learn about the device functionality or, if provided, about the content module. See help for more.
  • Holding this button will cause the device to go straight to the system module's Home location contexts.
  • Tapping this button when the content is paused, which jumps to the Record location record. There is no response if the Record button is tapped during playback.
  • Holding this button is ignored. It is not equivalent to a tap. No action is taken.

Content Programmable Buttons

  • Content Programmable Buttons basically allow the author of a content module to create metadata that specifies an action that the device should take upon a user tap or hold of the button during a certain block of time within the content module. The most common action will be the goto action; however, the destination point must remain within the same content module (package). There are two categories of content programmable buttons:
    • Select
    • Arrow Buttons
  • This button has no other function (within this location) than what the content module's metadata provides for it.
  • The functionality will normally be an audio hyperlink to learn more information about the current content being played.
  • It may also be used by the content module as an "enter" or "select" button, as it can be used within the system module.
  • It is expected that this button will usually be tapped, but the content module may also assign a function to holding the button.
  • For more information, see hyperlink in the functional spec or elements-onbutton and elements-goto for a lower level view.
Arrows Buttons
  • General
    • The arrow buttons described below each have default behavior that can be overridden/reprogrammed by the content module's metadata.
    • The buttons are intended to serve two primary purposes: 1) navigation within a content module, and 2) input for interactive content applications (e.g. multiple-choice questions).
    • These functions should not conflict with each other since a content module that uses an interactive feature may not need or want the user to navigate away from the interactive part of the module – and users can always exit a misbehaving content module (see "Getting Out of This Location" above).
    • The navigation functionality of these buttons is meant to work as follows: Left and Right buttons are smaller jumps back and forward; Up and Down are larger jumps back and forward.
    • If the device is set down on top of a page, one might imagine the Left and Right arrows represent back and forth across a line of text and the Up and Down arrows represent up and down the page, even though each pair may be used for jumps of arbitrary lengths.
    • The default behavior described below is meant to work best for information content, which is the only type of content that can be recorded by the devices.
    • Literacy content requires a more complex two-level hierarchy of points in text, such as word/line or word/page or line/page. Therefore, literacy content will only be created with the content authoring product, which will make it easy for authors to indicate points in each of these two levels and then reprogram the default behavior of all four arrow buttons.
    • However, information content can be useful with break marks between only one level of audio segments (such as between chapters or topics). A second manner of navigation uses relative time jumps, which doesn't require an extra level of segmentation to be designated by the content author.

The functionality of each arrow button described below must actually be specified in the record spec. It is listed here to provide an understanding of the resulting user experience, particularly of content that has no overridden defaults, such as content recorded on the devices. During playback, the device simply processes the metadata. The implementation of the defaults described below actually happens during the authoring stage, either by the content authoring product or by the device. In the case of a device recording, a very simple set of default metadata is attached to the recording, which will enable the default behavior described below. See the record spec for a definition of that metadata (still a TO-DO item as of March 23rd).

  • Left
    • Tapping this button jumps backwards 15 seconds behind the Last Point Played. If the device was in a playback state when the button was tapped, the device plays the content module at the new position; if the device was in a paused state when the button was tapped, the device remains paused. In both cases, a brief SAF is played to indicate the jump back. If there is less than 15 seconds to the beginning of the current audio segment ( block or file) the device jumps the remaining seconds back into the previous segment. If there is less than 15 seconds before the beginning of the entire content module (elements-package]), then the current position is moved to the beginning of the content module with the device, with the device in the same playback or paused state it was in before the button tap. In this beginning-of-module case, a second SAF is played to indicate the beginning of the content (this may only be a short tone, if not a spoken word/phrase….TBD).
    • Holding this button is ignored by default (unless defined by the content module). It is not equivalent to a tap. No action is taken.
  • Right
    • Tapping this button jumps forwards 60 seconds ahead of the Last Point Played. If the device was in a playback state when the button was tapped, the device plays the content module at the new position; if the device was in a paused state when the button was tapped, the device remains paused. In both cases, a brief SAF is played to indicate the jump back. If there is less than 60 seconds left in the current audio segment ( block or file) the device jumps the remaining seconds into the next segment. If there is less than 60 seconds left in the entire content module (elements-package]), then the current position is moved to the end of the content module with the device in a paused state, regardless of whether the device was paused or playing when the button was tapped. In this end-of-module case, a second SAF is played to indicate the end of the content.
    • Holding this button is ignored by default (unless defined by the content module). It is not equivalent to a tap. No action is taken.
  • Up
    • Tapping this button jumps back to the beginning of the current audio segment, unless the button is tapped within the first 1.0 second of the beginning of the audio segment, in which case it jumps back to the beginning of the previous audio segment within the same content module; unless the Last Point Played is in the first segment of the content module, in which case it still jumps to the beginning of its segment. If the device was in a playback state when the button was tapped, the device plays the content module at the new position; if the device was in a paused state when the button was tapped, the device remains paused. In both cases, a brief SAF is played to indicate the segment jump back. If the new position is the beginning of the content module, a second SAF is played to indicate the beginning of the content (this may only be a short tone, if not a spoken word/phrase….TBD).
    • Holding this button moves the current position to the beginning of the content module, just as if the same button was tapped more times than there are previous content segments.
  • Down
    • Tapping this button jumps forward to the beginning of the next audio segment or to the end of the content module if there is no next audio segment. If the device was in a playback state and not in the last audio segment of the content module when the button was tapped, the device plays the content module at the new position; otherwise, the device remains paused (or becomes paused in the end-of-module case). In all cases, a brief SAF is played to indicate the segment jump forward. If the new position is the end of the content module, a second SAF is played to indicate the end of the content (this may only be a short tone, if not a spoken word/phrase….TBD).
    • Holding this button moves the current position to the end of the content module, just as if the same button was tapped more times than there are following content segments.


The hyperlink should ideally be indicated by a background sound that begins and ends with the word or words that represent the hyperlink. If that level of precision is difficult to achieve in the content development platform, the indicator will still work even if the sound finishes towards the beginning of a subsequent word in the recording.

The sound will be 70Hz, but this frequency is subject to change once feedback is in from beta testers. It is likely that it might have to be slightly higher in frequency so that it can be more easily heard. The key balance is to have a sound that is noticeable but not disruptive.

The user will access or activate the hyperlink by tapping the hyperlink key during or after the sound is heard. In other words, the hyperlink key will activate any current or the latest hyperlink on any given audio text.

Since content that is played after a hyperlink is activated can have hyperlinks of its own they will by default contain at least one hyperlink that brings the user back to the previous segment. The "Go back" hyperlink that must be on every recorded segment by default will function very much like the back function on web browsers. It will bring the user back to the hyperlink that was clicked on, on the previous segment. If the need to save excessive writes to flash memory exists, then the "go back" hyperlink will bring user to the beginning of the segment he/she came from.

  • [Cliff] I think we can use the "Left" button for this "go back" function when the button is tapped near the beginning of the hyperlinked content, see nav.

The main body of the recorded document, i.e. content module, will not have a "go back" hyperlink.

The content below should be moved to help and is triggered by holding the Home button (see buttons)

Pressing down and holding the hyperlink button for two seconds or more will play the message:
"Help Mode activated. Press any key to learn its function or press this key again for two seconds to deactivate help mode."
and will activate help mode. Pressing and holding it in the same fassion will play the message:

"Help mode deactivated. All keys will function normally now."
and take the user out of help mode and back where he/she was.

While in help mode pressing the hyperlink key for less than two seconds, i.e. a normal pressing, will cause the device to play the help description for that key. The same will happen for every other key on the device.

Pressing any key other than the hyperlink key for two seconds while in help mode, will cause the extended help segment to be played for the corresponding key. This will also be a recording explaining the function of the key, but in greater detail.

Content Embedded Pauses

See also some crazy notes at old-nav

Speed Change

The Talking Book device offers playback speed control in order to facilitate learning at the student's own pace. When the student is learning a new word and sound, it's important that they can play the audio at a slower speed so they can hear it better, and perhaps read the corresponding written words. For navigational ease, it's desirable to allow students to increase playback speed, either as a fast forwarding mechanism, or as a way to refresh material in a short period of time.

The device will allow the following play back speed, listed in the order of slowest to fastest:
(Slower playback speed is crucial for learning, and should be prioritized above faster speed, which is more of a navigational helper and not essential to the mission of the device. If cuts need to be made, cut the faster speeds first)

  • 0.5x, or half the normal speed, at constant pitch, so that the student can learn the pronunciation and sound without having to adjust to pitch changes.
  • 0.65x normal speed, at constant pitch is required.
  • 0.8x normal speed, at constant pitch is required
  • 1x or normal playback speed
  • 1.5x normal speed, or 50% faster than normal. Constant pitch is preferred, and should be available as part of the chip set's feature.
  • 2.0x normal speed. Constant pitch is preferred, and should be available as part of the chip set's feature.

The slower speeds are determined from [citation needed] academic studies. The faster speeds are based on digital voice recorder specs only.

We examine all of buttons on the device and found there are no "free" buttons available to put the playback speed buttons:

  • Volume Up/Down should be dedicated.
  • MORE button is used for hyperlink and may be needed at any point in program playback
  • BACK/FORWARD are for jumping back 15 secs or fast forward 30 secs during playback
  • UP/DOWN are used for module/chapter navigation during playback

Thus it's necessary to somehow overloading of existing buttons to accomplish playback speed changes. We examine a number of button schemes:

  • Rapid double-tap of the button: The double-tap speed is hard to gauge and hard to learn. It is probably an unfamiliar concept for non-computer users, since it was introduced via the mouse. Rejected.
  • Tapping of two buttons:
    • Two variations were discussed, either the simultaneous pressing of two buttons, or a key-modifer approach where one button is held down while another is pushed.
    • Pros: There are parallels of simultaneous button pushes in the mechanical world: Some cassette recorders require pushing down of REC+PLAY to start recording. Typewriter's SHIFT key is a similar concept of key modifier and may be familiar to some users. It is easier to demonstrate to new users, without worrying about the timing element which which can be tricky to learn and get right.
    • Con: The two button maneuver requires a bit more dexterity, and is a new interaction that is not used elsewhere on the Talking Book.
  • Holding down of a button for >1 sec:
    • a bit of background: An important point is that a button will only appear to be "tapped" if it is depressed _and_ released within a short time, 1sec or less. The exact duration is TBD.
    • When the button is held (> 1 sec) the device can trigger the HOLD action without ever having triggered the "tap" action.
    • Pro: Since any button held longer than 1 sec is considered a HOLD, there is no tricky timing involved. Since we believe a button modifier scheme such as SHIFT or CTRL is likely the right behavior for any two-button gestures, which will involve a HOLD behavior to begin with, we think we should utilize HOLD by itself as a first step.


  • When a content module is selected, and PLAY is hit, it should always start at 1.0x speed
  • When a paused content module is resumed from a pause state, the playback speed should be the last used playback speed. For example, if I newly selected a module, selected playback at 0.65x, and paused it, but hours later resumed playback, the resumed playback should be still at 0.65x.
  • [FUTURE] It maybe useful to insert the speed back into the metadata for the module, so whenever the next time a given module is played, the same selected speed is used. This will involve, however, some consideration about reseting speeds when a module is copied to another device, etc.
  • Whenever the playback speed is changed, a corresponding SAF is played to tell the user the speed at which audio will play. They are:
    • 0.5x has the SAF as "Slowest Speed".
    • 0.65x has the SAF as "Much Slower Speed"
    • 0.8x has the SAF as "Slow Speed"
    • 1.0x has the SAF as "Normal Speed"
    • 1.5x has the SAF as "Faster Speed"
    • 2.0x has the SAF as "Fastest Speed"
  • When the PLAY button is held down for > 1sec
    • Audio playback is paused, the location is remembered
    • An SAF announces "Audio is paused. Press UP to speed up audio playback, press DOWN to slow down. Press Play again to continue."
    • The user can then tap UP or DOWN buttons to change the playback speed. Each tap will change the playback speed up or down one notch. The SAF corresponding to the newly selected playback speed is announced, i.e. "Slowest" or "Faster", etc.
    • NOTE: The SAF for the speed selected should be played back at the appropriate speed. For example, the SAF for "Slowest" should be played back at 0.5x speed; "Normal" at 1x; "Faster" at 1.5x, and so on. This is to help the user experience how the selected speed will sound.
    • The user can continue to adjust the playback speed up or down until the desired speed is attained.
    • If the playback speed is already at the slowest speed, pushing DOWN will not change the speed further. The SAF for "Slowest" is still played however. The same is true when the speed selected is already the fastest and the user tap UP.
    • When the user is satisfied with the speed selected, he taps PLAY again to continue playback at the selected speed. Audio resumes where it was left off.

Input / Output

Recording Content


This page is an early draft.


Compression of recorded content

Audio recordings on the device will encoded at the highest quality codec available to the chipset (A1600?) and at either 16, 20, 24 kbps (TBD). Since we will likely have more memory on the device than we need, a higher bit rate is acceptable, unless there is negligible difference in quality for voice audio between 16 and 24 kbps. The reason for choosing a lower bit rate (smaller size) when we have plenty of memory on the devices is to reduce the memory costs at the kiosks, where this could make the difference of requiring 32 GB vs 16 GB at each kiosk to support 10,000 pieces of 15-minute duration content (to pick one example).

Creating a New Content Module

Pressing the record button and holding it for at least 2 seconds will activate record mode. Once the record mode is activated user will hear "Record mode. Press record again to continue." Pressing again record button once, without any 2-second delay, and he/she will be prompted for title of segment. Specifically, prompt will say:

  • press up or down arrow key to choose and then select the title of a previous content module and by doing so, associate this recording with that module; or
  • Press left key to select segment for editing; or
  • press the hyperlink key to create a new content module, in which case user is prompted for name of new module once the hyperlink key is pressed and asked to press hyperlink again to conclude recording of name; or
  • simply wait for the beep to start recording the name of this segment. Press record again to stop recording the title.

Once the record button is pressed again, the device plays a recording that says, "The title is [title recording]. Recording will begin when you hear the beep. Press the record button to stop recording."

once record button is pressed to stop recording, the device stops recording and automatically switches back to play mode placing user at the beginning of the segment just recorded.

Indicating Chapter Breaks in Newly Recorded Content

All segments are accepted as indivisible. Segmentation must take place at time of recording. user simply stops recording and starts again designating each segment to the correct module.

If user activates record mode, then moves to the left, user will have a list to choose from that includes: erase, re-record title, re-record segment, append, and create a new segment.

by moving up and down the user can listen to the above options. Once he moves right from any of those options or presses select on top of one of them, the option gets activated.

Erasing a segment

Erase will erase the entire segment including title and segment content. The user can decide to erase and re-record only title or only the main body of the segment by choosing one of the re-record options.

If user moves up or down until he/she reaches the erase option, he can either press select or move to the right to activate this option. In either case, the user is placed on the list (elsewhere called column) of files i.e. segment titles. By selecting a segment title the user will hear: "If you press the hyperlink button this segment [title of segment] will be deleted. Press it at any time to erase or press cancel to cancel and keep the recording" At that point the audio of that segment is played back in its entirety unless the process is interrupted with the hyperlink key confirmation or with a cancellation. If the recording reaches its end without any user input, the device loops back and repeats the initial message with the title of the segment and plays the segment again.

Appending content

the user might want to have additional content on a segment that has already been recorded. By moving up or down until he/she finds the Append option on the menu, he/she can select that option by pressing right arrow or simply select. The user is then presented with a list of modules, and once the user selects a module with the right arrow or select buttom, the user is presented with a list of segments to choose from in the same fassion. Once the segment is selected the user is prompted with "Recording will begin after the beep. Press pause when you need to stop temporarily, and press it again to continue recording. Press record again when you have finishedrecording. Recording begins now [beep]".

Changing the Title of a Content Module Recorded on the Same Device

to change the title of a segment the user simply selects the re-record title option listed above when he is in record mode and presses left arrow to look at options. either by pressing right arrow when on top of the correct re-record option or by pressing select while on top of it, the user is placed on the list of segment titles. user is then able to move up and down the list and either press cancel which brings him back to the list on the left, or press left arrow which does the same, or presses enter and is prompted:

"The current title of this segment is [segment title]. Press record to start recording a new title or any other key to cancel."

if user cancels he is placed on left list of options, if user records he is first prompted with message "Start recording new title after the beep and please press the record buttom when done [beep]"

Deleting, Inserting, and Replacing Chapters from Content Created on the Same Device

Deleting and replacing is done with the procedures described above. Inserting, i.e. modifying the order in which segments are listed and played when inside a grouping, that is done in the following manner:

The list on the left containing erase, re-record, etc, will also contain an option called re-order grouping.

user selects re-order grouping and then is immediately placed on the
list of title segments on the right.

As user moves up and down on that list, he can select any title and move it up or down by simply pressing select, moving to a new location on the list and pressing select again. A move and paste operation.

the process is finished when user moves to the left and makes a different selection or when he/she presses cancel, or hyperlink, or actually any button.

Giving Titles to Chapters and Creating a Table of Contents

Need to ask you what you mean with table of contents, in this context.

Ability to Make Changes to Content Recorded on Device Long After Initial Recording

If a piece of content is created on device A, copied to device B and others, deleted from device A, and eventually makes its way back to device A, the content can no longer be modified by device A.

An alternative to this might be having every device store an MDsum of any content it creates, and never deleting those identifiers. Then once an edit is desired, the device checks to see if it has an MDsum number that corresponds to the content prior to any modification, and if so, editing is possible. That way, assuming perfect digital copies, and trusting on the extremely low probability that any two files will have exactly the same MDsum, the device will know the signature of any file it has ever produced. The computing requirements for such calculation need to be assessed.

Adjusting Volume


Redirecting Output


Transferring Content

Copying a single content module from one device to another device.

User Experience Steps

1. Physical Connection

  • Two devices are physically connected. The latest design (3/15/08) calls for the devices to be connected via a cable, via the special, non-USB, device-to-device port.
  • As long as the cable is connnected, the devices are in copy mode. To go back to single user/device mode, the device cable needs to be physically disconnected.
  • If at any point during the entire copy process, the copy operation is aborted, then the device falls back into this mode, i.e. cable still connected, and goes into step 2.
  • This implies a requirement for a frequent "still connected" keep-alive status exchange between connected devices, on the order of every half second. Only when the keep-alives are no longer being processed does the device goes back to the single user mode.
  • If cables are every disconnected, i.e. keep-alives are miseed, then each of the device responds with the default Talking Book greeting message.

2. Devices Simultaneously Respond to Connection

  • When each device recognizes the connection is made (should be simultaneously), each device plays a short System Audio File (SAF) that says, "Who is giving?"
  • This needs to be a very short SAF since it may be coming from both devices at slightly offset timing.

3. Determination of "Giving" / "Taking" Roles (USB Master determination)

  • When any button is pushed on either device (other than maybe Power Off button):
    • The selected device will attempt to signal to the other device that it is the master.
    • Error condition: If a device receives such a signal but it thought it was the master (from having its button pushed about the same time), the signal is rejected, and one of the devices plays a system audio file saying something like, "Please only push a button on the Talking Book that is giving."
    • The nonselected device (the USB slave, aka "taking") will play a system audio file, "I am taking."

4. The Giving Device Asks for Content to Transfer

  • The selected device, the USB master, (aka "giving") will wait two seconds (to not overlap with the previous audio) and play a file saying, "I am giving. Do you want to give, {plays the title audio segment of the most recently selected content module}? Press Play button if Yes, or select another module" [or whatever other pair of buttons that are intended to function as Yes or No].
  • The choice of the module to announce at this point, i.e. when d2d copy is first activated, should start with the most-recently played module.
  • If the Home or Escape button [we'll see what we come up with for this function] is pressed on either device, this specific copy operation is canceled, but the devices are in still in copy mode as the cables are still connected. Restart at step 2.

5. Finding the Content to Transfer
(For simplicity, only one module can be selected and copy at one time. i.e. there is no "multi-select" and copy.)

  • If any of the up/down/left/right selection button is pressed following the previous prompt, then the normal rule of selection (see selection spec) is applied. As a new content module is selected, that module's title is played in the SAF "I am giving. Do you want to give, {content title}? Press Play button if Yes, or select another module"
  • It's important that the playing of the title can be interrupted immediately and at any time, with either the press of Yes or any of the up/down/left/right selection buttons. If another selection is indicated, the new content module's title is played as quickly as possible. The idea is that one could rotate through the reading of ten content module titles in 3-5 seconds, if one was familiar enough with the voice and/or first word of the title.
  • As long as a selection choice is made instead of Play/Yes, this process continues rotating through titles until
    • a) a Yes is selected (continue to step 6);
    • b) the Home or Escape button [we'll see what we come up with for this function] is pressed;
    • c) the device goes into power saving mode from no button presses, from which it should recover, if still physically connected, to step 4 (where the giving/taking selection has been determined); or
    • d) the batteries die, from which it should, if connected, recover to step 1.

6. Checking Memory Availability of Selected Content

  • If Yes is selected, the size of the selected content module is sent to the slave ("taking book" :-), which responds with a signal to indicate if there is available memory.
  • If there is enough memory, continue to step 7.
  • If not, a system audio file is played by slave device, "I'm too full for that one. Please disconnect us and empty me, or maybe your friend can give me something smaller."
  • If disconnected, each device returns to the state it was in before the connection was made.
  • Until disconnected, the Giving device pauses and repeat "I'm too full for that one. Please disconnect us and empty me, or maybe your friend can give me something smaller."

7. Alert Users of Copying

  • The devices are now both prepared to copy a particular piece of content.
  • The giving book (master) will play an audio file that says, "I am now giving {audio title}. Please leave us alone until we have finished sharing."
  • the device will, at regular intervals, make a low-pitch sound to indicate it is busy.
  • If the file size is 24-48 MB (~ 16-32 seconds at USB 1.1's 12Mbps), it will also play, "This will take just a few extra seconds."
  • If the file size is > 48MB (> 32 seconds xfer), it will play "This is one is very large and will take a minute to share. Please have patience."

8. Errors During Copy
[Need to handle errors related to the copying here.]

9. Successful Copy

  • If the copy was a success, the taking book will play, "I have it and am ready to take something more."
  • Both devices then go to step 4.

Indicators and Instruction

Visual Indicators

nothing here yet

Auditory Indicators and Instruction

nothing here yet


Control of Power

nothing here yet

Availability of Power

nothing here yet


System Extensibility

nothing here yet

Content-Based Extensibility

nothing here yet