hello Sabahattin In reply to the last point of this email, the source code is already on the website. This has been the case as of May 13. You will find it by going to resources, then BrailleNote downloads.
Dean. Regards, Dean Jackson Customer/Technical Analyst Pulse Data International Ltd. DDI: +64 3 373 6184 Fax: +64-3-384 4933 Email: [EMAIL PROTECTED] Internet: www.pulsedata.com __________________________ ----- Original Message ----- From: "Sabahattin Gucukoglu" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, July 29, 2004 5:12 AM Subject: [Braillenote] List Of Requirements For Next Mainstream Release > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > I see the list hasn't quietened down much despite my inattentiveness to it > of late :-) . I got to go to Sight Village where I both exhibited as > AGRIP (for those who were there, that was the computer making beeping > noises and occasional bloodcurdling screams as monsters took the full > force of explosive rockets, deadly spiked nails, grenades and other > instruments of torture) and looked around, and of course I got to bump > into PulseData's stand and saw most everything there was to be seen. Very > impressive stuff. Titchy isn't really an adequate description for their > newest line-up. I've always thought a lot of PulseData's hardware, it's > really inovative and cool and totally appropriate for its audience. Now, > the software for the BrailleNote is what I'll be discussing next as that > needs improvement. If I could just take what I wanted from their stand, I > would take both the PK and their 40-cell Brailliant. Great work, > PulseData! > > Right, well, all that aside, I'm still busy, though not busy enough that I > won't give this list some much-deserved attention. So here, for immediate > digestion by those who care to read it, is my dream BrailleNote. This > list is the result of talking to a couple of friends about what the > BrailleNote was lacking, and which features seemed to be most important > for a near-perfect and practical PDA. The list is by no means final, of > course, but I think those who read it will agree that there is not more to > add to the list that most pocket devices or mobile phones don't now cover > in this day and age. In short, these items on top of the existing > BrailleNote line complete the generic feature set of a PDA, and it will be > then that I'll be happy to declare it as such. > > I would have sent these through the feedback form on the site as well, but > it appears to be busted. > > 1. SDK. Well, we all know about that. Just make it complete, well- > documented, thorough, and flexible. When you write an SDK, you are > agreeing to keep it that way or to make your interfaces stay the same > regardless of change; don't make any weird changes without telling us > about it, don't expect people to recompile their code once every five > minutes, try not to break old programs when a new release is available for > use. If you agree to use a closed system, that is more or less your > obligation, if you open source your interfaces this is often not the case - > the perfect example of this backwardly-maintained interfaces problem is > Microsoft Windows. The main concern was that PulseData might not provide > enough in the SDK to make it useful for true extensibility. For example, > if someone (probably me) designs a drop-in replacement for KeyMail, I do > expect to be able to integrate it into the system in the way that > PulseData currently has this core feature integrated. We want to be on a > level footing. On a similar note, we did discuss why it was that > PulseData didn't just develop the proprietary hardware and bare minimum > platform necessary to facilitate interfacing with proprietary components > such as speech synthesis for which they are obliged to keep things quiet, > and implement their own applications on top of it, thus providing > exemplary programs for us to use for our own code. This latter sentence > implies that PulseData would need to be willing to open up the source for > such higher-level applications. I have not forgotten Jonathan's offer to > write to him personally on the matter of open source, and, situation > pending, I will do that. There is a lot of legacy stuff still there in > the BrailleNote; your use of higher level application libraries in newer > parts of the system is a good thing, but remember to port the old stuff as > well. This previous suggestion gives you such an insentive. On the > matter of security, always remember that security through obscurity is > bad, bad, bad. Once again, the perfect example is Microsoft Windows. > > 2. IMAP and Exchange, SSL support for email, robust email design suitable > for pocket devices. Many corporate installations are exclusively now > using the Internet Mail Access Protocol (IMAP), typically version 4rev1 > (see RFC 3501) and/or the Microsoft Exchange service for receiving mail. > Apart from more widespread usage, IMAP is significantly better for use on > pocket devices where the presence of abundant bandwidth is not an issue, > since it allows most operations concerning mail manipulation to be done on > the server, including searching the mail. A notable example of recent > adoption of open standards by ISPs is that of AOL, which is heavily > considering allowing the reading of mail using IMAP exclusively in > addition to its proprietary interface. Even for the Post Office Protocol, > version 3 (POP3, see RFC 1939), a number of features can be used to allow > browsing and downloading of mail selectively, and even filtering based on > header or partial body downloads alone. In common with all protocols is > the requirement for SSL support, now required by many ISPs and corporate > sites for security of access remotely, using the protocol's provided > extension. For SMTP, this is the StartTLS ESMTP extension (see RFC 3207). > Generally, the email system needs an overhauling - the data structures > used, the functionality available, the performance. > > 3. Scientific calculator needs attention. General facilities that are > appropriate for pocket devices would be very helpful, currency conversion > being one such thing. Regardless, the scientific calculator currently > does not fair well against, well, most things. It is a conventional > calculator with a few added features, not a scientific calculator. This > wants looking at. If I can use another scientific calculator with more > features instead of the BrailleNote in circumstances where I would > otherwise use it then the BrailleNote is clearly not doing enough. I > would much rather there was no calculator at all. Examples are > statistical functions, function variations (such as hyperbolics), > substitutable variables, and graphical resolutions. Not all of these are, > understandably, easy to implement. As it stands, though, it is simply not > representative of any form of scientific calculator. > > 4. Less obfuscation of advanced operating settings - the BrailleNote runs > Windows CE, whether we like it or not. Many problems reported on this > list turn out to be fixable using an ugly hack, such as by modifying the > BrailleNote's registry or changing some file somewhere. Although I > appreciate the need for simplicity, I do think this black box should let > its user alter parameters that would otherwise have been assumed by the > BrailleNote. Examples of this are serial port parameters used for > ActiveSync, networking parameters, power management, caching options, > cookie settings, and so forth, in line with the original flexibility in > the existing programs you are using to underlie yours. There is room to > make these options sit somewhere out of site of the user who cares not to > look at them, but I do think an effort should be made to let us tweek > things the way we want them. In the case of cache file management and > cookies, these decisions are matters of privacy and security also. > > 5. General consession to practicality. The BrailleNote generally does > what it does well. What it doesn't do, it determinedly, defiantly doesn't > do, and no amount of tinkering or hysterical screaming will make it do it. > You have chosen to design your own interface as a replacement for an > inherently more complicated one, and we congratulate you for doing that - > there is no room for arguing that the BrailleNote encourages productivity > in a convenient way that makes sense for the blind and vision-impaired. > It is important, however, to cover everything you have written thoroughly > and, given the way the BrailleNote is targetted at getting the job done, > PulseData should be willing to commit to fixing minor issues important to > practicality before embarking on the next big thing. It is this sort of > concern that prompted general feasibility questions of open source in the > first place. The most predominant example that comes to mind is the > longstanding issue of how to read or get the URL of the current page in > the web browser and mail it to someone, or of clicking MailTo links in the > browser to open the email client or vice-versa (clicking links in the > email program to open the web browser). These are little things that > ought to be sorted out by now, two or three releases previous, fixing them > now rather than later will brighten up someone elses' usability experience > and encourage them to hold faith in the quality of the next release. It > is hard to imagine the SDK you will be providing will give us the chance > to fix such bugs, so once again you need to be ready for the suggestions. > This emphasises the need for PulseData to act on collectively appreciated > problems at once rather than at the next release cycle. We discussed if > it might be possible to just close the time delay between releases as a > way of doing this, but we wondered impartially whether that might > encourage the development of buggy code that did not undergo quality- > assurance as a result. It is really important to listen to the little > details. In our opinion, we think you would benefit from implementing > those suggestions now rather than later. I think that is one big reason > why I use Window-Eyes over JAWS (no, I do not want a flamewar, but > generally it is understood that GW Micro will tend to listen out for the > little details and have often done so for my personal requests and will > fix them very quickly). > > 6. Printing support. In this day and age, printing support provided by > the BrailleNote is yet another hallmark of inappropriate code > preservation. Fix it! Most modern printers simply do not work with the > BrailleNote anymore. > > 7. Hardware support. This relates specifically to supporting modern > hardware bought off the shelf. Your customer base must feel happy about > buying hardware for various purposes off the shelf, with your prior > recommendation if necessary and without obligation to purchase from you, > and your software must do its best to work with all such hardware. So, if > I buy a PCMCIA or serial Bluetooth adaptor and put it into my BrailleNote, > I expect to be able to use your fine configuration tools in precisely the > same fashion as for your in-built Bluetooth adaptor on the PK. > > 8. Better file management. There seems to be a common consensus that the > file management of the BrailleNote, though doable, is clumsy at best as it > stands. There is a real need for a file manager that has a Windows-like > navigational structure, and shortcuts for performing operations, rather > than performing operations from a menu. Also, this issue of file types > and not being able to manipulate files of certain types for certain > reasons (EG not being able to use KeyBook to open a file with an > unrecognised extension known for text or braille documents has turned out > to be quite unhelpful. This is one of the things that configurability > will give your customers the chance to change - just as many Windows users > choose to display all extensions and hidden files, so should the > BrailleNote family. > > Finally, and this is unlisted because it is just a reminder, please don't > forget to put up the source code for XBase. It is not there yet. > > That's all for now. If you've got comments, send them up - I'd be glad to > hear them! > > Cheers, > Sabahattin > - -- > Thought for the day: > Communist (n): one who has given up all hope > of becoming a Capitalist. > > > Sabahattin Gucukoglu > Phone: +44 20 7,502-1615 > Mobile: +44 7986 053399 > http://www.sabahattin-gucukoglu.com/ > Email/MSN: <[EMAIL PROTECTED]> > > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0 -- QDPGP 2.70 > > iQA/AwUBQQfeeiNEOmEWtR2TEQKuXQCgnA42s4XQq0cGfj64aDM2NVRKf9wAni8S > uDQwb2knmi+kWgJRaVkcj3tt > =JsxR > -----END PGP SIGNATURE----- > > ___ > To leave the BrailleNote list, send a blank message to > [EMAIL PROTECTED] > To view the list archives or change your preferences, visit > http://list.pulsedata.com/mailman/listinfo/braillenote >
