Slashdot Mirror

It's worth noting that Don Norman, the former VP of Apple's Advanced Technology Group and the author of The Design of Everyday Things (among others) is currently a professor at Northwestern University. He's teaching a class this quarter, the future design of everyday things (sorry--login required for the class page), and it's fascinating!

Josh

I've been playing around with the bitkeeper source control system for the last week. After reading this article I suddenly recalled that bitkeeper treats 2-way merge and 3-way merge as entirely separate features. N-way is not even discussed.

In some ways N-ways is merely a simple generalization of 2-way. The algorithmic complexity is not much different. The problem here is human scale. Humans cope well with two-way merge as a daily activity, cope with 3-way merge at the level of focus required by air-traffic control, and don't cope with 4-way merge under any sane circumstance.

Bitkeeper solves the problem by designing the architecture so that merges can be performed hierarchically. This is a feature that CVS sorely lacks.

Everyone knows that the success of projects is to a large measure determined by whether the architecture obviates the need to delve into N-way hell.

I also recall a project where a database supported two processes which concurrently updated the same dataset. During the design process we found a way to define the system so that each process was permitted to update a distinct set of columns, with maybe a column or two where one process was allowed to set a value and the process allowed to clear the value. Months of potential development effort slashed at the stoke of a pen. The first design dealt with the concurrency problem in a different way. Getting everyone to respect everywhere the subtle rules required by that design just doesn't happen on most projects.

The best book on the subject is the psychology of everyday things

What people tend to forget is that nuances of a software design create affordances with respect to the coding effort. When the pressure is on, people tend to grab onto the nearest handle. The handles hidden in the design have a momentous impact.

Some of the most important affordances are second order effects.

The C++ language is often criticized for having a model of class protection which is easily violated. Yes, that's true as a first order criticism. However, the C++ makes it fairly easy to figure out a way to manipulate the source code to find all the violations if you decide to look. These manipulations might be a temporary modification for the sole purpose of determining whether a certain kind of integrity exists. The C++ community doesn't lose any sleep over the first order weakness of the class protection model. We all know that violaters are playing a dangerous game.

On the other hand, there are certain kinds of abuse in the C language where it's practically impossible to turn up the smoking gun short of a complete source code audit.

The difference is not that C++ prevents programmers from abusing abstractions, but that it provides the necessary affordances to catch the people who do. The importance of these second order effects is vastly underestimated by those who plan.

You can see the extent of the problem wherever mouthy mights thrive. You know the people who always shout "it might happen" when the downside of anything they oppose is mentioned, as if might was an adverb of quantity. The implicit logic is that only a first order guarantee is sufficient, yet the recent study shows what everyone already knows, second order affordances generally suffice.

My experience is that projects are a morass of non-quantifiable psychology, experience, and intuition. The second order effects are never discussed on paper. It's left up to the cohesion of the team to impose the second order effects that make the first order effects possible.

It would be far more useful for the estimation people to spend their time figuring out the conditions under which a project becomes non-viable. Offer the programmers some kind of handle for coming back to management with their concerns about faulty second order effects, in language a whole lot less vague than what I'm using.

Wouldn't it be a fine start just to be able to limit ourselves to projects where the outcome is somewhat proportional to the effort expended. If we had proportionality already, the kind of estimation we have now would be a second order concern in its own right, rather than a masturbatory mission impossible.

As the commenter above notes, the now standard WIMP (windows, icons, menus, pointer) interface isn't necessarily the optimal way to interact with a computer; it's just what we've all learned to work with. And it's worth noting that even that interface took several iterations to get right, just as it does for a lot of MS software (IE, Office, Windows, etc all seemed to come of age with the 3.x versions, and start surpassing the competition that they copied with the 4.x & 5.x versions. They of course start bloating by the time they get to 5.x & 6.x, but that's a separate problem... :)

Computer hardware is now drastically more capable than it was when Bob came out, to the point that software developers are always looking for ways to fill up all those extra clock cycles -- anything from running Seti in the background to having hooks in the Windows interface that pause for a few hundred milliseconds before opening a menus so that "it feels like the computer is working harder" -- surely my least favorite part of the Windows interrface and the first thing I try to disable with TweakUI on any computer I'll be using regularly. The really "revolutionary" releases of the recent past -- Mac OSX and Win XP -- aren't really revolutionary at all, but glossier and more refined versions of what we've been using for well over a decade now -- and in the case of OSX at least, you could argue that the interface is a step backwards in terms of flexibility and usability, emphasizing style over substance at the UI level, even if the underpinnings are surely much more advanced than before. XP might also be guilty of this, but I haven't used it yet so I can't say; I do know that the dissolving menus that Win2k had were guilty of the same sort of cute wastefulness that OSX/Aqua's pervasive translucence & drop shadows represent...

Maybe it's time to consider abandoning the WIMP interface. Maybe the world is ready for Bob or something like Bob to give it another shot. Or is it? Bob tried to represent the computer 'space' as the interior of a home, and for a desktop computer of sufficient power (i.e. what most of us have now, but didn't have when Bob came out), this isn't so bad. But in a networked world? Can you achieve some sort of network transparency & represent it in that sort of metaphor? I dunno, maybe. I am sure that it's an interesting challenge, much more than ever more glossy iterations of the same old Mac & Win interfaces could ever be, as they both try to refine their implementations of the Macintosh Interface Guidelines ever further.

