Category Archives: Usability

Posts related to product design, user experience and usability

Up next: a replacement for the Google Docs Gadget

The current version of Kerika uses an embedded Google Docs Gadget, that’s part of the Sidebar within the application. There’s no polite way to describe this software, which comes in four different flavors from the mighty Google itself; let’s just say that the technical term for it is “p.o.s. software”.

A Google Docs Gadget is supposed to be something that you can easily embed within a website or application: it supposed to provide easy, direct access to your Google Docs from within your site or Web App. There are at least four official Google Docs Gadgets out there:

  • There’s this one from “Claudia C. and Ted C.“, both employees at Google – as you can easily see by viewing the XML code for this Gadget. It doesn’t work, which probably explains why Claudia and Ted are coy about revealing their last names. And when we say it doesn’t work, we don’t mean that it has some subtle bugs that are unlikely to surface for most users: just visit this Gadget, at Google’s own official website, and try setting the number of documents to show in the list. It doesn’t work.
  • Here’s another one: presumably a later one than the first, since it’s authorship is attributed to “Claudia C. and Ted C. Modified by Gordon Bunker”. We don’t know who Mr. Bunker is, but he couldn’t get Claudia and Ted’s Gadget to work properly either.
  • Here’s a third one: also the work of Claudia C and Ted C. This one is hilariously broken: just visit the link that says “Add to your home page” and you see the helpful message “Error parsing module spec: Not a properly formatted file missing xml header”. So, here we have an example of two Google employees, hosting an official Google Gadget, on Google’s own website, that is completely broken…
  • Finally, we have this one, attributed to “Claudia C., Ted C., and Sam B.”. Sam, like Claudia and Ted, found it wiser not to disclose his last name given he somehow managed to reduce the utility of the original Gadget.

So, there you have it: four different, official versions of the embeddable Google Docs Gadget, none of which work… The situation became untenable for us because with the latest version of Google’s Chrome browser, the drag-and-drop function stopped working altogether. No small irony here, that Google’s own browser doesn’t work with their own Gadgets, when Firefox’s drag-and-drop continues to work.

We can’t fix these Gadgets because they were built by Google employees; instead, we are building our own replacement for this Gadget which we expect to release this weekend. It’s simple, functional and reliable. It will let you perform a search across all your Google Docs, and drag-and-drop results from this search straight onto your Kerika pages. And, it will work on all browsers.

A single-click if you are under 35, a double-click if you are over 35

When we first built Kerika, we deliberately modeled the user interface using the desktop application metaphor: projects were organized in folders, and mouse actions were as follows:

  • Select an item on the page with a single mouse click.
  • Open (or launch) an item on the page with a double mouse click.

It seemed the most natural thing in the world to us: everyone on the Kerika team liked it, and we assumed that our users would like just as much.

So it came as a very considerable surprise to us when we observed a generation gap among our beta users, in terms of what they considered to be the most natural way to open and launch items.

The breakpoint is roughly at the 35 years-old mark: people older than 35 had a strong preference for the double-click metaphor, and people under 35 had an equally strong preference for the single-click metaphor: where you select an item with one gesture, and then you select the action you wish to take from a menu that pops up.

The preference grew almost exponentially in intensity as you moved away from the 35-year breakpoint: people in their 50s, for example, had a very strong preference for double-clicking, while people in their early 20s were, for the most part, surprised by the notion that a double-click might do anything at all.

Our theory for this phenomenon is simple: roughly 15 years ago, the Netscape browser came into wide use. People who are older than 35 started their careers before the Web, and first learned to use desktop applications before learning to browse the Web. People under 35, on the other hand, probably first learned to use computers by surfing the Web at college.

(You might guess from all this that the Kerika team’s average age is well over 35, because it never occurred to us that the double-click metaphor might be strange or unappealing to anyone.)

At any rate, Kerika now supports the single-click metaphor exclusively – at this time. The initial feedback we got from our beta users was skewed by the younger demographic, and this caused us to reluctantly abandon the double-click in favor of the single-click. However, we are now hearing more from older users, and a future version – very soon! – will support both the single-click and double-click metaphors.

And while the Kerika application doesn’t run completely smoothly on iPads – for one thing, the Google Docs application doesn’t really run on iPads – supporting the single-click metaphor positions us to ensure that Kerika will run, intact, on tablet computers in the near future.

