Mac OS X UI Hall of Shame

I found a Mac OS X UI Hall of Shame. The site describes itself like this:

Mac OS X, Windows and Linux/UNIX desktop managers such as Gnome and KDE have a similar purpose and, as such, similar shortcomings. This site is designed to be a source of “dos” and “don’ts” for interface designers and application developers. The main section of the site is dedicated to various specific GUI issues that can be found in many places in these systems. The second part of the site is a showroom of examples of bad GUI from various popular applications available for various operating environments.

Even with CSS, frames suck

Asa has apparently decided it is a good idea to ignore or downplay complaints about the usability of his blog. He writes:

Some folks are complaining that my site doesn’t provide the same experience for folks on low-resolution systems. They’re right…. If … you can’t cope with the links over to the left not all showing up in your browser because your resolution is archaic then you’re in luck. I’ve constructed a special version of this site just for you.

[He then provides a link to view the source of the page.]

What he describes is a common problem with framed pages: web designers will set frames to have no scrollbars and just pretend that everyone uses the exact same screen resolution and font sizes that they do. This frequently causes inaccessible content just like that seen in Asa’s blog. But Asa isn’t using frames, he’s using the shiny new CSS (validated no less!) that is supposed to cure world hunger and bring world peace. Or something like that.

The problem is that CSS position: fixed elements (those blocks that act like frames) get overflow: visible by default. If they had overflow: auto they would get scrollbars when necessary. Asa could easily fix his blog by adding overflow: auto to the .leftcontent class in his style sheet. I hope he does. I understand people blog for the fun of it and that you can’t please everyone, but this is a trivial change that doesn’t fundamentally change his design.

It troubled me that at least with old framesets, if you didn’t do anything special, the default was to get scrollbars automatically if they were necessary. With the CSS replacement, you now need to add both position: fixed and overflow: auto to get the same behavior. I suspect that many designers using position: fixed will, because of ignorance, arrogance, forgetfulness, or by design, omit the overflow: auto and therefore create sites that have accessibility problems. This prompted me to file bug 164983. Too bad this isn’t a technically feasible solution. In bug 105796 mpt made a similar suggestion which would also help with frames.

I find it ironic that because IE doesn’t apparently support position: fixed, Asa’s blog is more usable in IE.

Responsiveness vs. Performance

An IBM developerWorks article discusses design and implementation considerations related to Progress Indicators. The article distinguishes between responsiveness and performance. Responsiveness is how quickly an app acknowledges and indicates acceptance of user input. Performance is how quickly it completes a task and displays the final results. A more responsive app contributes more to user satisfaction than quick performance by itself. A quick response can make the application feel faster, even if it takes longer on an overall task.

“Progress indication is needed because: (1) there are inevitable limitations in UI performance, that is, there are always cases where the user will have to wait for a final result, and (2) increased UI responsiveness, or improved communication with the user, can make the wait more acceptable to the user.”

I noticed the other day that the throbber makes Mozilla feel responsive. It activates immediately after clicking a link or entering a URL. The progress indicator in the status bar only seems to show up after a fairly lengthy period of time. For those that want to eliminate the throbber completely, this points out the need for better responsiveness in the rest of the UI.

The article is packed with practical and specific information. All designers and developers would do well to carefully consider the information in this article and how they could improve their application’s responsiveness.

Validators can’t

Ian Hixie provided an insightful quiz to show that there’s more to writing proper markup than running it through a validator. The answers are educational and identify several common misconceptions about which tags are required and how tags should be used. Proper and accessible pages take work beyond what a validator can easily check.

I was happy to get 4 out of 4 in a minute. The errors seemed obvious to me, almost as bad as someone using the <a> tag just to create underlined headings. Based on the results, there’s a lot of educational work to be done to teach people how to create proper markup. The quiz also makes it obvious why automatic conversions from a non-markup format (such as Word .DOC or Adobe Acrobat .PDF) to a markup language generate such poor results.

Inductive User Interface

Technical writers can make a tremendous difference in the quality of a product if they are allowed to provide feedback early enough in the process. Apparently Microsoft is making this more official with their new UI guidelines for their inductive design. Fascinating. I have noticed that web interfaces are influencing traditional software interfaces. It seems to be a good idea when this involves embedding help text (tips, hints, short instructions) right in the interface, especially since no one reads the documentation. Writers are quite sensitive to complications in the UI even when they cannot suggest a good way to solve the problem. At the least, they tend to write things that make more sense than the typical programmer-speak.

Usability and Beauty

Don Norman is working on a new book, “Emotion & Design” which will explore the roles that beauty and emotional impact play in the usability of designs. His site has a number of essays related to this topic, including Emotion & Design: Attractive things work better. One of the interesting points raised in the essay is that we use our emotions to make good/bad or safe/dangerous evaluations of the world, while we use cognition to interpret and make sense of the world. In stressful situations, the emotional aspect of the design can improve its usability. In short, “Attractive things work better.”

Given the horrible usability of many products, it is easy and understandable for design professionals to be stuck on the basic plain-and-simple functionality and ignore the beauty aspect. Norman emphasizes that the usability is still important–this is not just about prettiness:

There are many designers, many design schools, who cannot distinguish prettiness from usefulness…. True beauty in a product has to be more than skin deep, more than a façade. To be truly beautiful, wondrous, and pleasurable, the product has to fulfill a useful function, work well, and be usable and understandable.

May we have more products that are beautiful to look at and pleasurable to use.

Extreme programming vs. interaction design

After reading my earlier Jon Udell and Alan Cooper blog entry, Basil dug up an interesting debate between Alan Cooper and Kent Beck. They are discussing the differences in process between extreme programming techniques and interaction design. At times I feel they’re speaking different languages, but I feel like Cooper generally has a better understanding of the software development process than Beck does of interation design. I believe Cooper won the debate, but then I believe in interaction design as a way to improve the quality and usability of software.

Going to extremes

Jon Udell talking about his question to Alan Cooper: “Is there no hope that interaction design can itself be made interactive, with the assistance of software? He doesn’t rule out the possibility, but thinks that useful interactive prototypes are unlikely and, in any case, unnecessary … It’s extreme design versus extreme programming. I don’t buy either one completely. Call me an extreme anti-extremist.” More…