Zen rock gardens, accessibility, information architecture

I was walking into work this morning, thinking about 1st, 2nd, 3rd orders of order (“Everything is Miscellaneous” by Weinberger) and came across a frozen pond. The pond is shaped like a teardrop and has three clumps of grass growing from it. As I considered the space between the clumps of grass, it reminded me of a Zen rock garden, with fine white gravel raked into patterns and larger rocks placed within.

I had a brief conversation yesterday afternoon about a website whose scope drastically changed. Instead of considering an audience of a few hundred people and serving about a dozen stakeholders, it may now serve tens of thousands of people, and our definition of who is a stakeholder sort of went out the window.

It is too late to reign it in.

We have an initial launch of mid-April, and we will only deliver a very small portion of what this site may become.

Organic does not mean irresponsible

The person I was conversing with heard my concern at what this change means for the information architecture of the site, and responded that we can’t know where this will go, and it will simply have to grow organically. I agreed, but asserted that we can still try to imagine what the site will look like in the future.

The word “organic” is sometimes a euphemism for “I don’t know what will happen, so I give up. Let it be what it will be.”

Organic does not mean wild and untended. In a design sense, it seems to relate to an out-of-style phrase, “form follows function.” Farmers who grow organic crops still have furrows in their fields.

I pictured this website on the one hand as “organic” in the loose, wild and untended sense. I have seen information that has grown “organically” like this and it is very much like a field of weeds, unfit for harvest. Those of you who have done a content inventory of a site that hasn’t been reworked in years know what I’m talking about.

Utopia: IA as rock garden

On the other end, imagine an information architecture as ordered and spacious as a Zen rock garden: Beautiful to gaze upon, rich in hidden relationships, all in view at once, yet different depending on where you stand around it.

The accessibility connection: tactile rock garden for the blind

An aside, I was looking at picture of Zen rock gardens, and found this example of one that has an accompanying tactile rock garden for the blind. Scroll down to the “Ryoanji” heading.

Usability in Packaging

A couple evenings ago I attended a presentation by Laura Bix from the MSU School of Packaging. The presentation was about how Laura and a couple of her graduate students have been employing user experience design methods in the package design process.

The short of it is, they’re doing great work. I appreciated seeing usability work done in a field different from my own.

Of the many different examples they showed, one concept really stood out to me as a nice application of thinking about human factors: That is, the design of child-resistant medicine bottles. (Or did they call them vials? Packaging jargon escapes me.)

Laura and her student co-presenters showed usability tests of people from different age groups trying to open a push-and-turn style bottle. What seemed typical was that the people in their 80s had a lot of trouble opening the bottles. In one case, a woman reported resorting to cutting the bottle open with a serrated knife. Meanwhile, there was a video of a little girl, perhaps four years old, who had the bottle open in about 10 seconds. So, more like elderly-resistant than child-resistant.

The presenters offered the notion that the human factors used in the design of the typical push-and-turn style bottles are dexterity and strength. Based on testing across different age groups, they suggest that those two factors can’t really be used as a differentiator between the elderly and children.

Instead, they researched anthropometrics, which I took to be the measurements of the human body, such as the distance between the tip of your forefinger and thumb when you spread your fingers out or the lengths of your phalanges.

The physical dimensions of hands are noticeably different between adults and children, so that factor may have much more potential in the design of a child-resistant bottle, than dexterity and strength.

Their presentation made me think of two notions from the usability realm:

  1. the usability heuristic of error prevention (I’ve recently seen this principle referred to as the poka-yoke principle, attributed to Shigeo Shingo from Toyota)
  2. the similarity of why a CAPTCHA works

One of the design requirements of a child-resistant bottle should be that a child can’t open it, without resorting to extreme workarounds (such as cutting it open with a knife). I see this as the poka-yoke principle in that, just like you cannot physically plug your USB cable into your Firewire/1394 port, so there should be physical aspects to the bottle design that prevent children from opening it while allowing adults. I’m sure the packaging people appreciate how this is not a simple challenge.

