Thanks to Google – the WIMP User Interface is Dead
TweetUpdated: A follow-on post titled “Why the WIMP User Interface is dead” has been posted by me. Please read it for more information on this topic.
Updated on May 8, 2006: Nick Carr writes in support of this post. Sadagopan refutes the idea. Ganesh, and Vinnie have posted comments against it. Looks like a good discussion is developing.
Since the advent of powerful business intelligence report-writer tools and adhoc querying tools more than 10 years ago, I have been advocating the idea that we should stop developing the information retrieval components of any Enterprise OLTP application.
Typically, OLTP applications are organized around transactions which perform CRUD operations on Business Entities. In other words, develop only the Create, Update, Delete parts of the application and configure standard tools for the Read part of the application without writing much code in the traditional OLTP application development context. This will allow us to optimize the OLTP app for just the Create, Update & Delete parts and the READ part for retrieval respectively, but that is besides the point.
We have been using WIMP as the User Interface design strategy since the days when Xerox Parc and Apple Macintosh pioneered the GUI and subsequently made ubiquitous by Microsoft Windows. As everyone will attest software development costs time and money, so my argument has been that by eliminating development on the Read part of the application, we can save time and money.
Now, there is a new twist to this strategy and that is Search. I think Search will make the WIMP interface obsolete for basic Information Retrieval/Foraging purposes. Of course, for more advanced information retrieval applications you will use business intelligence tools. Let’s see how this will pan out.
Google’s Onebox Search
First, I was reading Nick Carr’s interesting post today on Google’s Grand Ambition. This closing statement from Nick caught my attention and served as the inspiration for this post:
Well, there you have it. What Microsoft is trying to do with its new Duet partnership with SAP – provide a user-friendly way to tap into data from a complex enterprise system – Google is trying to do on a much grander scale. It wants to be a front end for everything. One wonders if the big application providers will really want to forfeit the user interface – and the power it represents – to Google. One also wonders whether they’ll have a choice.
From there, I landed on Dave Girouard’s interview about Google’s Enterprise strategy. This particular answer from Dave caught my attention:
Yes, because it’s a development environment. Any given company may
have all sorts of information that they would like to make available,
and they can make it all keyword triggered. You could type the word
“contact” and then a name and it would go to Exchange. It’s really up
to the administrators to decide how they want to trigger it.
But the user experience—and this is really important to
us—entirely mimics how Google.com works. So, you don’t have to get
training; you can discover it over time; a friend can show you a OneBox
that they think is particularly useful. For example, one of our
partners is Oracle, and you’ll be able to look up a purchase-order in
your Oracle financial system because Google will recognize what a
purchase order number looks like. Just like Google.com recognizes a UPS tracking number. The Enterprise system will know what an Oracle
purchase order looks like, and it will insert that information right at
the top.
Let’s make a note of “you don’t have to get training” and “the user experience”.
Why is the Google Search Interface is so intuitive and addictive?
Al though, we see Google as a Search engine, it has actually turned the spotlight back on simple User Interfaces moving away from the bloated and cluttered WIMP interfaces we see today with Microsoft being the leading light in this approach. User Interface design is a complex field and has a lot of theory behind it.
Let us focus on 2 important Laws that guide UI designers to understand the impact of the Google Search Interface:
1. Fitt’s Law In simple terms, this law governs the amount of time the user takes to move from the starting point to where s/he needs to go to accomplsh the task using the navigational elements (read windows, menus, icons) provided by the UI. Now, lets call this amount of time – Fitt’s Time.
2. Hick’s Law In simple terms, this law governs the amount of time it takes for the user to make a decision(s) amongst the myriad choices (read windows, menus, icons) presented by the User Interface to accomplish the task . Let’s call this amount of time – Hick’s Time. Now, in the Google user interface, for a basic search request, Fitt’s Time = Zero because when you launch the Google home page, your cursor is already in the text box for you to enter your search term. Additionally, Hick’s Time is also Zero because there is no decision to make as to which menu to go to or which button to press. The screen is so sparse that there is not much you need to figure out. You key in the search term and hit enter and you get the Search results. That’s it. Brilliant, isn’t it?
Of course, if you want to do more complex searches, you will have to learn more about the various Google operators and the Advanced Search page etc. There is another important concept that is a bit more subtle. This comes from the field of Information Foraging. Researchers at Xerox PARC and elsewhere, have found that the way we look for information closely mimics how he found food during our hunter-gatherer days.
Read this fascinating article by Rachel Chalmers for more information on this topic. The important concept that emerges from this theory is “Information Scent” – as you forage for information, you pick up some scents and go down certain paths depending on how strong the scent is. You get the idea. Coming back to Google UI – the scent is extremely good because the relevance of the search results is quite good. In the absence of a semantic web, Google produces extremely good results. In sum, Google UI has Zero Fitt’s Time, Zero Hick’s Time and a strong Scent to produce a very powerful user experience.
Enterprise Information Retrieval
Coming back to the Enterprise, a typical company has tons of OLTP applications each of them having their own confusing WIMP or Text-based UI making information retrieval a painful process. Here is where Google’s Onebox concept could prove very powerful. You have a single search for searching all the intranet portals and use keyword-triggered searches on specific OLTP applications to bring back information.
So when you type purchase-order followed by the customer name, it triggers a query on your Purchase Order system and brings back the relevant purchase orders. Using this method, you have actually made the Fitt’s Time and Hick’s Time zero for information retrieval inside the enterprise. I think this approach will help us escape the deadly embrace of the WIMP interface and make information retrieval a no-brainer.
References:
1. Search User Interface and User Experience – A comprehensive directory of links on this subject. I found the Rachel Chalmers article mentioned above from here.
2. Acclaimed usability expert Jakob Nielsen argues that WYSIWYG is dead. I am not yet able to see how this is going to turn out. I haven’t seen Office 2007. But in essence, Jakob is saying that the the WIMP interface is dead because there are too many features in today’s software and this WIMP interface is not working out.
Technorati Tags: User Interface Design, Infomation Foraging, Search, Usability
Sukumar,
I guess I will usurp this thread to add my $0.02 on just the information retrieval aspects alone.
In the purchase order example mentioned, information that a CFO of a company can access in a purchase order could be different from the one that can be accessed by a customer support personnel. Also, interpretation of the data could be different based on the person looking at the data. Further, a CFO could be looking at the purchase order for a variety of reasons – auditing, reporting, reconciliation etc. For the sake of simplicity – let me bundle all of these as ‘context’. So, the context under which a request made could be different. So, we need to find a way to accommodate this. And on top of this, sometimes the semantics or the meaning could be hidden and needs to be deciphered. So, the search language needs to be sophisticated enough to understand such requests. At the same time it needs to be simple to be use from a end-user perspective.
Am I right in thinking that a specialized WIMP based application (just by the fact is is custom-tailored) provides some of the features mentioned above? We need a way to bring these into the ‘search-based’ retrieval.
And, I have not even touched upon the structured/unstructured aspect of data – how to mine such data, put them together, decipher how the data itself can be useful in a variety of ways etc. A whole bunch of folks in IBM have been thinking about this for quite some time. If interested, take a look at their thoughts in and around this area. Being an IBMer, I apologize for the shamless plug!!
Ganesh
Ganesh,
Good point. Thanks also for the pointer to some interesting blogs.
1. Overall, i think i did not do a good job in the introduction. To clarify, I am merely talking about the low-context, low-semantic queries that the READ part of OLTP systems fulfill (what i referred to in the post as “basic information retrieval needs”) . I was planning to write a separate post on that so that it becomes clearer as to what i am talking about. Your comments have hastened the need for that.
2. What Google has shown us, is that mostly your information retrieval needs can be fulflled by a simple search interface. For people looking for information that has a lot of context and semantics, they need to use better, more sophisticated tools. Although Google may not be the first company to build a Simple UI, I think it has certainly turned the spotlight back on simplicity.
3. Now, if you look at traditional UI design inside enterprises, you tend to clutter up your interfaces with WIMPs because you are trying to make sure that the high-context, high-semantics task can be accomplished. This results in forcing the person with simple needs to learn a complex UI. In the olden days, command-line interfaces accomplished this beautifully. If you had an advanced need, you could use more parameters on the command line. Of course, GUIs definitely improve productivity and we can’t really go back to the command line. But, you can definitely try not to stuff the Complex UI down the throats of simple user needs.
4. Additionally, my point is, if you adopt Search as the unifying UI for all your simple information needs from OLTP systems, you can probably focus your UI design on more complex needs.
For a variety of reasons – technological, information architecture, commercial, security centered etc.. I do not think that the enteprise world would accept a common interface – a google centric one that easily – the questions of demonstrated value would be far more difficult to answer. The deployment of technology inside enteprises are generally far more sophisticated and complex than that seen in the consumer world.Enteprises taxonomy keeps evolving and to think of a unified interface for search and synthesis looks far too complicated – aside from the fact that more speialised players other than Google are already at it and doing a good job.
Sukumar:
Interesting post. At AdventNet, we have a couple of interesting products related to this. The first is SQLOne Search http://sqlone.com which is a way to provide a search interface to a set of relational databases. We apply algorithms to extract the navigational information present in the database (using foreign keys and such), and use that to perform search. We can also generate join queries using that search interface. In effect, it can be used as an alternative mechanism to generate queries.
From an end user perspective, we are experimenting with a search based UI in our Zoho Writer product http://zohowriter – here, we augment a typical toolbar/menu with a “Search your feature” box. The user can guess at something, and it will list the related commands, and when the user makes a selection, it will directly go to the relevant screen. This is an alternative to deeply nested menus.
Your feedback is appreciated.
Regards,
Sridhar Vembu
Sridhar,
Tnanks for dropping by. SQLnet seems like a neat idea. I also checked out the search-for-features on Zoho writer. That is a good idea as well.
I don’t always understand why there’s a lot of hype about different “enterprise” databases and why no one talks about free SQLite – IMHO, THE best database engine ever created. Genious database. Moreover, its FREE and PUBLIC DOMAIN! It is compact, very easy, and powerful. It can be used in MANY business applications. However there’s almost NO PR for it. If you disagree with me then go play games – download games and play. You probably do not know what i’m talking about. In many cases SQLite database is fast as MySQL. This is amazing database engine!!! Just go to website and learn. Oracle and MySQL can be used only for VERY HUGE database clusters. In most cases SQLite is more than enough for MANY MANY companies.