Slashdot Mirror

and Don Norman, who has something to say on the matter.

Jeesh. Why is this even a question?

Anyone who has ever done any reading on usability knows that we need to craft the interface to the user.

That usually means different interfaces for different cultures.

For example, Japan and Germany have general populations that are far more used to multi-choice, complex UIs than the US and UK. They tend to prefer their UX to be a bit more technical than other cultures.

Engineers tend to design for themselves; not for others.

Read The Design of Everyday Things. It's quite life-changing.

This book changed the way I view the world (Don Norman is Nielsen's buddy). Ever since I read it, I learned a new appreciation for human interface.

Terribly amused by the irony of the usability of the original ebook version of the book, as mentioned on that site.

UThis book changed the way I view the world (Don Norman is Nielsen's buddy). Ever since I read it, I learned a new appreciation for human interface.

Instead of saying "this book" (especially when there is no book laying around) could you instead, maybe give the actual name of the book? I realize typing "The deisng of everyday things" is a lot longer than 'this book" but it is MUCH more informative (and well a better design) for the reader.

Unfortunately, he mispeld "Nielsen."

Those guys get upset when we don't spell write.

As someone who has done plenty of criticizing (and received it), I can say that we need to get our facts straight when we do it.

That said, I'm a HUGE proponent of usability. I think tecchies, as a species, tend to really suck at it (I include myself, there). I am constantly amazed at how "stupid" my users are.

Except...they can be doctors, lawyers, scientists, engineers, teachers, etc. Real smart folks.

When a whole bunch of real smart folks make the same mistake, over and over again, then it's probably a real good idea to examine the usability of the interface.

This book changed the way I view the world (Don Norman is Nielsen's buddy). Ever since I read it, I learned a new appreciation for human interface.

Serving a constituency that tends to take personal frustration and embarrassment out in rather pithy fashion helps to keep me focused on making UX accessible.

is an essay written by Donald Norman, you can read it here: http://www.jnd.org/dn.mss/the_psychology_of_waiting_lines.html

He argues that there are several things that matter more; one that matters the most is the perceived fairness of the queue.

It doesn't matter if the line is long, or that you have to wait slightly longer; what matters is that everybody waits roughly the same amount of time, and there is no way to cheat in such a system.

Giving up control is a feature. When you have options to choose from, there is a chance that you made a sub-optimal choice. In the case of a single line - you are certain you chose the fastest option ;-)

The highlight of the paper is that in the context of customer satisfaction, perceivedPerformance > actualPerformance.Whether this rule is the same when it comes to counting the profit - is another matter.

http://www.t0.or.at/delanda/meshwork.htm
"Indeed, one must resist the temptation to make hierarchies into villains and meshworks into heroes, not only because, as I said, they are constantly turning into one another, but because in real life we find only mixtures and hybrids, and the properties of these cannot be established through theory alone but demand concrete experimentation."

Compartmentalization can lead to lots of secrecy ("need to know"). Secrecy helps some things, but it also makes it easier for snakes to hide inside something, or for people to be unable to "connect the dots". I heard about one sociology professor who said, studying movies, that the "good guys" always win because they have better communications than the "bad guys". There are endless books about how organizations can improve their internal communications for greater effectiveness. Also, consider that analysis is about putting things into compartments, but synthesis is about putting things together, and both are important for creative problem solving, and the needs of our society seem to be shifting towards creative synthesis:
"RSA Animate - Changing Education Paradigms"
http://www.youtube.com/watch?v=zDZFcDGpL4U

What good is a "secure" organization if it can't perform its primary function (whatever that is) very well?

There are always tradeoffs of security vs. effectiveness/useability. See:
http://www.schneier.com/blog/archives/2009/08/security_vs_usa.html
Which links to this:
http://jnd.org/dn.mss/when_security_gets_in_the_way.html
"The numerous incidents of defeating security measures prompts my cynical slogan: The more secure you make something, the less secure it becomes. Why? Because when security gets in the way, sensible, well-meaning, dedicated people develop hacks and workarounds that defeat the security. Hence the prevalence of doors propped open by bricks and wastebaskets, of passwords pasted on the fronts of monitors or hidden under the keyboard or in the drawer, of home keys hidden under the mat or above the doorframe or under fake rocks that can be purchased for this purpose. We are being sent a mixed message: on the one hand, we are continually forced to use arbitrary security procedures. On the other hand, even the professionals ignore many of them. How is the ordinary person to know which ones matter and which don't?"

One might expect people at the NSA to be quite a bit more disciplined and trained than average, but certainly this point holds for other organizations.

And about another three letter agency (quoting from Wikipedia) apparently struggling with compartmentalization:
http://www.pdfernhout.net/on-dealing-with-social-hurricanes.html
"All of this has the effect of making it hard for DI analysts to interact even with the classified outside world. The CIA view is that there are risks to connecting CIA systems even to classified systems elsewhere. Mitigating those risks sends implicit messages to analysts: that technology is a threat, not a benefit; that the CIA does not put a high priority on analysts using IT easily or creatively; and, worst of all, that data outside the CIA’s own network are secondary to the intelligence mission."

And links on open alternatives for most of any nation's intelligence needs:
http://pcast.ideascale.com/a/dtd/76207-8319
http://groups.google.com/group/openmanufacturing/msg/2846ca1b6bee64e1
http://www.phibetaiota.net/abou

One of my favorite UI speedups is on recent versions of OSX (but I don't know when they added this): The 'Help' menu has a text box that lets you type in text for that semi-obscure but useful feature, and if there's a match it opens that menu with a gigantic vibrating arrow pointing to that option. So if I know what a command is called, I can invoke it without having to hunt through nested menu la-la-land. But really, that is just a variation of the command-line interface. Of course if you don't know what they called some particular function, you're still boned. Personally, M-x apropos is adequate, but I am a curmudgeon.

Donald Norman Design of Everyday Things (ISBN-13: 978-0385267748) He will get you thinking about the implications of your interface design; this classic may be hard to find but he has other books out as well. While his examples focus on mechanical objects the thought process and criticisms provide insights into how to think about the end user in your design and avoid become someone "Who won an award" for their design. Once you read teh book you'll get what I mean. http://www.jnd.org/

Bruce Tognazzini Tog on Interface (ISBN-13: 978-0201608427) A bit dated but the concepts and idaeas are what matters. He has a website as well as other books. http://www.asktog.com/

Finally, there are classics by Edwin Tufte you may want to checkout as well. He focuses on displaying information (mostly quantitative) in a manner to support understanding; and hates PowerPoint type presentations with a passion. Tufte has a website as well. http://www.edwardtufte.com/ His one day course ie excellant.

My main problem is that unlike most graphics programs, I am never quite sure where the tool that I want is located. In most programs, tools come from a menu that is fixed/attached to the window that contains the image that I'm working on. In GIMP, all tools are selected from a myriad of windows that are opened for various tool sets.

Then if I want, for example, to select the colour palette, then I have to find the window - if it's open. And the problem there is that it could be anywhere on the screen. Heck it could even be hidden under another window. And I have to hunt d__n near every time I want to use a tool that I haven't used in the last five minutes.

On the other hand, in most commercial applications, I slide my cursor to the menu bar, pick the correct drop down and slide the cursor down to the tool. And it will always be in the same place.

You might want to look at Don Norman's essay on Affordances and Design or read his book on "The Design of Everyday Things".

This article is interesting, despite their wide generalizations of gamers, many of which are not really true. If you take out their focus on mentioning video games and gamers every sentence, the article is really about two things.

People aren't having a whole lot of fun in libraries. They suggest: Hold LAN parties, after hours, in libraries. In effect, make the library somewhere that people associate with fun, instead of... not. I don't think this will ever work: people come to the library to find books. If people enjoy reading, they'll enjoy the library. If they just come to do work, then they probably won't. Nothing wrong with that. In my opinion, if you want to make libraries seem like a more fun place, they should have more sections that don't stress silence so much. Of course, people who are trying to work or read quietly, perfectly understandable, but if I'm just leisurely reading and I see someone reading an interesting book, I might want to have a chat with that person. If you go to any bookstore, especially one with a cafe attached, you'll see tons of people reading, drinking coffee and chatting. Why? Silence isn't an enforced rule.

The real substance of the article, though, is about usability. It's not really true that no gamer reads the manual before playing, but the reason that it's not mandatory is because games (especially console games) have a common interface. If you're playing on the 360, you know the controller layout, it's just a matter of pushing a button and seeing what it does. PC games can be a bit more complicated, and I would argue that most people tend to read the readme or look at the Controls option in the game to find out what the controls are. Libraries without a doubt could use a usability overhaul. A requisite link for talking about usability is Don Norman's publications.

As a sidenote, I really hate the term "Digital Natives". I hope it doesn't catch on.

There is a dissenting opinion by Don Norman, by the way.

Read Emotional Design: Why we love (or hate) everyday things and you'll understand why this story constantly comes up.

So flame me, but Schenier has little authority when he speaks of psychology.

If you read the essay you'll see that he isn't inventing his own psychological theories. He's doing a survey of several fields that have produced results relevant to security, and showing how those results affect decision-making and perception around security.

He may make mistakes in applying theories from other fields, but it's only by publishing his applications that the academic conversation can occur. Cross-disciplinary stuff is like that.

For your enjoyment, here's the list of references from his essay, many from outside the field of security. #10 sounds especially authoritative ;)

1 Bruce Schneier, Beyond Fear: Thinking Sensibly About Security in an Uncertain World, Springer-Verlag, 2003.

2 Robert B. Cialdini, Influence: The Psychology of Persuasion, HarperCollins, 1998.

3 Malcolm Gladwell, Blink: The Power of Willful Thinking, Little, Brown & Co, 2005.

4 Daniel Gilbert, Stumbling on Happiness, Alfred A. Knopf, 2006.

5 Barry Schwartz, The Paradox of Choice, HarperCollins, 2004.

6 Bruce Schneier, Beyond Fear: Thinking Sensibly About Security in an Uncertain World, Springer-Verlag, 2003.

7 David Ropeik and George Gray, Risk: A Practical Guide for Deciding What's Really Safe and What's Really Dangerous in the World Around You, Houghton Mifflin, 2002.

8 Barry Glassner, The Culture of Fear: Why Americans are Afraid of the Wrong Things, Basic Books, 1999.

9 Paul Slovic, The Perception of Risk, Earthscan Publications Ltd, 2000.

10 Daniel Gilbert, "If only gay sex caused global warming," Los Angeles Times, 2 Jul 2006.

11 Jeffrey Kluger, "Why we Worry About the Things we Shouldn't...And Ignore the Things we Should," Time, 26 Nov 2006.

12 Steven Johnson, Mind Wide Open: Your Brain and the Neuroscience of Everyday Life, Scribner, 2004.

13 Daniel Gilbert, "If only gay sex caused global warming," Los Angeles Times, July 2, 2006.

14 Donald A. Norman, "Being Analog," http://www.jnd.org/dn.mss/being_analog.html. Originally published as Chapter 7 of The Invisible Computer, MIT Press, 1998.

15 Gerg Gigerenzer, Peter M. Todd, et al, Simple Heuristics that Make us Smart, Oxford University Press, 1999.

16 Daniel Kahnerman and Amos Tversky, "Prospect Theory: An Analysis of Decision Under Risk," Econometrica, 1979, 47:263-291.

17 Amos Tversky and Daniel Kahnerman, "The Framing of Decisions and the Psychology of Choice," Science, 1981, 211: 453-458.

18 John Adams, "Cars, Cholera, and Cows: The Management of Risk and Uncertainty," CATO Policy Analysis #335, March 4, 1999.

19 Daniel J. Kahneman, Jack L. Knetsch, and R.H. Thaler, "Experimental Tests of the Endowment Effect and the Coase Theorem," Journal of Political Economy, 1990, 98: 1325-1348.

20 Jack L. Knetsch, "Preferences and Nonrevsrsibility of Indifference Curves," Journal of Economic Behavior and Organization, 1992, 17: 131-139.

21 David L. Rosenhan and Samuel Messick, "Affect and Expectation," Journal of Personality and Social Psychology, 1966, 3: 38-44.

22 Neil D. Weinstein, "Unrealistic Optimism about Future Life Events," Journal of Personality and Social Psychology, 1980, 39: 806-820.

23 P. Winkielman, R.B. Zajonc, and N. Schwarz, "Subliminal affective priming attributional interventions," Cognition and Emotion, 1977, 11:4, 433-465.

24 Daniel Gilbert, "If only gay sex caused global warming," Los Angeles Times, July 2, 2006.

25 Paul Slovic, The Perception of Risk, Earthscan Publications Ltd, 2000.

26 Amos Tversky and Daniel Kahnerman, "Judgment under Uncertainty: Heuristics and Biases," Science, 1974, 185:1124-1130.

27 Bruce Schneier, Beyond Fear: Thinking Sensibly About Security in an Uncertain World, Springer-Verlag, 2003.

28 Barry Glassner, The Culture of

Don Norman argues that Google isn't simple at all. Sure, searching with it is, but Google does way more than search - and if you're not looking to search, you're going to have difficulty finding things. It's all argued here: http://www.jnd.org/dn.mss/the_truth_about.html

I think you completely missed the point.

No, I think, sadly you did.

They are suggesting that Google works so well and is so incredibly simple from the end users perspective, because of how much complexity went into the back end.

Don Norman is actually suggesting that Googles front page is so simple because, in the end, it is a one-trick-pony. He describes the hard work needed if you actually want to do something besides searching for a query.

You have to click the section headers (don't click the Vendors link). It doesn't give you a very good indication that there's any sort of functionality hooked into those headers.

To many, this is an indication of bad design. (See affordance.)

Of course, the "bad" in this case refers to usability for new users, not to the visual appeal of the page. The former often takes a second seat to the latter.

These are two guys who have some good stuff to say about usability - Jakob Nielsen (http://www.useit.com/) and Don Norman (http://www.jnd.org/) - Don Norman is the author of 'The Design of Everyday Things', mentioned above.
Also worth a mention is Joel Spolsky - http://www.joelonsoftware.com/

what's with all the dead space around toolbars, blocks of text, etc?

Ever heard of Fitt's Law?

It's also a good thing to display information in a clean, uncluttered. It improves efficiency when scanning the screen for the information you need, and it reduces stress (really!) and makes for an easy-to-love interface.

Right on, brother!

Having to train users to do alien things should be taken as a sign that your system may not be so well-designed

Listen to this man. He knows what he's talking about. Then, if you haven't done so already, read some Don Norman. Yes, well-designed systems do protect users from their mistakes. That's simply appropriate design. It's a tragedy that so few designers understand this, and saddle us with hard-to-use or (in this case) badly dangerous products, and then blame the user when things go wrong.

Not to flamebait, but it would help for getting answers if you formatted your text with some whitespace in order to make it readable...

You might want to read some insightful essays by a usability guru on this very subject, addresing the forces that affect the problem and an existing solution.

Not to flamebait, but it would help for getting answers if you formatted your text with some whitespace in order to make it readable...

You might want to read some insightful essays by a usability guru on this very subject, addresing the forces that affect the problem and an existing solution.

Not to flamebait, but it would help for getting answers if you formatted your text with some whitespace in order to make it readable...

You might want to read some insightful essays by a usability guru on this very subject, addresing the forces that affect the problem and an existing solution.

If and only if you have GIMP 1.2.x or higher, select a painting tool (pencil, paintbrush, etc.). Click where you want the line to start. Now hold down Shift and click where you want it to end.

In my opinion this should go in the Interface Hall of Shame if it isn't there already. What kind of interface designer thinks it's a good idea to make such a simple, common task so difficult to discover? Why couldn't they just have a straight line tool like every other paint program on the planet since at least MacPaint way back in 1985?

If you can find a copy - read Don Norman's "The Psychology of Everyday Things". In it he talks about how we are often ready to blame users for stupid mistakes - but that how the physical design of an object can give misleading suggestions on how to use it.

He discusses the problems with early cockpit design at length, and other problems that when you read it you will recognise them as 'mistakes' you have made yourself at various times and given yourself a smack on the upside of the head for being stupid.

For more information, see:

• review by a usability guru
• review of similar model
• Company site (recently taken over by Logitech)

If *I* looked like that, I'm not sure I'd plaster my face all over the Internet!

If *I* looked like that, I'm not sure I'd plaster my face all over the Internet!

I use the to-do list and calendar in Outlook.
Works for me. Yeah, Outlook, it is a bit of a liability, but its what we have at work. No arguments will be entered into by the powers that must be obeyed.

That said, before you snort cheetos and coca-cola out of your nose, I will remind you Don Norman, the reigning king of usability studies is himself is a fan.

Have you by chance tried the Harmony Remote? It's task based, so for example you click to watch a DVD and it executes all the remote commands for you. FWIW, Jakob Nielsen appears to like it

In fact, UI is not hard anymore (since we don't have to use the Xt object model, the most overengineered piece of object-oriented crap that ever came out of an ivory tower). Instead we have simple UIs and simple object -event models like KDE's components and QT's slots to hide the complexity (most of the time), and vastly more examples of consistent and market-persistent UI designs since back in the day, making UI design and implementation so dead simple the bulk of the time that any barely or even not quite competent coder is without excuse.

If, as you say, UI is not hard anymore, why are there so many applications around with sucky UIs? You seem to be implying the "hard part" of UI is getting pixels on the screen. And you're right -- that was hard, now it's easy.

But good UI design is hard. It is based on psychology and a deep understanding of human cognition. Good UI design is based on solid theory, backed up by formal usability testing in controlled conditions.

Apple has a 20 year history of great UI design because they can afford to hire people like Bruce Tognazzini and Donald Norman. They can also afford to staff a great usability lab, and they take the time to include feedback from the lab in their product's design cycles.

The OSS community needs more people like Tognazzini and Norman.

team they've assembled is smart, inspired and better motiviated ...at making RPGs and FPSs. Looking at the indiagames website, you can see that your programmers culture permits them to understand concepts a few thousand years old, e.g. run around and shoot or slash, or walk around and explore. I'd expect they'd be innovative at magic-centric games as well.

Other concepts, such as sims, real time strategy games, etc. don't seem to be something you don't look to from a third worlder who's only recently "culturally" left rice fields for a PC. Even the developers just seem to lack the clean, intuitive application to a problem, ala Don Norman. Granted, plenty of western developers break these rules as well, but I'll guarantee you'll never sense such counterintuitive interface amusement as you do on a trip to India (where technology is often applied without an understanding of the design principles beneath it). And then there's the whole "designing reliability, consistency and redundancy" which I've yet to see anyone come close to mediocre outside the EU and US. When the elevators and escalators are permantly inoperable at the Caracas International Airport (and throughout offices in the city - and have been before Chavez), don't expect this culture to produce exceptional systems. Look to cultures like the Germans and northern Europeans for excellence here. Culture-based design, while terribly not politically correct and socially unpopular in the states, has real ramifications in system design.

And before you're critical of this perspective, understand you can't rush several hundred years of painful democratic evolution and missteps. Aristide left on a plane today - do you expect Haiti will become a modern marvel overnight? (Instead you might question why they've been a nightmare for 200 years and take a close look at the intrenched mysticism and parasitism beliefs that poison their culture). India has some significant cultural baggage that it will have to work on over time before it can match many western approaches in thinking (and yes, they have elements to offer as well).

Outsource the components to the culture that best fits; mismatch and you'll pay the consequence.

As an interface designer I'm happy on both a professional and personal level to see user-centric design getting press lately. On the other hand I'm afraid that a lot of MBA-types will read articles like this and figure that they can just throw a designer at a problem and expect them to fix everything that's wrong with their product.

Real UI design will not fix fundamental flaws in a product. In fact a good designer will probably uncover problems that no one had noticed before. The reason that Tivo's interface is good is because the entire product was designed from the beginning around being easy to use. I'm willing to bet that there were designers involved in the product from the very beginning.

I recommend that people interested in this sort of thing read Alan Cooper's The Inmates Are Running the Asylum. It's a bit harsh on engineers and I don't buy Cooper's zealousness regarding his techniques but it has a lot of good insight into what can go wrong and how to avoid it.

I also really wish that the press could find a better poster child for our indutry than Nielsen, whose core competency is attention whoring and getting people to pay him thousands of dollars for speaking gigs [something he excels at]. He's got some pretty smart coworkers who have actually designed products that changed the way we interact with computers. Nielsen's crown jewel is a kooky Sun skunkworks project.

Don Norman, a colleague of usability expert Jakob Nielsen (who is quoted in the article), has a great essay about "activity-centered design" and the highly-usable Harmony Remote Control.

The problem with large projects is that they require different skill sets that are usually not present in one single person. Someone might be a good coder, someone else understands a specific (business) problem and a third person is skilled in streamlining the UI. There is a real challenge in getting people whose expertise is something other than programming to participate in community projects of this kind.

Case in point: At the moment I'm forced to use Windows by (among others) an accounting program. I do not know of any Linux based programs that I could use for accounting in Finland, where I live. In order to make one, one would need skills in the local accounting standards (economical), in the Finnish legal system governing taxes etc. (legal) as well as UI design (psychological and esthetical) and programming (technical). It is extremely unlikely that any one person would master all these skills, and have time to spare to code free software.

Your second point about licenses not helping in this problem is most probably correct, though.

And before I accept your point about the GUI not working as an add-on, I'd like to hear what systems you like.

Here I would like to offer another example. I was once working as a trainee for a company making CAD software used in piping. There was a function to make a pipe transparent on one section. Technically it worked by making a 3D box that was clipped out from the model before rendering, thus making the pipe and everything else transparent where the box was. The original UI was just a front end to this OpenGL code and the user was required to give the box anchor, width, height and 3D rotation. It turned out that no user understood about this box and couldn't use it (to use it you would have to think about it like the developer sees it: OpenGL calls, rather than how a user sees it: "I want to see through this pipe). A solution was to allow the user to just click the pipe that was to be cut (at the position to start cutting) and another click to show how far to cut it. This redesign, of course, required a redesign of the code - which goes to prove that UI design should be done at an early stage if you want a good product.

Some of the UI gurus advocate the extreme version of this with the workflow: design the UI first, write the manual second, and implement it last. This of course depends on what you are building. I assume you have looked into the UI literature if you are into making things more usable. If you haven't come across them yet, Nielsen and Norman provide some interesting text on the subjects discussed above. A lot of Normans texts are available here.

Conventional wisdom suggests that the people who had been paid more would be more apt to change their minds, but actually, the reverse was true. The explanation is that the people who were paid could resolve the conflict in their mind between the beliefs they held and the contradictory statements they were writing by saying "heck, I still don't believe this, I'm not writing it because I believe it or anything, I'm writing it because I'm being bribed to." But the people who didn't have that "out" had to resolve their own cognitive dissonance another way, and for some of them, at least, the way was to realize that maybe there was something to the counterargument, after all.

Anyway, the reason I bring this up is that I was eerily reminded of it while reading Ballmer's arguments that Microsoft's commercial software is "obviously" better because it's written by professional programmers who are paid for it.

But if you're getting paid to write code, and the code is (for whatever reason) crap, that you can't take pride in, you can at least feel good about all the lovely $$$ you're being paid. The open source programmer, on the other hand, who is doing it for love rather than money, doesn't have that out, so has a much higher incentive to write code that's not crap, because feeling good about it is the only reward.

I recognize that some of the tasks we perform with computers are inherently complex. However, I think the emphasis must always be on improving the user interface so that a lifetime of training is not a prerequisite to, say, burning a CD. Donald Norman's Design of Everyday Things provides an insightful perspective on this issue. For example, a door that requires an instruction manual, however short ("Push" and "Pull"), is poorly designed.

His Invisible Computer is an interesting comparison of computers to motors. Motors used to be expensive, so a household would rarely own more than one, to which several proprietary peripherals, like sewing machines, could be attached. Today, of course, we wouldn't dream of buying a blender that required a separate motor. Likewise, computers are making the transition from expensive mainframes ("I think there is a world market for maybe five computers") to emedded devices.

that somehow all the employees are (by this same magic) supposed to be proficient

I see lots of computer techs say things like this. Stupid user, doesn't he know how to xxxxxxx....

That's one reason why Linux is not ready for the desktop, and most software on all platforms sucks. The user shouldn't need to be proficient. The software should be designed to make sense.

It's fine to have cryptic compilers and command lines for those of us who use them. I personally hated the Mac until OSX came out because of the lack of a command line. But I'm a developer - if you want a system to be useful to people with other professions, design them to make sense in the terms familiar with the user. Otherwise you're just catering to yourself - cool, but it doesn't make it ready for the masses.

I'd highly recommend reading Don Norman's works on useability and engineering for anyone designing anything for use by others. GUI Bloopers by Jeff Johnson is another favorite for making things make sense to others that aren't coders or techs.

The simple point is - there are professions other than computer programmer/administrator/tech. Software should, in most cases, be designed for those other professions. And you shouldn't have to drop a lot of money to train people to use good software past the "this is a mouse - it moves the pointer" stage.

Simson Garfinkel eventually became a hermit and withdrew from public life after too many people mistook him for Art Garfunkel. He now lives in a cave in southern California.

Daniel Weise went on to work at Microsoft. He distinguished himself as the first non-Samoan to ever pick up Bob Barker after winning the Showcase Showdown on "The Price Is Right."

Steve Straussman (no website, sorry -- anyone?) left the Unix-Hater's list after it was revealed that he had fallen in love with a woman who loved Unix. He has come to terms with the past, and now teaches "How to Shell Script in Linux" classes at his local community college.

John Klossner went on to a successful career making cartoons for Lucas' Skywalker Sound company newsletter, until fired for printing one that suggested an unnatural intimacy between Luke Skywalker and Chewbacca.

Donald Norman won the coveted "Golden C< Prompt" award and retired from public life.

Dennis Ritchie became something of a celebrity on the web for his many and varied contributions of photos to Engrish.com.

Scott Burson became a monk and moved to Iceland.

Don Hopkins ran for office in Lousiana and lost. He is now a semi-successful insurance salesman, and plays harmonica regularly.

That was all I could find out about -- anyone got any more?

A couple points:
for sake of argument, yeah. Paintings are useless. Compared to a basket, say. But that's oversimplifying. Rarely are paintings /purely aesthetic/. Painting is a communicative medium. Saying that isn't all that far off from saying speech or writing is purely aesthetic.

2nd: the art/craft argument is similar to an argument I have with art/design. (if "art" is /purely/ aesthetic, it's more /design/ than it is /art/) Back to painting, though. Look at what most people immediately think of when they think of painting - the Rennaisance master painters. They exhibitted a high level of craft. (and, to be sure, a number of them hired "code monkeys" to do some of their painting)

on the combinations of aesthetics and functionality: Emotion & Design: Attractive Things Work Better by Don Norman. This article got me pretty angry, 'cause I don't tend to agree, but he makes a good case.

Pottery: since I'm not terribly familiar of art references in basketry, I'll switch the example to this. /Plenty/ of non-functional elements of crafts don't "express their object's function visually" - look at Greek vase-paintings. These clearly aren't art, because the vases serve a functional purpose - but no art historian denies that they /are/ art, nor would I think anyone else who looks at them. And architecture - look at gothic cathedrals, or any other cathedral for that matter. Plenty of the non-functional elements of these have nothing to do with expressing their functionality visually - these cathedrals are works of /art/ using the /craft/ of architecture as their medium.

So, my point: just because art is useless (though I think art's communicative aspects leave that statement on shaky ground), and programming is functional, doesn't mean that there has to be a clear division between the two.

I can't find the article, because the link now seems to be broken, but Donald Norman has/had quite a lot to say about the interface of aircraft cockpits in his book "Things that make us smart".

From memory though, he was mostly impressed with the current evolution of aircraft control panels rather than scathing of them in any serious way. Among other things, the large and mechanical controls have an important side-effect of aiding communication between the pilot and co-pilot and what each of them is doing at any given time.

His main negative comment, which I think I agree with in principle although I'm not a pilot, was that some of the dials had several needles, and they weren't automatically intuitive to read. Looking at them had to be learned, and it wasn't so much of a surprise that many accidents in the past have been caused by things like pilots mis-reading the altitude indicator.

Much of this could be fixed (in theory at least) by using digital numeric displays instead of dials, but there are other problems. Also base 10 numbers made from arabic numerals arguably aren't intuitive. Interpreting ordinary numbers is another thing to be learned, and although virtually everyone in modern society can read numbers, there have still been measured differences between looking at a number and interpreting what it stands for.

Getting a glimpse of a four digit number could mean something comparably big (9111) or comparably small (2111). Compare this with a graphical representation of the numbers using bar comparisons for example, and there's instantaneous recognition of the meaning without all the brain processing that needs to go on.

Perhaps this is what the intent of the article is

• Understand the causes of error and design to minimize those causes
  
• Make it possible to reverse actions, to "undo" them, or make it harder to do what cannot be reversed
  
• Make it easier to discover the errors that do occur, and make them easier to correct
  
• Change the attitude toward errors. Don't think of the user as making errors; think of the actions as approximations of what is desired
  

At least you are making a claim about Dvorak that perhaps makes sense (contrary to popular belief, Dvorak layout does not lead to superior typing speeds - see this)

As for Dvorak and keyboard pain, I don't think there have been any scientific studies, but lots of people think it does help and often any sort of change helps RSIs.

At least you are making a claim about Dvorak that perhaps makes sense (contrary to popular belief, Dvorak layout does not lead to superior typing speeds - see this)

As for Dvorak and keyboard pain, I don't think there have been any scientific studies, but lots of people think it does help and often any sort of change helps RSIs.

By the looks of it, we still have some way to go until AI in games reaches the 'good enough' stage.

Good enough for what? For us to stop speaking and caring about it I guess.

When that happens, we'll have 'Invisible AI'* that just works, and game producers can no longer use it as a selling point.

Of course, I guess that won't happen anytime soon, and I can already see hardware manufacturers making AI-accelerator cards, with built-in multi-processors and neural net chips, to fit next to your graphics card. The 'Intel Inside' logo will gain a whole new meaning...

* - Yes, I'm adapting Don Norman's Invisible Computer term.

Posting from Mozilla on Window Maker on Debian, I have to say that his user interface comments are way off the mark. Free Software is free to combine the best interfaces with the best answer to any particular problem. Sure, that makes for some inconsitency as the right tool for the job is never a universal. Just the same I've gotten used to the particular interfaces I like and now think of them as far easier than the M$ junk I use at work and even Apple stuff. If he wants to be the tyrant of an interface, he's welcome to make one or even to simply make some constructive comments. Oh wait, I see, he and the people he works for consider such stuff "intellectual property" that can be owned so that best practices never go very far.

His website would benifit from a more modular approach. Everything is thrown out in one big long scroll down page. Stuff like his background should be a link to two kilobytes of text with links instead of a too short to be useful with no links paragraph. Recent articles and publications should also be links. The sidebar is full and distracting rather than informative and useful. Why would I take this man's opinion about software design seriously when his site so clearly misses the pull nature of html? Oh wait, now I see, he thinks of his web page as an advertisment rather than a means of sharing information.

I'm starting to see a patern and it's name is greed. The things he bemoans are the direct result of his own way of thinking. The only thing he gets right in the article is that many cheap gadgets have poor interfaces. Who is not sick of having to read a manual to learn how to use yet another black box that is a toaster or microwave oven? This has little to do with software design and his mixing the two up is the result of ignorance or malice. His ingorance of the world of free software is less than forgivable from a design expert. His disparagement of software licenses that give the user the ability to run software for any purpose, modify that software as the user pleases and share those modifications, is likewise the result of unforgivable ignorance or malice. Take the blinders off, Don, you might like what you see.

As Donald Norman has commented, if lots of people use something incorrectly there is probably a problem with the design, not the people. I will admit to having on more than one occassion typed "less readme" instead of "less README" or scrolled through a file listing and overlooked a file that was sorted elsewhere due to capitalization.

Even worse is the fact that subparts of an item follow different rules. For example:
http://slashdot.org/index.html == http://SlashDot.ORG/index.html
due to required case-insensitivity of domains,
http://slashdot.org/index.html != http://slashdot.org/Index.html
unless the underlying OS/web/app-server chooses to interpret them as equivalent.

As some have commented, everyone sees a difference between joe doe, Joe Doe, JOE DOE and jOe doE but they all know that in every case we are referring to the same person. In fact many places standardize on all-caps for the family name in forms and documents to reduce errors.

To those who say that the problem should be solved on the application level: consistency is good - a user should not have to remember the quirks of each application. Even if one is a slave to point-and-click GUIs there are problems created by sorting and the possibility of multiple files with the "same" name.

Windoze is also brain dead. Although it is case insensitive, it also changes the case of file names in one of its many misguided attempts to "help" the user.

My preference would be to have the OS keep the filename in whatever form of caps/lowercase that I choose but to treat files in a case-insensitive manner.

I've not wasted a couple hours yet, but the Essays I have read are quite insightful... I'm especially fond of the one titled "in defense of cheating". My wife has her degree in education and is homeschooling my 5 year old son, I'm going to have her read them and give me an educator's perspective on them. I think that the concepts are more intended for a higher education but I'm curious if she will come up with methods for implimenting them into an early childhood classrom. His assertions of attractive things working better and his corresponding defenses are very interesting as well.

"Yahoo-style" design is great for a directory, where the volume of information is such that speed and "cleanliness" are paramount: nobody expects the White Pages (or the Yellow Pages) to evoke oohs and aahs for their design: we expect them to be efficient, no-nonsense directories. But the design of other types of sites (or other software, or hardware for that matter) can be more complex, especially if one is creating a new interaction model and has precious few (if any) precedents on which to base one's design.