Related, a CAPTCHA (you see the warped letters that you need to enter all the time with online forms, like blog comment entries or when you sign up for services) operates by asking you, a human, to answer a question that will be fairly trivial for you to answer correctly, while it would be confounding to a computer system, like a character recognition software. The point is, the CAPTCHA tries to guarantee that only humans can enter data, not automated systems. So, just as a CAPTCHA tells humans and computers apart, so part of the design challenge for the packaging people is to devise a system that can be trivial for an elderly adult while confounding to a child.

Hats off to Laura Bix and her grad students (sorry guys, I’m blanking on your names…Joe and Javier maybe?) on the great work they are doing, and presenting for the MIUPA event.

What does it take to be an evangelist of good interface design?

Reference: The Art of Evangelism, Guy Kawasaki

Here are Kawasaki’s list of ten ways of looking at evangelism and my interpretation of them as someone who might be an evangelist within an organization for good interface design.

1. Create a cause.

We need to do good interface design on our products, because it makes life better for our customers. And for our sake, our customers judge us by the interfaces we provide them.

The interface is *the* medium that customers use to interact with our products. As such, the interface in turn becomes the application.

A product with great SQL queries and OOP architecture but a bad user interface is like a computer with a smoking processor and 2 GB of super fast memory, but the keyboard randomly enters the wrong character and the display is 10 inches, monotone, and at the wrong height.

Given a great application behind the scenes, if the interface sucks, then the application also sucks. If the interface rocks, then the application also rocks.

2. Love the cause.

I love good design. I study it. I notice and share good design when I run across it. Badly designed applications are caustic to me; they make me sick (seriously) and give me motivation to see them made right.

I hear talk of interface design and usability, sometimes synonymously. To avoid confusion, let’s put usability in its place–usability is not the end of design, it is one requirement of a great design. Usability is roughly defined as how easy it is to use a product. Design covers visceral, behavioral, and reflective aspects of a design, and usability is a piece only of behavioral design. (Refer to “Emotional Design,” by Donald Norman.)

3. Look for agnostics, ignore athiests.

Who can argue with good design; who are those athiests? Well, for one, they may be developers who see the true value of an application within the actual programming of the application. There is undeniable value there, but it is virtually invisble to customers. For another, there are some usability nuts who firmly believe that the best a design can be is usable. They’ve sold the product short, dismally so. For evidence, I point to the usable, but fairly ugly useit.com, Jakob Nielsen’s website.

To get people within an organization to hop onto the “we need to do good interface design” bandwagon, look for those people who haven’t really known what to think of it yet, who are open-minded. As the culture shifts, the rest will come along (cross your fingers).

4. Localize the pain.

Bad interface design results in painful things. Namely, too many support requests; frustrated customers on the phone; disenchanted end-users, who, incidentally, do not praise your product to their peers; customers who jump-ship to the competition because the grass looks greener.

There is also subtle pain for developers, I believe, and that is the lack of an ability to truly believe that they have contributed to the best application of its kind in the world. How confident are the developers in their apps? Are they rightly proud of the accumulation of their work?

5. Let people test drive the cause.

Believers have an experience. For good design, one way to provide that good experience to people in the organization is to have them look at before and afters of designs that once looked like their own work, to designs that could resemble their future work. Let them imagine, based on concrete examples.

One example could be the Paypal before/after by 37signals.

6. Learn to give a demo.

One great type of demo for use in production teams is to run sample user-tests with the development team. The test user should not be of the team, but could be someone else in the organization who isn’t as familiar with the product. The developers should play a role in the test, as observers. By taking part in a user-test, developers can begin to actually see how a design process can directly feed into the work they do.

7. Provide a safe first step.

Small, easy changes across an interface can turn into disproportionalely large rewards. Identify those short term, quick wins and take them. Savor them as evidence that the cause is indeed worthy.

8. Ignore pedigrees.

Evangelizing good interface design within an organization needs to happen at all levels. It is a value-shift of the people who work within the organization, and it will happen over time as a community. There must be top-level support, but we’re after belief and conviction, not compliance.

9. Never tell a lie.

