Many, many years ago, as a young boy living in Delhi I had the good fortune of being a neighbor and friend to the then-elderly, since deceased, M. Chalapathi Rau, the publisher and editor of the newspaper National Herald which had been founded by Jawarharlal Nehru himself during India’s freedom struggle. (“M.C” or “Magnus” as he was known to his friends was a man of many talents and a true eminence grise who unobtrusively operated the levers of power in India.)

To help me research a school project, M.C. took me to his newspaper’s printing press, a vast, clanking space where I watched with great fascination the painstaking process of laying out moveable type by hand: a craftsman’s job that had remained essentially unchanged, at least in India, since the 19th century. I did my school project, thinking that this would be my first and last experience with typesetting…

At college, however, typesetting reappeared: in order to get a job, one had to have a beautifully laid out resume, particularly if one had no “professional experience” to list other than the insalubrious qualification of having toiled in the scullery of a campus dining hall for minimum wage. So, I dutifully learned the obscure commands that helped set fonts and margins using troff, the first document preparation software for Unix computers.

I prepared and padded my resume, bluffed my way into my first job, and assumed that that would be my last encounter with typesetting. Ironically, my first job was at AT&T Bell Labs, working on Unix-based applications.

Typesetting is closely tied to the history of Unix, and, indeed, provided the raison d’etre for Unix’s existence. In 1971, when Ken Thompson and Dennis Ritchie (and others) at Bell Labs wanted to get funding for developing the Unix operating system, their business case was based upon the rather tenuous argument that developing this new operating system (Unix) would help them develop a better typesetting program (troff), which could be used by Bell Labs to file patents.

In those halcyon days, Bell Labs generously recognized and encouraged geniuses to explore their ideas, and, more mundanely, Bell Labs actually did need a better typesetting programs: since it’s inception in 1925 the organization had averaged one patent per business day (and collected about nine Nobel Prizes by the time I showed up as a very junior programmer).

So troff, the typesetting program, is responsible for the creation of Unix, which means that typesetting is the reason why Linux, cloud computing, Google, Facebook, Twitter, etc. all exist today!

Typesetting occupied a relatively small part of my workday until I started moving into management roles, which coincided with the widespread adoption of Microsoft’s Word software. Suddenly, most of my day was spent typesetting memos, performance appraisals, proposals, etc. I emphasize “typesetting”, rather than “writing”, because Microsoft Word remains, at heart, a typesetting program, not a writing program. It requires you to learn the same obscure catechism of tab settings, kerns and serifs, character and line spacings that those ancient typesetters at the National Herald had mastered as a craft.

And, yet, no one considers it strange that all of us highly trained, highly paid “knowledge workers” are required to master a craft that was first invented in China in 1040 AD!

The advent of the modern Web, starting with the release of the Netscape browser in 1995, has provided little relief: we exchanged one set of obscure keystroke combinations for another, equally opaque set of symbols (i.e. HTML). It is only in recent years that blogging tools, like the excellent WordPress software I use to pen this essay, has helped hide the typesetting and allow users to focus on the writing.

Between the release of the Netscape browser and the current robustness of WordPress came the advent of Google Docs. Google Docs’ primary innovation (or, more precisely, Writely’s primary innovation — remember Writely?) was to offer online editing; Google Docs did nothing to fundamentally alter the typesetting nature of word processing.

Google Docs continues to evolve, but as a persistent shadow of Microsoft Office. This makes sense from a business perspective, of course: it is easier for Google to get customers signed up if they can state simply that Google Docs works like the familiar Microsoft Office, and is a lot cheaper and easier to access. It would be much harder to get people to sign up for a Google Docs that seemed to fundamentally alien in comparison to that reliable reference, Microsoft Office.

And, so it continues… Centuries after the invention of moveable type, we remain trapped in its formatting conventions. At Kerika, we are starting to think seriously about making our embedded text editor (which is based upon Whizzywig) be the primary way for people to write for the Web. Kerika is all about creating and sharing pages stuffed with your greatest ideas and coolest content, and it’s high time we put aside typesetting. For good.

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.

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.