User Control and Data Entry

"I'd rather make progress by having computers understand what humans write, than by forcing humans to write in ways that computers can understand."

Sergey Brin
Co-founder, Google.

A couple of days ago, dad wanted me to look up a conversion on in the internet. He wanted to convert a figure in square meters to square yards. I knew the formula for meter to yard conversion but wasn’t sure if the same would apply for square meter to square yard. [yes, I’ve always been lousy at Math].

So I thought of trying Google’s calculator feature. I had first used it a few weeks before the launch...I found it browsing around their features page. But that day was my first attempt at using it in an actual need.

Dad almost never browses the internet himself – he usually asks me when he wants something looked up. But he knows quite well what a search engine is and what it does. So I found it quite revealing that he wasn’t surprised when I told him that I could do the conversion on the search engine itself.

He expected it to work that way.

Multiple doors to success

Google succeeds where every competing search engine fails. Yahoo, Excite, Altavista, MSN all lead me to search results – links to pages that might possibly contain the answer but don’t immediately provide me with it. Leaving me with the undesirable job of trying to screen out what appear to be incompetent links and visiting those that appear to be competent until I get to the one that really is. [That’s the way search works, doesn’t it?]

On Google, I simply enter 225 square meters in square yards and it promptly reveals the answer: “225 square meters = 269.09776 square yards”.

That’s not all. Google goes out of its way to address needs of wide range of audience. It works even when I use the UK variant [metre] of the term meter. It suggests correction when I make a spelling error. And to my delight, still provides me with the correct answer when I try query formats different from the one that is popularly known to work for such conversions – (known unit in unknown unit). I had no idea that I could also:

Order it to... convert 225 square meters in square yards
Ask it: how many square yards in 225 square meters? (works without ? mark too)
Do a reverse lookup: square yards in 225 square meters
And try the formula route: 225 square meters = ? square yards.

This is remarkable. An absolutely brilliant interface. Not only does it latch on to the metal model of even the lowest denominator, but it doesn’t stick on to one rule or method of performing the query… stretching the limits of the search engine to support more than one right way of phrasing it, thereby accommodating a much wider audience.

This perhaps goes beyond satisfying the user. This is about delight. One may argue that most people probably won’t notice it. But at least in my case, it filled me with joy.

Squeezing it through

It’s also a great example of considerate software, as Cooper and Reimann define it in About Face 2.0. In the book, they lay out over a dozen different characteristics of considerate software that include being forthcoming, using common sense and anticipating needs.

One that I particularly like is, knowing when to bend the rules. They discuss this further in a chapter devoted solely to data entry where they introduce the concept of data immunity and fudging.

The common method of taking user entered data into the system – say when the user submits an online registration form - is to scan each entry for validity - as defined by the programmers in strict, unbendable rules.

"The programmer erects barriers in the user interface so that bad data can never enter the system. The pure internal state is commonly called data integrity. ... The software must maintain a vigilant watch for bad data, like customs officials at a border crossing. ... Anything on the outside is assumed to be suspect, and after it has run the gauntlet and been allowed inside, it is assumed to be pristine."

This is how it’s done all over the web. Prevent bad data and you will be safe, this is the maxim. For example, in address fields, users are made to suffer long drop down menus to select their state instead of just allowing them to type the two-letter code. One of the reasons this is done is to prevent bad data from entering the system – a user might make a typo.

Instead of rejecting suspect data, Cooper argues that program should strive to immune the system from being affected by bad data. Therefore, instead of halting user’s critical task, it should inform him of the error at a later stage.

Error messages are terribly disrupting. In user tests, one often watches the user feel stupid, guilty or angry on such occasions. Consider yourself at the checkout stage of a shopping site and being asked to register. With some courage you commit to the registration form and then right after you hit submit, the site tells you, you’ve made a mistake.

Now what’s easier, abandoning the purchase when there are five more steps ahead of you or to drag yourself through each of them with the possibility of encountering one or more error messages?

Data immunity requires that the system accept everything while keeping records so that when the user becomes aware of the error at a later stage [say, at order confirmation, in the above example], he has detailed information at his hand to make changes. It is the programmer’s responsibility to build safeguards in the system that prevents user from coming to harm.

Fudgeability is the system’s ability to accept data that has been fudged by the user. A simple example is the omnipresent e-mail field. Your e-mail address must contain the @ sign and a dot or it will not be accepted. If you’re commenting on a blog entry and don’t want the spambots to collect it, there’s no way to fudge it by inserting ‘at’ instead of the @ sign.

You can certainly fake an e-mail address but you can’t fudge it.

The common argument behind these concepts is that the system must be flexible and tolerant, keeping user needs ahead of its own. Ensuring that the user remains in complete control of his environment. Cooper sums it up quite well at one place.

"If an automated data processing system is too rigid, it won’t model the real world. A system that rejects reality is not helpful, even if all its fields are valid. In this case, you must ask yourself the question: “Which is more important, the database or the business it is trying to support?”"

Notes

Immediate source of Sergey's quote: Ziya, our friendly referee on the SIGIA discussion list.
Possible original source: This post on John Udell's blog. Sergey was speaking on the technology behind Google and the elusive goal of a truly intelligent search.

Learn more about Google's co-founder Sergey Brin

I’ve often found revealing insights on user requirements by making an interface run though people who are not familiar with the conventions of the domain. In the case of search engines for example, ordinary, beginner users often consider it a place to get answers to their questions. The term they use is not “conducting a search” or “looking up” but “asking.”

All books by Cooper including About Face 2.0.