About Me

Manu Sharma New Delhi / Gurgaon, India

Since mid 2006 I have grappled with climate change and what it means for us. As an activist and campaigner, I sought to learn and simultaneously, attempted to influence the issues surrounding it - in technology and policy advocacy. As a consultant, I studied markets and created portfolios in sustainability services and renewable energy investment.

After thousands of hours of research, tenacious activism, working up-close with NGOs as well as the industry, delivering about two dozen public talks, countless conferences, hundreds of online discussions, a few media appearances (including Reuters, News Television, and BBC radio), and continuous evolution of my own ideas about what ought to be done - I may have found some answers but the issue remains far from being addressed.

In the despair filled world of climate change the only place I've found real and lasting hope is in a beautiful vision inspired by "The Ringing Cedars of Russia" book series by Vladimir Megre. The books have triggered a transition movement in Russia and have profoundly influenced me. I am now working towards the vision.

Climate Revolution Initiative, an RTI campaign I founded and ran for a few years is now retired. I no longer deliver talks. I still consider myself an activist though and occasionally post on Green-India group started over nine years ago.

Older entries in this blog relate to my former occupation in user experience design; long time interest in business innovation, strategy, ethics; and venture creation.

Image on top of this bar is courtesy book covers of The Ringing Cedars series published under Croatian translation. (Source)

February 19, 2004

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 BrinCo-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?]

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:

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?”"

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.”