One of the beauties of interface design is that it is a continual quest for the truth of an application. As an interface designer, there are some aspects of a design that I’ll feel comfortable tackling on the spot, because of my experience with other similar interfaces. However, there are so many variables, I have no trouble saying, “I don’t know how to handle this one. Let’s figure out a test scenario for ideas.”

10. Remember your friends.

We’re part of a commmunity that crosses our own boundaries of roles. We are not just developers and members of the organization, we’re also the end-users. Our family members, neighbors, and friends might be the users at some time. Part of the value of interface design is humility. What I think as a designer/developer does not match what our users think. Thus, good interface design hinges on an honoring of others and the ability to listen and see what is really going on, not just what we think is going on.

Techie error text

Techie error text, wireless authentication

As I logged in to a local coffee shop wireless network, I got this message. I took a snapshot because I thought the error text was telling. Clearly, a programmer wrote it.

Else you can always goto following url to logout…

Here’s the thing: nobody actually says else and goto isn’t actually a word. And, instead of url, why not just say, Or, you can logout at

UX is a quality, not discipline, thoughts spurred by Peter Merholz

I thought this post from Peter Merholz was a nice philosophical step-back for usability.

User Experience is a Quality, Not A Discipline

One of the things that has been hard for the “usability community” to accept is that usability is not really interesting in and of itself. And that usability isn’t really a goal, and it’s definitely not the end-all be-all. Usability is simply a quality. It’s an important quality, but just one of many. And it definitely doesn’t warrant being a “discipline.” [More]

Kind of goes with Tufte’s observation that a superbly usable site does not equal a superbly designed site. Extend that thought with this post and you get the idea that a high level of usability is a quality of a superbly designed site (or, a site that provides great user experiences).

Useit.com: Usable, sure. Pretty, nope. My experience at useit.com is never that great because I don’t feel good about the visual design. I always find what I came for, but I am never inspired to do greater work or humbled at the work of a master.

Features of robust dynamic menus

There are many fine examples of dynamic menus, menus that display sub menus when you hover your mouse pointer or bring focus to them in other ways, such as tabbing through links with your keyboard. I was reading a recent article on AlistApart.com regarding hybrid CSS menus, and the discussion that followed the article showed a real demand for a robust, cross-platform, accessible, dynamic menu.

Here are some features the menu should have:

  • Be written with web standards: valid xhtml, ECMAScript, and css. (There are some nice flash implementations out there, but they have accessiblity issues.)
  • The menu should degrade gracefully, allowing site visitors to navigate even when scripting is turned off in their browsers.
  • The menu should work well for people using a mouse as well as people using a keyboard.
    • When a user tabs to a main link, the sub menu should appear as though the user hovered over it with a mouse.
    • And users should be able to tab through the sub links as well.
  • The menus should work well in all mainstream, current browsers (i.e., it doesn’t need to work with Netscape 4.x or it’s peers).
  • It should allow for text-zooming, and it should remain useable when the font size triples.
  • The menus should be built with usability in mind. They should be as easy to use as possible, from a purely interface perspective. For example, the links should be easy to click on, and it should be easy to navigate a sub menu without accidentally closing it. (Review Fitt’s Law for some principles.)

I’ve seen menus that support these features, but none that support them all. In fact, Adam Richardson (business partner) wrote a very nice menu system that worked well with keyboard tabbing as well as mouse events.

Related resources:

There are many solutions implemented out there, some better than others and very few that I’ve seen have been flawless. When I get some spare time (ummm), I’d love to take a crack at this. Anyone else have a menus system that matches up to the features list above?

Fitt’s Law Applied to the Web

Fitt’s Law Applied to the Web by Scott Berkun, Microsoft Corporation.

The basic idea in Fitts’s Law is that any time a person uses a mouse to move the mouse pointer, certain characteristics of objects on the screen make them easy or hard to click on. The farther the person has to move the mouse to get to an object, the more effort it will take to get to. The smaller the object is, the harder it will be to click on.

This is a pretty clear write-up on Fitt’s Law. Recommended reading for web designers.