pjr@ariel.ucs.unimelb.EDU.AU (Peter Rayner) (09/28/90)
Index Number: 10675 This overly long article is written in response to several recent postings on the subject of graphical user interfaces and the visually impaired. I think it is a fair paraphrase of these articles to say they are pessimistic about the future. In summary there is a wide belief that the increasing prevalence of software which concentrates on layout or presentation will undo much of the advance made in the last decade towards nonvisual access. I do not share this belief and intend to show some pathways forward in this article. This sounds very grand. Let me say I haven't actually tried to do any of the things I'm going to talk about. I've had neither the money to buy the necessary hardware nor the time to write the software. It's also entirely possible I'm not a good enough programmer to actually code this stuff but what the hell. I think it can be done. I'm also not the only person actively thinking about this. The Outspoken System from Berkeley Systems Inc. already implements some of the ideas I'm going to mention (so much for making my fortune). What the hell would he know you ask? Well not much maybe. I'm not a professional software engineer, really a mathematician/meteorologist. I do a fair bit of programming and get to spend a lot of time playing with Unix workstations, much touted as one of the harbingers of doom. So take this for whatever you think it's worth. I'm also totally blind and a computer user since the early 80s, neither of which are credentials. First a quick and incomplete summary of some changes in the way computer's do business. We already know about the increasing use of the two dimensional nature of the screen to display things. This has not occurred alone. The machine which commercialized this approach (it didn't invent it) was the Macintosh. It launched a new vocabulary of scroll-bars, dialog-boxes, windows, pull-down menus and so on. It also did one less obvious but more important thing. It provided a standard way of organizing this new zoo. This meant that when you saw your first menu in a new application, you new how to select an item from it. You also new the difference between a click and a double-click and so on and, if the programmers were playing by the rules, it worked the same way every time. There are two ways of achieving this kind of consistency. Either you can have somebody standing behind each and every programmer continually sharpening a large axe or you can write a library. Libraries are cheaper than axe-wielders. So Apple provide this library of routines to our would-be programmer for drawing menus and getting selections from them, for arranging to scroll text etc. Apple also had to provide video hardware that ensured programmers could write well-behaved applications without them being as slow as a wet week. This brings us to the second important lesson to learn from the Mac. The application, the part of the program which is doing something other than talk to the user, has this well-defined way of finding things out from you, the library routines. It doesn't really care much what goes on inside them provided it finds out what it wants to know. This means that the user interface is, to some degree, separated from the rest of the program. Hence, if things are going well, you only need to adapt the interface. And what of Dos? I don't really like Dos. It may or may not have some of this stuff but if it does, not many people use it when writing new programs. I suspect it doesn't in fact. So the problem is not so much that people write applications which draw characters on the screen directly, but rather that there isn't a standard place you can snoop on them doing it. The efforts within IBM which were reported at the Denver NFB meeting in 89 are focusing on finding these places within Windows or Presentation Manager or whatever it's called. Oops they're different aren't they. Anyway I hope they have a standard way of drawing characters, otherwise we're in a spot of bother on that front. And Unix? Here's where I get all excited. Warning: much of the rest of this article is nerdish. Well Unix comes in lots of colours and flavours. All of them are inherently multi-tasking so there's no problem having a process sitting around gobbling up text and speaking it. My two favourite current hardware systems even have sound capabilities on board which is promising. There are two main ways of displaying stuff on Unix screens at the moment. By far the most popular is X-windows. This is a huge conglomeration of software, a "server" for doing things to your screen, a truckload of libraries for talking to it, multiferous window managers, prewritten applications etc. As I understand it, the server isn't very clever. I don't think it knows about characters and other such high-level constructions. Anyone care to set me straight? There are, however, a reducing set of libraries around which new coding is being standardized. This should provide us with an opportunity something like that for the Mac. Postings in this group earlier this year have already talked about making X talk, hopefully someone is already at it. The other output method and the one I think provides the best access, is postscript. Postscript is the language used to describe pages to many laser printers. At least two companies, Sun Microsystems and Next Inc. are using extensions of it to describe output to their screens. Postscript is a genuine programming language. Hence it has simple commands for drawing lines etc, for drawing characters in particular fonts and sizes, shading. It also has mathematical operations and all the standard stuff for a complete language. Most of its operators can be redefined. It also has procedure calling capabilities. Hence at least Sun and probably Next have chosen to write toolkits (another name for these interface libraries) using postscript. So what? Well an example. The operator usually (in my experience at least) used for displaying characters is "show" which takes a string as argument (sort of). As I understand it there's nothing to stop me redefining this to (1) display the characters (wouldn't like to exclude anyone now would we) (2) send the characters to my speech synthesizing process (3) keep a note of the area the string is displayed in for a later review mode. We then go on to do similar things for alert boxes and all the rest of the menagerie. Again, provided the application is using this standard toolkit to talk to us it won't even know the difference. Also for enthusiasts of programming elegance, all we've done here is change some vendor-supplied high-level code for our own, no changing binaries etc. Sound too good to be true? Well it probably is but I can't think why right now. At least one problem is that these postscript-based output systems aren't very popular yet. Anyone from Sun still reading? As soon as I get sustained access to one of these machines I'm going to start testing the feasibility of such an approach. A simple proof of concept is to just stick my existing PC on the serial port and start playing with the postscript. Writing speech synthesis programs is difficult but obviously feasible for something with the processing power of a Sun or Next. Ah well, I've gone on way too long and missed bits still. In summary: nil desperandum. ps, anyone have some money, time or I.Q. I could borrow, all three overstretched here. Peter Rayner