RussellHltn wrote:
Would anything special need to be done to support Braille devices?
Daisy supports synchronizing Braille with the text and audio, though no players support this, that I know of. However, if we are designing the player, then there's no reason why such functionality couldn't be added.
The only problem I see is that Braille is only produced for a few of our publications. But, if there were enough demand...
RussellHltn wrote:
Going back to what you are envisioning, I'd see it as something that could be "flavored" to go to the initial download. For example, since you would be downloading it from the lds.org site, it would go back to that site to find content on install. But another group could do the same thing to have it go to their site.
This is also something that I've thought about. Of course, if enough organizations began offering feeds of their DAISY content, then it might also make sense to give the user the ability to add additional locations to their library.
mkmurray wrote:
Out of curiosity, which standard(s) would you support? the 2005? the 2.02?
Currently, we are creating books in the 2002 format. The format changed significantly from version 2.02 to 2002, but the differences between 2002 and 2005 are not that great. The 2005 format just added some specialized features that we probably won't need.
Still, I would eventually like to have it support all formats, but Daisy 2002 would be a good start.
Nearly all of the hardware players can support the 2002 standard, although some of the older models may need to have their firmware updated.
RussellHltn wrote:
Another question: what is the standard computer interface for blind users? The reason I ask is I'd assume that most programmers on this project would be sighted will little experience in coding or even using products aimed at the blind. That creates some user interface issues.
Most blind computer users (though not all) are using Windows with a screen reader. Some also have Braille displays. Other than that, our computers are generally no different.
Creating interfaces for the blind or folks with low vision should not be too much different than creating one for a sighted user. If one is careful to use standard windows controls (as aposed to nonstandard controls that are used by some cross platform gui kits), and if the developer makes sure that all controls have text associated with them and are accessible via the keyboard, then there really shouldn't be any problem.
Under Python, the best answer I have found is the WxPython toolkit. This is cross platform, but it also utilizes the standard windows GUI controls.
I plan on being as involved as possible with the development of the interface, to make sure that this doesn't become an issue. Even though I would like us to make the interface self-voicing, I would also like to make it work well with screen readers, because most screenreader users would rather use their screenreader to get access to the screen. (Sorry for the tongue twister.)
JamesAnderson wrote:
One other thing, since the files would be in mp3 format, would one also be able to download them for use on anything that otherwise would play mp3 files? That way even if one was not disabled but wanted the same content, they could grab that off the site and listen to it, just like any other mp3 file now published by the Church and others, albeit without the special/enhanced features that using a DAISY player would bring.
Yes. I have been quite careful when creating our DAISY books to name the files in such a way that they should play in order on any device that sorts its playlist by file name.
The only difference between a bunch of MP3s and a DAISY book is that a DAISY book has three or four extra XML files in the directory. I assume that most players worth anything should just ignore any file they don't recognize.
tomw wrote:One comment in favor of Java is the platform independence. Building in Python still requires you to call specific platform GUI calls. However, I love the idea. Who wants to participate?
Tom
I believe that the WXPython package mentioned above takes care of this. You use the WXPython interface, and it figures out which API to interact with based on the OS. I believe in Geek Speak this would be refered to as an abstraction layer.
Finally, I have been working on a class that will parse the XML data into a nice data structure. Up until this morning, it was all pseudo-code, but it seems to be coming together nicely. It's not much, but it's a start.
Aaron