ncyoung.com

JAWs is an application that blind people use to have the contents of web pages spoken aloud to them in a synthesized voice. In fact, JAWs will read any part of the screen, including application menus, alert boxes, etc. The vocalization generally follows focus.

The latest version of JAWs has a trial package that you can use for forty minutes after each restart of the computer, which is generous enough to make getting a feel for the app practical. I've recently been exploring the site I work on using JAWs and it's a pretty strange experience.

I had never quite thought carefully enough about it to make the distinction between audio browser and screen reader, but using JAWs on a page whose structure is intimate to you brings home this distinction right away.

The way a page is laid out is (ideally) optimized for the way the eye absorbs information. Reading the page left to right top to bottom doesn't necessarily present it in the way that's most intuitive to a listener. Reading the page in DOM order may or may not be an improvement. Adding elements that get read but not seen may also help the audible experience.

Ideally, the page could be structured for visual interpretation when displayed on the screen and structured for audible interpretation when spoken. CSS includes can specify a media type for just this reason.

This is not at all the model that JAWS uses, and in fact there's no way to put this model in place for JAWs users. Using JAWs with a web browser, the web browser renders the screen and then JAWs reads it to you. It's strictly limited to created a visual experience, then trying to read you that visual experience.

For that job JAWs works very well, and it's necessary for interoperability with a wide range of applications. But it falls well short of the usability we could be getting by tailoring the spoken experience differently than the seen experience, even in very minor ways.

JAWs

Fangs is a firefox plug in that lets you read the page in the order it would be read to you by JAWs.

I posted before about Eudora's status bar and how useless it is.

Now I've found a status indicator that's one step more hilariously meaningless. Status indication for the backup client I use (connected TLM) has a status bar and a percentage complete number. These two do progress in tandem, though that's about as much consistency as they have.

The client has a cute characteristic twitch of progressing inconsistently but rapidly to the "79% done" mark and then staying there for up to an hour.

The good news is that once you're past 79% the rest of the job takes under 2 minutes.

Not only does the speed with which status changes vary wildly, but progress gained is no guarantee. I have seen the progress shoot to 47% then back to 3% in a most unnerving manner.

Update:

I found out why it works this way. The application maintains a queue of diectories to examine, adding to that queue and examining directories in the queue at the same time. Directories that have not yet been added to the queue are not counted in the percentage left to complete. I'm not sure why 79% is the magic number, but it must reflect something about the ratio of add speed to examine speed. Or it could be that the application is purposely optimized to maintain a specific ratio of files examined to files in the queue.

Obviously the percentage reflects a presumably accurate picture of some portion of the internal state of the application. Labelling it "% complete" is just plain incorrect. And insufficient information is given to the user to expect them (me) to figure out what the figure DOES represent.

Eudora has as status bar that fills up as you download email. The really funny thing here is that the status bar will chug along, then slow way down when it comes to a big attachment. Sometimes this means it goes fast then slow then fast again.

The net effect is that you can't tell anything at all from the status bar. You don't know based on how far it's gone how much of the task you've done. You don't know based on the current speed of progress how much longer the whole job will take. The only thing you know is that you're not done yet.

A common problem with devices is the lack of a good display. Building displays into everything is costly, takes up space, and may involve design compromises.

Plain old washing machines can have a ton of features and modes, how can you see what's going on?

Remote controls are about the worst examples, since even if the device has a display you may be too far away from it to see it.

A universal remote program I downloaded or my palm pilot gave me an idea about this. Suppose in addition to beaming infra-red commands from the palm to the device, the device could beam back information about its state and the options currently available? The palm becomes another interface to the device, potentially much richer, more customizable and easier to use.

I understand that wi-fi and genie (or whatever replaces it) could do this. But why do we need to wait? Is it just that no-one's thinking about this? I want to get into device hacking.

Here's some neat palm ir stuff...

Reading The Design Of Everyday Things.

Affordances are attributes of a thing that suggest ways for it to be used. (I love it when I find a rock that fits my hand perfectly. I guess that's a false affordance, but I love it anyway.)

Constraints are limitations that prevent you from using a thing in a way it was not meant to be used.

Visibility means that you are provided relevant information about the state of the thing before you take action with it, and that you can see the effect of your action.

Mapping is harder to explain quickly. A thing should help you build a mental model of how it functions. Putting up and down buttons next to each other is bad mapping. Putting the up button above the down button is good mapping.