I just discovered visualcomplexity, a catalogue of over 600 visualizations. There are a couple of really great finds. The best visualizations reveal the underlying structure of the data but without sacrificing the complexity and show artistic beauty and elegance.
Other catalogues are mentioned at the coding horror weblog. It seems the developments in visualizations have gone really fast. Some of the older examples already feel, well … old.
I really like Phatch. It’s an elegant piece of software for batch processing images (its name is a contraction from photo + batch). Open source, in active development and quick to learn and friendly to use for tasks such as making thumbnails for a directory of photos, or adding round corners and drop shadows. And cross-platform (linux, windows and mac).
As I said, I am very enthousiastic about this tool. However, I had a small annoyance. The opening screen looks like this (I didn’t capture the screen borders, but imagine a standard title bar and window frame):
Three active buttons in the toolbar. A green horizontal bar with a hint text and a nice picture of a box with tools. continue reading…
A simple navigation structure in a wordpress weblog, typically found at the bottom of the landing page:
So obviously it makes sense to have links at these places pointing to a mysterious “next” and “previous” place. In most cases at least. Weblogs are a little different.
How many items can a category contain before it grows too big and should be split? Long lists are overwhelming and confusing. But it can be very easy to get lost in hierarchies with subcategories, several layers deep.
In 1956 George Miller wrote The Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing Information. A great paper, but unfortunately often misunderstood and misused. The number 7 is not a limit for the number of items a category on a website should contain for the number of submenus in a menu.
There are a few different types of relationships in hierarchies. Apples and oranges both belong to the category fruit. Horses and dogs are both animals. These relationships have a clear direction: it makes sense to say “every horse is an animal”, but “every animal is a horse” is clearly nonsense. Objects can be classified at different levels of abstraction.
continue reading…
In reaction to this brainstorm idea about the icon for Evolution in Ubuntu, I wrote the following:
As long as Evolution is the default mail application in Ubuntu, the current (envelope) icon works better. The icon serves two different purposes:
1. Tell a user what the program does that is run if he clicks on it (in this respect the original evolution icon clearly wins).
2. Help a user find his way to an application that is suited for the task the user wants to do. In this respect any default mail application should be clearly labeled as such, without clutter from other, secondary features.
In this case I think it’s more important that a user can find ‘the’ email application quickly so I wouldn’t change the icon. It would be a whole different case if Evolution wasn’t the default mail software.
In general it’s always a trade-off. An icon serves as a road sign, and should help the user to find the function or program he needs. To achieve this, an icon should be clear, unambiguous, yet give complete information (or at least complete enough). This can be complicated, as icons never work in isolation (and should always be compared to both similar icons and icons for similar functions).
In the domain of usability, much attention is given to user satisfaction, intuitive design, ease of use and so on. This certainly has its merits and results in easier to use user interfaces, more satisfied users and in the end more sales revenues. A problem with this approach, though, is that it is biased towards novices and against experts. Simply put, the jobs done by specialists (often after years and years of training) are neither simple, easy nor intuitive. The tools they use are highly specialised, and only useable by specialists.
If the system as a whole (user + tools, in environment) should have high quality output, usability criteria should be focused on expert behaviour. The standard values of ease of use, subjective satisfaction and intuitiveness are all less important in this setting. A steep learning curve is not a problem, as long as the investment pays off in the end. In this respect it should be noted that learning processes are often not linear. In many domains early success is followed by a plateau phase or even a temporary decline in performance. Good design should take this into account. It is possible that a product that is moderately useful for beginners and unworkable for intermediate users has the best results in the expert group. Would that be a good product? I would think so.
However, designing for non-experts is easier in some respects. Product designers or usability experts can easily relate to novice users, but cannot easily become experts in the product-specific domain. Their own expectations influence the whole design and testing process. Getting real users for testing is more difficult as well, since experts are few and expensive.
Earlier this week I went to an ATM to deposit a check. The procedure on the new Green Machines is pretty straight-forward. Select ‘deposit’, enter the amounts, choose account to deposit to, put your deposit items (checks or cash) in envelopes and feed those envelopes to the machine.
In this procedure I found two minor problems, both problems with affordance. Affordance is “a goal-relevant description of the world that describes an opportunity for action defined with respect to the capabilities of a particular actor” – definition found in ‘Cognitive work analysis’ by Kim J. Vicente, originally from J.J. Gibson. The key term here is opportunity for action. Affordance describes what an actor can do with an object (and related: what one thinks one can do, and what one cannot do). A classic example is pushing or pulling a door: if there is no handle but only a plate the door doesn’t afford the action ‘pulling’.
Back to my ATM. The first problem came up when I was asked to which account I wanted to deposit. I was given three options: checkings, savings and visa. Upon selecting ‘savings’ I got an error message: “invalid account”. I tried ‘visa’ and got the same message. Fortunately, the checkings account was not considered invalid.
My second problem was a little different. I put my check in the envelope, sealed it, and found the right slot on the machine. So far, so good. But when I watched my envelope disappearing into the machine I noticed there where 3 little arrows printed on it, not facing the machine’s way but mine. It clearly suggested I had done something wrong! The good thing is that it didn’t come back and I got my money. The bad thing is that the machine gave me wrong expectations, I really expected having to give it another try.
Lessons taught by this green machine:
For software products pay attention to suggestions of clickability, drag-and-drop behavior, and temporarily disabling buttons when their associated actions don’t make sense. Little things to make a user-friendlier product.