Maybe it's time to give the Anti-Mac Interface a try -- a system that inverts all the assumptions that we've been working with for years now.

The authors of The Fable of the Keys are economists and are not experts in user interface design.

The design of everyday things by Don Norman contains more accurate information. In brief, Dvorak is better than QWERTY, but only by about 10%, so it's not worthwhile to switch.

Reading the summary, and having a lot of respect for what the authors had to say on other topics convinced me it wasn't worth my while to bother with WAP.

The WAP Usability Report (available in PDF form for $26) reports on a study where 20 people were given WAP enabled phones for a week and asked to report back on their experiences. The study was done in London because of the advanced state of WAP services there. Read the summary here.

• 70% of users reported they would not use WAP within a year
• One user calculated it was cheaper to buy a newspaper and throw away everything but the TV listings rather than use WAP to check the BBC schedule

our basic conclusion is that WAP usability fails miserably; accomplishing even the simplest of tasks takes much too long to provide any user satisfaction. It simply should not take two minutes to find the current weather forecast or what will be showing on BBC1 at 8 p.m.

• Jakob Nielson
• Don Norman, author of The Design of Everyday Things, Things that Make Us Smart and The Invisible Computer
• Bruce "Tog" Tognazzini, one of the original designers of the Macintosh UI and author of Tog on Interface. Check out Tog's Software Design Bookstore to learn how to write software that doesn't suck. Read Top 10 Reasons the Apple Dock Sucks.

I link these and a couple other useful sites in my brief section on Some Web Application Design Basics in Use Validators and Load Generators to Test Your Web Applications:

I'm not talking about pretty rollover buttons here, folks.

You need to understand that many web sites are developed with investments totalling many millions of dollars, only to have the effect of driving away any user who might have the misfortune to stumble across them, with much resulting heartbreak and the loss of fortunes.

Why should everyone have to know how their computers work?

If not, why are crazy parents putting children in the age of four in front of their mast^H^H^H^Hcomputers then?

Working in the field of human factors, I fully agree with you in that it is the machines', or better the designers' and developers', fault if people encounter difficulties. Every careful reader of Don Norman's The Design of Everyday Things oder Jakob Nielsen's Alertbox column knows that.

The interesting thing is, most people don't. They surely notice when getting confused by some software, web site, or gadget, but they are drawing the wrong conclusion that they had to learn how to use it, or that their children should learn it as early as possible, and things like that. Just a few hours ago I encountered a colleague who complained about usability of some web site. It took me a while to assure her there really are incompetent "web designers" who do not care about users and do not really understand the concepts behind web technology. And this happens over and over.

And things are getting worse. The Internet not only brought to us a lot of incompetence in user interface design, but also a tendency to make three steps backwards unnecessarily. We are told the web browser will be the user interface for everything in the future, because "everyone can use a browser" (how about the application inside the browser?), our personal computers get replaced by "thin clients", and typing on a mobile phone's tiny keypad is considered an adequate way of making payments. In short, we are going back to terminals and transactions, and beyond.

Even cool sites like /. are affected. I would prefer to type into a real text editor instead of this text entry box. I would like an auto-save function for everything I write built into my /. client, like the one in my favourite Usenet newsreader. I would really appreciate a more flexible, i.e. not page oriented, presentation of comments, which my favourite Usenet newsreader provides as well. Don't get me wrong; /. is quite usable if one considers the limited capabilities of a web browser. But those capabilities are not sufficient for most interactive applications.

Recommended reading:
C. Fellenz, J. Parkkinen, H. Shubin: Resolving conflicts between the desktop and the Web

This approach generally ignores the fact that the user herself can frequently become a valuable source for new interface ideas. A big pool of creative people is more likely to come up with some suggestions that turn out to be worthwhile. To paraphrase Don Norman: "People propose, science studies, technology conforms." It all starts with the people.