blogger counters

Friday, January 05, 2007

Users are Idiomatic

I recently had a discussion with J.D. Meier about user interfaces. During that discussion, I was talking about how users aren't consistent in a way that programs would define consistency. I've been having this discussion for years because of lessons I learned while writing the Norton Commander. Back then I discovered that in order to make an application "feel" consistent, the code need to include many special cases. But I've never had a succinct way to describe this.

But during my discussion with J.D. yesterday, he mentioned idioms and models and I realized that that's really the issues. Model-based design uses models to help create the design, and that's useful for many things. However, users, by nature, are not model driven--users are idiomatic.

One of the definitions of idiomatic, from the Merriam-Webster dictionary is this:

"peculiar to a particular group, individual, or style"

There are actually several aspects to viewing users as idiomatic.

First, different users will have different definitions of "intuitive." So when designing software, you need identify the different groups to understand what they're expected. But to make it even more interesting, individuals tend to jump from one group to another on a whim, so this process is by no means an easy process.

Second, and this isn't conveyed directly by the definition of idiomatic, users actually expect inconsistent behavior. Let me say that again. Users expect inconsistent behavior. What I mean by this is that code that "feels" correct to users typically has lots of special-case code to make the interface feel natural. As an example, going way back to the mid 1980s with the Norton Commander, I had scroll bars for a file viewer. In these days the thumb of the scroll bar moved by an entire line at a time and only had 23 possible positions. The usual approach for positioning the thumb is to calculate the percentage into the file and use this for the thumb position.

But imagine for a moment what happens when you have a long document. You page down several times and the thumb hasn't moved at all. Makes sense, right? You're probably thinking about the math when you answered that question. However users for the most part aren't familiar with the principles that lead to the code that controls the thumbs position. Instead, they're probably expecting the thumb to give them some indication of where they are in the file. One common reaction was that they must be at the top of the file because the thumb is at the very top.

So what I did was add some special case code that would move the thumb away from the top the minute you scrolled away from the top-most line of the file. Likewise, the thumb would not be at the very bottom until the last line in the file was visible. In between these two positions the thumb position was proportional.

This type of special-case code is what makes a program "feel" right to a user, but it often drives programmers nuts. My libraries were used by the people who wrote Norton Utilities 5.0. One of the first things they did when they started to change these libraries is to remove these special cases because they were "confusing" to users. The actual fact is that they were inconsistent by design. The inconsistency was in understanding that users views and "models" often do not map well into logical models because users are idiomatic. 


At 7/17/07, 5:23 AM, Blogger Brad Browne said...

Hi John,

Great post! I have recently been thinking about Idiomatic Design with regards to Personal Finance Software and how to break the mould of detailed micro-management of finances [think: Quicken/MS Money] to work with the user to get more value in less time.

I have used Quicken for quite some time, and I am sure that there must be a better way!

With that in mind, I recently stumbled on YNAB Pro, which I really took a liking to, because it changed the way I think about spending from an historic view [what did I spend money on this month ?] to a planning [how will I spend my money this month ?] view.

So instead of focussing on the past and assuming that will change your cash-flow when you look at reports generated from that data, it uses past transactions primarily as a guide to allocating future income, and insists that you allocate all of it, so you actively take responsibility for the allocation of funds on an ongoing basis.

This fundamental change means you get the value, without resorting to all the minutia of Quicken, that seem to support, but in fact are only consequently involved in, the outcome of spending less than you earn.

I guess partly, Quicken suffers from solving many problems [budget, tax preparation, retirement income calculation] that do not exist in a smaller "built-to-purpose" application like YNAB Pro. Hence, it has to be designed to support all of those activities, some of which might be mutually exclusive of an Idiomatic Design. So I guess my questions are:

How can Idiomatic Design be applied to software on a larger scale than individual features, like scroll bars etc ?

Because of the large number of special cases required, do you think it is feasible to implement Idiomatic Design in monolithic applications that are used for multiple purposes, like Quicken ?


Post a Comment

<< Home