Jakob Nielsen’s Power of Ten Principle

We like to think that we have done a fairly good job in terms of designing our user interface. A major influence was the writings of Jakob Nielsen: Kerika’s CEO had the good fortune to meet Mr. Nielsen at a conference in the mid-90s, when corporate America was slowly waking up to the reality – and permanence – of the Web, and Mr. Nielsen just been laid off from Sun Microsystems, which, in its infinite wisdom, decided to get rid of their entire Advanced Technology Group as a cost-savings measure.

Mr. Nielsen fast became a popular speaker at the few Web conferences that were held in the early days, and one could listen to his speeches practically for free. (Now, we understand, it costs about $15,000 to get Mr. Nielsen’s attentions for a single day…). Mr. Nielsen went on to found the Nielsen Norman Group, with Donald Norman who had done pioneering work on product design, and he created a simple newsletter-based website (www.useit.com) that remains a wonderful source of research on Web usability.

What was remarkable about Mr. Nielsen’s approach then, and which we think still is a relatively rare ability among the many design pundits today, is a rigorous emphasis on scientific observation and testing. Mr. Nielsen has never given the impression of being someone who has relied very much on his instincts when it comes to design; he has always emphasized the need for usability testing.

Too many other “pundits” – and here we use that phrase in the American sense of a talking head, rather than the Indian sense of a priest or wise man – rely upon what they believe, often erroneously, to be a superior design aesthetic which they deftly package with enough jargon to make it appear more like fact than opinion.

(Today, we have a beta version of Kerika that we are using to gather usability data: we are sitting down with our initial users, directly observing their reactions – their many sources of confusion and occasional moments of delight – to see fine-tune our user interface. We believe we have done a good job on the main aspects of the design, but there are many rough edges that we still need to sand over, to get the “fit-and-finish” just right. So, while we are immensely proud of what we have accomplished – and the tens of thousands of lines of Javascript and Java code we have written in a remarkably short period of time – we are only too aware of our shortcomings as well…)

Mr. Nielsen writes mostly about website usability, but his observations and principles are very apropos to the design of Web applications as well. We have tried to incorporate his suggestions on perceived affordance and information scent in the various elements of our user interface, but when we expand the discussion from UI to UX – from user interface to user experience – it is clear that performance is a key contributor to an overall good experience.

In his article on the “Powers of Ten” principle, Mr. Nielsen points out that 0.1 second is the response time limit if you want users to feel like their actions are directly causing something to happen on the screen. If a system responds within 0.1 seconds, the system essential disappears from view: the user believes he or she is directly manipulating the objects on the screen.

(A simple analogy is the mouse: when one moves the mouse, the cursor moves immediately on the screen, which is why it is so easy to learn to use a mouse: one quickly forgets its presence altogether, and concentrates upon looking at the screen instead. We often see people who hunt-and-peck at their keyboards; when was the last time you saw someone look down at their mouse to make sure they were moving it correctly?)

To that end, we have tired to ensure that most user interactions when using Kerika fall within the 0.1 seconds time limit: when you add an item to a page, or move it, or delete it, it happens instantly.

Next up is the 1 second time limit, and here we quote Mr. Nielsen:

When the computer takes more than 0.1 second but less than 1 second to respond to your input, it feels like the computer is causing the result to appear. Although users notice the short delay, they stay focused on their current train of thought during the one-second interval.This means that during 1-second response times, users retain the feeling of being in control of the interaction even though they notice that it’s a 2-way interaction (between them and the computer). By contrast, with 0.1 second response times, users simply feel like they’re doing something themselves.

In the Kerika user interface, there are moments when a user will experience a 1 second response time, although not very often: most commonly, this happens when we are waiting for an external website to respond. For example, if you have built a “video wall” of YouTube videos, you may have to wait a second (or two or three) for YouTube to respond when you decide to play a video. This, regrettably, is out of our control. But for the parts of the user interface that are within our control, we have tried to stay within the 1 second time limit.

After 1 second, users get impatient and notice that they’re waiting for a slow computer to respond. The longer the wait, the more this impatience grows; after about 10 seconds, the average attention span is maxed out. At that point, the user’s mind starts wandering and doesn’t retain enough information in short-term memory to easily resume the interaction once the computer finally loads the next screen. More than 10 seconds, and you break the flow.

Nothing, in Kerika, breaks the flow.