The Quest for Universal Usability

The author refers to "universal access" as an "important step" and a "compelling goal," but does not indicate the reasons it should be considered as such. His view seems to stem from the notion that it is a political right, and that those who are unable to use the technology are a class of "have-nots" to whom society has a duty to provide with the things they cannot get for themselves, to bring everyone up to the same standard. (EN: Poppycock)

A "particularly strong argument" is that technology oprovides access to government services - such as tax filing, social security benefits, e-mail to legislators, etc. - and lack of access creates an "Internet apartheid" system in which those without access are denied their basic rights (EN: this is only true if the Internet is the only method for exercising one's rights. The argument favors the prohibition of technology by government in favor channels that already have universal access.)

The author sets his goal of "universal" at 90% - then cites statistics that only about 51% of US households have computers and only 42% have internet connections. Demographically, the technology is used by the "social elite" - individuals who are wealthy, educated, and live in urbanized areas. Internationally, the inequities are even greater: industrialized nations have it, developing countries do not.

The author asserts that the technology is presently too expensive, and asserts that "telephones and televisions are universally usable" and implies that computers should be the same. (EN: in their infancy, these technologies were the toys of the rich, and eventually dropped in cost to the point where the middle and lower classes could afford them. So he seems to be cheering on what will happen anyway.)

He also cites difficulty of use as a significant barrier to the adoption of computer technology. (EN: again, cheering evolution. The television was not always a push-button device, but earlier models required the user to adjust an antenna and fiddle with dials to get a usable signal)

There is also the matter of providing accommodation to the disabled. The author draws an analogy to curb-cuts, which are less expensive to build in advance than to tear up the pavement and install them in arrears. EN: he also draws an analogy to vehicle manufacturers, which is probably not wise, as there are very few vehicles that are accessible to the disabled (panel vans being an exception) and many categories of disabled (deaf or blind) are prohibited, by law, to operate a vehicle at all, which is contrary to his intentions.

Coping with Technology Variety

At the time the book was written, technology variety was a problem: there were wide variances in hardware, software, and networks that were not analogous or compatible, which made it difficult to accommodate some users without disenfranchising others.

He suggests that "every user of computers has to decide about keeping up with change" (which is ironic, as his overture would seem to suggest he'd be in favor of government programs to provide everyone with the latest equipment to keep everyone on equal ground.)

Designers generally set a minimum standard, and cut off other users, though the author asserts that "software [should] be designed so that users could run the same program on a palm-sized device, a laptop, and wall-sized display" (EN: a patently idiotic concept)

Changes in software are also a concern: each version of a program provides newer features and additional capabilities, but fails to preserve compatibility with older file formats. The author favors "bi-directional file conversion" (EN: another utopian concept, which is supported to some degree today.)

Accommodating Diverse Users

The author lists several factors related to the user (or their location):

The author's perspective is that services must be developed to suite the broadest possible range of users. (EN: I disagree - a key concept in UX is specialization, or tailoring the experience to the unique needs of the market segment you are seeking to serve. One size does not, and cannot , fit all.)

What Users Know vs. What They Need To Know

EN: this section is a lengthy ramble that doesn't quite make a point. My notes here are a total paraphrase that is on the same topic, but may not be an accurate reflection of what the author intended to communicate.

Every computer user must learn how to use an interface in order to accomplish a task. (EN: this is not unique to computers - you must learn to use a broom in order to sweep a floor.) The challenge for designers is to bridge the gap between what the user already knows and what they need to know to get through a task.

There are two basic approaches to training users: providing information in advance of a task and providing information in the course of doing a task. Historically, computing counted on the first approach, and every product came with a set of manuals to be read before beginning. In action, users do not use the manuals, but proceed haphazardly at the task, hoping to figure it out as they go along.

Knowledge and experience means that users begin at different levels of capability and confidence. A user may have performed a similar task using different tools, a different task using similar tools, both, or neither.

The author looks to game designers, who provide clever introductions that gracefully provide the information on new items in the game, and unobtrusive ways to access information within the game, such that it does not unduly interfere with the player's experience of the game. He suggests that similar approaches can be used for less frivolous purposes.

Finally, many users will need additional help, beyond what can feasibly be provided in the context of an application: e-mail, telephone, and other forms of interactive support will be needed. He also rambles a bit about peer support through chat rooms and bulletin boards, or online interest communities, but doesn't seem to come to a point.

The Skeptic's Corner

One objection: that accommodating a broad number of users will result in a "lowest common denominator" approach to interface design and prevent any real progress from being made. The author concedes that it is a 'reasonable fear" but provides a few examples of instances in which users could be accommodated without holding back the rest.

He also cautions against designing for the most capable users, using the latest plug-ins and tricks, but this is more of a rhetorical trick to suggest that it's one extreme or the other.