Hi Joseph and All: Interesting post and something worth thinking about. The basic problem though as I see it is the long-term lack of significant advancements and enhancements to KeySoft, and advancements that have been made have taken Kezsoft backwards as much as forwards.
Many of you already know that I have largely abandoned BrailleNote in favor of Pronto, the upgraded BrailleNote PK. However, I still follow this list because my wife is still a BN user, and I did use Keysoft for over 5 years. Regarding software, the single biggest reason I decided to move on was my belief that there will never be a credible SDK for BN, despite the many promises from HW. It's clear they have no idea even how to get started with such a project. The other major reason was the lack of significant software upgrades. I see little evidence to suggest that will change. I'd love to be proven wrong on either count. Also, I got sick of dealing with the file typing issues. I'd rather have a plain text file than these proprietary BN filetypes. It is certainly true that we should be cautious about assumptions of HIMS product upaidates we haven't yet seen. All the best: Chris --- Original message --- Subject: [Braillenote] Comments on recent posts (a bit technical) Date: 3/20/2011 1:33:46 PM Fron: Joseph Lee <[email protected]> To: [email protected] > Hi folks, > > Despite the recent developments, I can still see that > BrailleNote > does have some following among its users. As with any > product, > the concerns raised about BN family are valid, and I, too > would > like to see some clarification from HW about these issues > posted > on this list. Coupled with recent questions, I'd like to > summarize my take on latest developments in this post: > > * Braille Sense firmware 6.0: Personally, I'd say, "let's > wait a > while, then we'll write a commentary about it." From what I > can > see, all the posts that we've read and wrote were nothing > more > than speculations, explanations, some misinformation and > hopeful > suggestions. Speculations, because we are talking about > something which haven't been released, therefore lacking > proof of > what we are talking about. Explanations, since I think not > many > people on this (and other) mailing list didn't know other > options > existed for some time, thereby giving others a chance to > shed > some light on current state of assistive PDA market. > Misinformation (at least some were), since some posts > suggest > that HIMS's "grass is greener" when in fact HW's "technical > > forest" is stronger - and we have just started exploring > perhaps > less than a tenth or even a fifth of this massive > potential. In > a way, HIMS would have a "greener field" thanks to feature > sets > and their SDK (with one programmer willing to write a > compiler/interpreter for a simple language), but when we > note > technical differences, Apex is ahead with plenty of room > for > corrections, improvements and up-to-date (technically not > anymore) platform to work with. Suggestions, because most > of us > would like to see some Braille Sense-like features on our > BrailleNote, yet, as one lister put it, "... we are at the > mercy > of the company ... ,was thus the only "effective" (and > sometimes > not that used) solution is suggesting some feature sets. > > Overall, I do agree with the sentiment that BrailleNote has > room > for potential enhancements in the near future. I > personally do > feel that 1there needs to be some sort of a comparison page > of > sorts, which is the perfect reason why I host such a page > on my > site. However, in my opinion, what HW could do to help us > is > extensions support, particularly extending current doc > support to > docx and beyond, libraries for more media types and overall > of > how KeySoft functions at runtime level. However, I'll say > this > again: Dear HumanWare Staff, could you give us any > indication of > a possible release of public SDK for BrailleNote? Thanks. > > As for the specs and hardware with accompanying software > issues, > I personally take a view that the blindness PDA market as > we know > it will fade away. With the speed of change in mobile > technology > arena, one would find oneself "trapped" - sacrificing > usability > for enhancing braille experience. No, I expect blindness > PDA > market to come to a close in the near future when > capacitive, > touch-based braille display comes to existence, with > gradual > reduction in price and integration of accessibility on > mainstream > devices (IOS is the prime example of what we'll see later; > however, instead of wireless braille displays, I can > clearly > envision touchable braille interface being integrated > seamlessly > to other devices via enhancements to touchscreen interface > and > technology.) Some would take this "judgment" as a shock - I > can > already envision people saying, "how can this be possible?" > > However, for those of us who are concerned about future > viability > of blindness devices, this is not an "old news." I'll save > the > rest of this conversation to a later time (not now, because > I > need to learn more about hardware this year before I > continue). > On with the rest of this post, shall we? > > * KeySoft's multitasking ability: Quite an explanation is > in > order: KeySoft is not a multi-file suite as with Microsoft > Office. Rather, KeySoft is a huge executable file which > has > several functions and "sub programs" of its shj (commonly > called > subroutine, thread and other terms). When KeySoft runs a > "task," > what keysoft.exe is really doing is switching to other > threads > running within KeySoft (a thread is a task that a poogram > performs). For instance, whenever a document is opened, > KeySoft > "opens" with KeyWord. It sort of opens it, but what > KeySoft is > really doing is running a > "KeyWord" thread and asking the thread to do something with > the > file in question. Similarly, when you are viewing a > contact, > KeySoft asks "KeyList" thread to view the database for the > user. > Thus, if you switch between these two tasks, what Windows > CE > (more towards KeySoft is asking) "really doing" is > switching > between these threads within a process called "keysoft.exe" > (in > computer science jargon, this kind of task is called > "thread of > execution" - that is, a program can perform multiple tasks, > but > to the OS, it would appear as one executable). > > * File download percentage reinstatement: This is only my > hypothesis and opinions (again, I'm not a HW programmer, > but have > some guesses about KS): As stated before, if you have > KeySoft > 9.1, you won't get percentage indicators when downloading > files > from the Internet nor you'll get notifications on number of > > files/folders zipped/unzipped. This is because these > "tasks" are > run by separate executables (programs). A basic rule about > > programs (sometimes termed "processes") is that a program > cannot > view what the other program is doing (unless if something > went > wrong). To rectify this, two likely solutions come to > mind: > converting these processes to libraries (DLL, or > dynamic-linked > library, a service that does something and is availible to > programs that needs it, such as device drivers), or asking > the > programs to tell KeySoft what it is doing (chief among > download > indicators). > > Converting exe to dll require doing some work from > programmers' > end by telling the linker (a program which translates links > > produced by compilers to machine code) to transform the > source > code as a library (dll) instead of creating an application > (exe). > >From there, all that the library would do is report to > KeySoft > what it is doing, thereby restoring the feel and look of > what we > were used to before 9.1 (having percentage messages when > file > download is in progress). However, this has a crucial > design > consideration to keep in mind: It may use additional > memory, and > if the library is not "retired" (freed) from memory, it may > > create memory problems later (where availible RAM may > decrease). > Other things to keep in mind is that different connections > have > differing dowdload speeds, and websites which use security > would > lengthen the download process. > > As opposed to this, asking the programs to tell KeySoft > what is > doing might sound easier - all that is required would be > periodically returning some indicators. But it is not that > easy, > particularly because KeySoft cannot really "listen" to what > the > other programs (particularly the downloader) is doing > unless the > downloader itself provides messages. > > Personally, if I was a programmer, I'd prefer the latter > approach, with the programs themselves reporting to the > user as > to what it is doing. However, with the possibility that > third-party programs (if released) may benefit from this > enhancement, I think the former option could be considered > as an > alternative. But it is really up to HW developers to do > this > (I'm just a user just presenting my ideas, that's all). I, > like > many others, would like to see this lack of progress > indicators > be fixed in the maintenance release (and I expect this > release to > be availible sometime within the next two to three months, > given > the release patterns from last year). > > For those who are new to this sort of "technical talk," I > guess I > should clarify by writing a mini dictionary of CS terms on > my > website... Hope you understood at least the picture of > what's > going on. > > * Microphone: It is sort of hardware, but it is something > you can > control. This distortion is usually caused by high volume > level > on the microphone. Before you start recording, from Main > Menu, > go to Media Center/Record a Memo. At the prompt that > appears, > press SPACE with DOT 3 (LEFT ARROW) or SPACE with DOT 6 > (RIGHT > Arrow) to change the mic volume level. For mPower, I > recommend > between 15 to 25 db; for Apex, I recommend levels no higher > than > 5. > > That's all. Again my apologies if some of the content > didn't > make sense... If you have any comments, feel free to post > about > it. > > Cheers, > Joseph > > ___ > Replies to this message will go directly to the sender. > If your reply would be useful to the list, please send a > copy to the list as well. > > To leave the BrailleNote list, send a blank message to > [email protected] > To view the list archives or change your preferences, visit > http://list.humanware.com/mailman/listinfo/braillenote
___ Replies to this message will go directly to the sender. If your reply would be useful to the list, please send a copy to the list as well. To leave the BrailleNote list, send a blank message to [email protected] To view the list archives or change your preferences, visit http://list.humanware.com/mailman/listinfo/braillenote
