[bookport] Suggestions for Improvements to Book Port - Others' Input and Discussion Requested
- From: "Jeremiah Z. Rogers" <jzrogers@xxxxxxxxxxxxx>
- To: <bookport@xxxxxxxxxxxxx>
- Date: Mon, 10 May 2004 06:35:45 -0400
Greetings to all ye Book Porters
A few weeks back, there were a number of messages surrounding Book =
Port's behavior when playing MP3 audio, where it leaves markers once it =
has played the file, etc. I didn't weigh in on the discussion at that =
point, because I wanted to think over the idea I had and to decide =
whether or not the practicality of it warranted suggesting it to APH for =
consideration. Please do point out, publicly or privately, the positives =
and negatives you find in the following thoughts.
At present, the transfer tool allows the user the option of specifying =
whether mp3 audio is sent to the machine as music, which is to say that =
it is unmarked, or to have the software deduce breaks in paragraphs, =
chapters, and other navigational units. Many of you were asking for a =
means of resetting all of the markers within a given folder such that =
you could start at any given point in the list of files and have the =
files play, starting from the beginning, in exactly the same fashion as =
would occur when using a commercial CD player. Seemingly with little =
modification of the Book Port's firmware, and perhaps with only slight =
modification to the transfer tool, APH could instruct the device not to =
keep track of where it left off playing a given file if that file were =
sent as music, while still retaining the device's present behavior for =
audio files which were sent allowing the transfer tool to mark them up. =
If, for some reason, one wanted to start at a given point other than the =
beginning of a sent-as-music file, they could still use the device's =
marking features.
Concerning a separate issue altogether, I also have a suggestion for how =
the Book Port behaves once locked and powered off. At present, if any =
key other than the 1+3 combination is pressed, the machine emits that =
all-too-familiar half-second or so buzz, waits the customary ten seconds =
or so of inactivity, then powers off. Over the course of half an hour in =
one's pocket, briefcase, or other location of transportation, this could =
happen dozens of times, and could cause lots of disruption to those =
around the device with that annoying beep. My suggestion, then, is to =
have the lock and unlock command be a combination of keys, and to have =
the machine's behavior when the unit is locked and not reading to be =
completely unresponsive to keys or key combinations other than the =
command chosen as the unlock command. Further, I suggest that the unlock =
command be a combination of keys other than on the same row or column. I =
suggest 1+F, given that they'd take two hands to invoke and that it =
shouldn't interfere with any of the present command structure.
I look forward to reading any insuing discussion in response to these =
thoughts.
Jeremiah Z. Rogers, jzrogers@xxxxxxxxxxxxx
Other related posts:
