Since I started exploring Vista and, to a lesser extent, Office 2007, Blind Confidential posts have given JAWS 8.0 quite a spanking. With nearly a full week using Vista behind me, using Window-Eyes most of the time, I feel I must comment on short comings of the GW product and point out situations in which either System Access or JAWS provide a more usable solution.
As it has been more than nine years since I last used Window-Eyes on a full time basis some of my impressions of it in Vista are likely also true in XP and earlier operating environments. Also, some of the issues about Window-Eyes that have caused me to struggle a bit result from my using JAWS so much over the last eight and a half years and that I know the commands I use with any frequency so well that I don’t need to think in order to act. Finally, various aspects of the Window-Eyes interface seem very unfamiliar to a JAWS user which also requires a different way of thinking in order to function properly.
I don’t know if such a beast exists but I think a set of tutorials on the subject, “Window-Eyes for the JAWS User: A Primmer on Using a Second Screen reader,” would serve users who want to use WE as well as or instead of JAWS quite well. Of course, if such a document existed, I would probably ignore it as I tend to only consult documentation when I’ve already tried everything I could think of on my own.
JAWS users, including me, think in terms of a modality based upon which cursor (PC, JAWS, Virtual or Invisible) is active. Window-Eyes has two or three cursors (equivalent to the PC cursor, a JAWS cursor that moves the mouse pointer, an invisible cursor that GW calls the WE cursor and, although not identified as a cursor per se, a virtual cursor when in browse mode). Years ago, I remember users complaining that the different modes that JAWS employs caused some confusion. I found the simultaneous cursors in Window-Eyes quite confusing over the past few days as, because I know JAWS so well, I think in terms of a mode defined by the active cursor.
I can see advantages and disadvantages to each system. JAWS, in all of its different modes maintains a single set of keystrokes to perform similar and identical tasks. Thus, a JAWS user only needs to learn one set of hot keys to perform the most common tasks like reading a line, word or character. In Window-Eyes, there are at least two cursors (the one that equates to the JAWS PC cursor and either the WE or mouse cursor) active all of the time and, as a result, a user must memorize two commands to read a line, word or character. Of course, having the mouse cursor turned on all of the time obviates the requirement that one switch between modes to perform tasks best suited to a specific cursor.
Whether the modal approach or the double simultaneous cursors is more user friendly is a topic that my friend Will Pearson can speak to far better than me. To me, when I find myself in a place that Window-Eyes does not read immediately, I think I should do something like routing my JAWS cursor to the focus (PC cursor) which is a mental artifact of having used JAWS almost every day for more than 8 years. At the same time, I can see why a person more fluent in Window-Eyes would find the different modes JAWS uses quite confusing.
The cursor and modality issue is the same on all platforms and not, therefore, specific to Vista. It did, however, slow me down quite a bit as I had to stop and think about or even look up a keystroke now and then.
This brings me to the JAWS keyboard layout that ships standard with Window-Eyes (also not a Vista specific issue). The people at GW provide just enough of the JAWS desktop keyboard layout to, in my opinion, really confuse a JAWS user. Because of the lack of cursor based modality, Window-Eyes cannot provide the consistent set of keystrokes that exist in JAWS. Thus, I’ve been spending a fair amount of time trying to create a keyboard layout as similar to the JAWS Kinesis as I can. Once again, I cannot say which system is superior, only that I am much more familiar with JAWS so remembering that different keystrokes govern the mouse cursor than the focal one slows me down and makes transitioning from JAWS to Window-Eyes less smooth than I had hoped.
Recently, I’ve written about how I need multiple screen readers to accomplish everything I use a computer for. In the areas in which System Access does a good job, I definitely prefer it to Window-Eyes as its default keymap mimics that of JAWS so I immediately feel at home when using it. This specific issue probably keeps most users locked into either JAWS or Window-Eyes as the time to learn the different user interface metaphors can easily become an expensive training issue.
My next complaint about Window-Eyes has to do with how it talks to audio hardware (I don’t know if this is true only in Vista or if has been around for a while). I almost always wear headphones while working at a computer. The headphones I most often use is a Logitech USB headset which has its own sound card that resides on its USB cable. When running JAWS, I can listen to it speak using Eloquence through speakers and then plug my headset into a USB port and JAWS will recognize that my default sound card changed and will switch over to speaking through the headset sound device. This is not the case with Window-Eyes (at least in Vista) so, yesterday, while I had to juggle sound devices Window-Eyes had to be restarted each time I either plugged in or detached my headset.
Perhaps because I spent a lot of years working on it, I find the JAWS UI considerably more intuitive than that of Window-Eyes. In JAWS, one need only go to a single place in the UI to globally change basic behaviors like speech rate, running from the system tray, hot key announcements and other simple settings that I tend to adjust right after installing a new version of JAWS. Window-Eyes provides some keystrokes for making global adjustments but, in its own window, one must separately set things like speech rate and pitch by using items under three different menus. Compared to JAWS, I find this process to be pretty clunky and, in general, I find the WE UI to feel a bit antiquated. If I remember correctly, System Access only has global speech and other settings so is, in my mind, the simplest to grasp.
Window-Eyes also seems to use different keystrokes to perform common tasks depending upon which application is running. I’ve heard some people claim that this is a more intuitive approach as each Set file is tweaked to meet the specific use case. Frankly, I find any system that requires me to memorize more keystrokes than I absolutely must to be less intuitive than using the same keymap in all situations. While the JAWS cursor based modality might confuse people accustomed to Window-Eyes, JAWS users can get completely confused by needing to remember differences in the keymap as one switches between applications.
Likely due to my novice status as a Window-Eyes user, I can’t figure out why changes made to the hot keys do not immediately take effect. In JAWS, if one goes to the Dictionary Manager, any changes take effect as soon as one saves the jkm file. Also, with JAWS, advanced users can open the keymap file for a given application or the default in Notepad or some other text editor, change a keymap, save the file and it will instantly take effect. This, in my opinion at least, is far more intuitive than figuring out whatever it is that one must do to make Window-Eyes learn a new keystroke or two.
Other settings and configurations are also much simpler in JAWS than WE. Specifically, if I want to change the synthesizer I want JAWS to use, I go to a menu that only includes synths that I have installed; Window-Eyes, on the other hand, presents me with a list of every synthesizer that they support, whether I have one or not. I accidentally fat fingered a keystroke while in this part of the WE UI and found myself entirely without speech, “Sue!” I yelled and my lovely wife came to the rescue but if I had been home alone, I’d have been SOL until I could find a sightie to help out.
JAWS provides a feature called “hot key help” which, by default, launches when a user hits INSERT+H. As Window-Eyes does not have virtual viewer functionality, it may not be able to offer a similar feature. In JAWS, especially in applications where the scripters and developers add a large number of keystrokes it is easy to forget those one doesn’t use frequently. JAWS hot key help brings up a window that lists most if not all of the keystrokes available in a particular situation (it is context sensitive at the application level) and the user can arrow through the list, search with the virtual find feature or navigate however he chooses and when the user finds the feature he wants, he is told which hot key is bound to the feature but, at the same time, can hit ENTER on the feature name and JAWS will execute the command. This is a really nice feature in programs like Excel and GoldWave which have literally dozens of hot keys to perform lots of really interesting functions.
On the other side of the argument, I find that, in Vista at least, Window-Eyes runs faster than does JAWS. Window-Eyes rarely, if ever, repeats a bit of text over and over, a really annoying aspect of JAWS that really should be fixed. Overall, in my first week with Vista, I still feel that Window-Eyes does a better job than JAWS in most cases. At the same time, I find that JAWS “feels” better than WE and that JAWS many help and tutorial features make it more comfortable to operate.
I promised Mike Calvo that I would spend a week using System Access as my primary screen reader in Vista so as to get a feel for it in a more real world environment than I have gotten by simply starting it up and checking if one or two things that either JAWS or Window-Eyes does poorly. I will report on that experience when it is completed.
A month or so ago, I wrote that if I had to live with only one screen reader, I would choose JAWS. Today, now that I use Vista daily, I am confident that I need at least two and maybe three screen access tools to do everything I use a computer to do.
Today, I plan on trying the speech recognition features of Vista with Window-Eyes. I want to get a copy of jVist but I don’t know where to purchase it in the US. I supposed if I wasn’t so lazy, I could find it on the T&T web site.
— End
I think that if someone were to start off with no prior experience of screen readers then the cursor configurations of both JAWS and Window Eyes would be equally as easy, or should that be confusing, to use. One problem that you are running into that a virgin user would not is that you already have memories related to the specific keystrokes and processes that you use to accomplish a specific task and these keystrokes and processes are associated with JAWS. So, when you come to think of an activity, and particularly an activity you haven’t done that often with Window Eyes, you are likely activating the memories related to performing that activity with JAWS. Also, remembering keystrokes and the processes associated with Window Eyes will seem harder than it does for JAWS because you have less cues associated with the Window Eyes memories and the synaptic bonds for the Window Eyes memories are weaker than they are for your memories related to JAWS.
I don’t like the idea of having different keystrokes for the same task based on the application currently being used. This would seem to increase the initial cost of learning an application and the continuing costs associated with maintaining proficiency with an application. If you consider J Stacey Adams’ Equity Theory of motivation then people do thinks if the benefits they derive from the activity are greater than the costs associated with that activity. I don’t know enough about whether the difference in keystrokes bring any efficiency gains to reduce the costs, but if they don’t then the additional learning will more than likely be putting some Window Eyes users off using applications that they would otherwise have used.
I think that when it comes to good user interface design that all screen readers could easily make it into any hall of shame. Screen reader user interfaces are pretty horrible and the funny think is that half the job of a screen reader is to be an alternative user interface to a computer system. So, you would have expected screen reader vendors to be on the ball when it comes to user interface design but this really isn’t the case. One senior manager at a leading screen reader vendor refers to usability issues as “training issues”, which transfers the problem from one of bad design on the part of the screen reader vendor to a problem with the user, whilst another screen reader vendor has commented, in response to some specific suggested UI improvements to their product, that they are “something that customers do not want”, whilst another screen reader vendor has commented that UI improvements are “gimmicks”.
Hi Chris, also wish there was a sort of primer for JAWS users wanting to change screen readers. I have to learn WE, because that is what’s installed at Uni and I’ve used JAWS at home all my life, now I have to study the WE documentation, going through stuff I really don’t want to know, I just want to know how to sort of use WE!
You stated “Window-Eyes also seems to use different keystrokes to perform common tasks depending upon which application is running.” I have been a Window-Eyes user for nearly 10 years and have not observed this situation. No matter what application I am in, insert t announces the time and date, control shift t reads the title bar, control shift w reads the entire window, etc. If this is not the case for you, I’d be glad to help you sort out your problems.
As far as the issue with the various modes in JFW for the pc cursor, jaws cursor, etc., I basically understand what is going on. However, I don’t understand the reason. The arrow keys move the cursor in windows even without a screen reader while the keys on the numeric keypad move the mouse pointer as long as the num-lock is off without a screen reader. I think GW Micro wanted to stick with how the applications and Windows treat these keys and keep that behavior consistant even with their screen reader. Window-Eyes has an invisible WE cursor which, frankly, I never use. Its purpose was to allow one to explore the screen without disturbing the contents of the screen. Some applications change icons and perform actions when the mouse pointer moves over particular sections or areas of the screen. The WE cursor was designed such situations. Most of the applications I work with do not behave in this manner and thus I don’t have a need for the WE cursor. While JAWS provides a user with the same keystrokes to read from the perspective of the cursor, JAWS cursor, etc, this is not how windows and applications behave without a screen reader present.
Again, if you have any questions what so ever, don’t hesitate to write. You can reach me at fire975@yahoo.com.