User-Supportive Internet Architecture

by Jakob Nielsen on September 19, 1999

The ideology of the Internet is based on assumptions that all made sense twenty years ago when the Internet was restricted to a small number of computer science professors and graduate students at elite universities plus a few Bell Labs-style research facilities. These assumptions are embedded in millions of line of code and countless protocols:

  • data is inevitably valuable
  • bits must be moved - but all bits are created equal
  • humans exist to consume bits
  • the existence of multiple computers should be made explicit
  • everybody is honest, credible, and equally important

Today, we need to change the foundation of the Internet to make it adapt to human needs and millions of users. Most research dollars are being spent within the existing ideology, simply aiming at higher bandwidth for data transport: the ability of a physician to diagnose a patient remotely through high-definition video is as close as one gets to usage scenarios.

Some of the steps needed to give the Internet a more utility-enhancing, human-centered ideology are:

  • Reputation managers help users focus on the good stuff and avoid bad stuff.
  • Micropayments will allow an explicit economic model of Internet usage and will encourage new protocols to transfer value. For example, it will be reasonable to charge users more if they want to download bandwidth-clogging video streams than if they want to read text-only pages.
  • Security and encryption should be pervasive: no plain-text information should ever cross the Internet; nor should any messages be sent without a digital signature. Unfortunately current approaches like PGP have too poor usability for the average user: security should just happen and it should be the default rather than the exception.
  • Assume abuse and assume bozos: minimize their impact on honest users. Reputation managers reduce the influence of bozos and flaming; security measures reduce the potential for abuse. But all Web services need to be resilient in their very design and architecture.

Email: The Scourge of Productivity

You are overwhelmed by email: you get too much of it.

I can state this safely because everybody is overwhelmed by the amount of email they get. A striking finding from studies of email users is that they will all say something like, "I get as many as X messages per day: this is very stressing and I am far behind in dealing with them." People will say so with the same degree of exasperation whether X is 10 or 100. No matter how much email you get, it is too much and too stressful - and you are behind in dealing with it.

My explanation for this finding is that users are always behind the curve in changing their behavior to being able to cope with a certain amount of mail. As mail volume increases, you have to treat it with increasing ruthlessness. As long as you get a few messages per day, they are treated as personal correspondence with each reply being carefully considered and composed and written in flowery language. At around 50 messages per day, people start sending "OK, do it" replies, and above 100 messages, much mail never gets answered (many messages get deleted unread, which is why most people need to write better subject lines).

All users are overwhelmed by email, and the cost of the time spent dealing with email world-wide is about two hundred billion dollars per year.

Yet, the basic philosophy of email systems is "the mail shall go through." Much like the old slogan "Neither rain nor snow nor sleet nor gloom of night shall stay these couriers from the swift completion of their appointed rounds."

A much better philosophy is to protect users' mailboxes from filling up. With the current system, anybody who can get hold of your email address has a license to dispose of a dime of your company's money. In the long term, the only way to eliminate spam is to charge the sender for the cost of the message, including the cost of the recipient's time.

When sending a message to a distribution list, the user should get a dialog box saying something like "You are about to send a message to 8,537 people. Do you want to proceed?" This simple question would eliminate much of the wasted email caused by people hitting the "reply-to-all" button instead of "reply-to-sender". And yet there is no way for the user's email client software to know how many people will receive the message. The architecture of the Internet prevents this information from being available.

Email also highlights the need for users to be aware of the underlying server structure, with addresses in the form user@machine.domain . Some email software tries to be "helpful" and hide this computer-centric addressing scheme in favor of presenting human names, but the result often causes usability problems: try to find all your email from a certain company in Microsoft Outlook. Since the domain name is hidden, this is not an easy task. A better solution would be to make email messages rich objects that included fields like the sender's company, but progress has been very slow in such human-oriented enhancements to the basic protocols.

The only improvement in email usability over the last 30 years seems to be that we have eliminated the hop1!hop2!hop3 style addressing scheme that required the user to know the path of the message through the net.

Userids Only Work on Mainframes

The concept of unique userids may have worked reasonably well in the mainframe age, when each computer was shared by no more than a few hundred users. Back then, it was usually possible to get your name or some other preferred identifier as your userid. Also, most users only needed to access that one computer system, so they could remember their userid, even if it was a variation of their name.

The Web invalidates the assumptions behind the concept of unique userids: a successful site will have millions of users, so it is almost never possible to get your preferred name. Good luck if your name is Bob or Mary. Even Jakob with a K is usually taken by the time I get to a site.

Also, users access hundreds of sites, so they need to remember hundreds of userids - obviously an impossible task, so users have to write down their userids and passwords , eliminating most of the security benefits from having the userid in the first place.

Having to specify a userid that nobody else has taken is a major stumbling block that reduces users' willingness to register for sites. The short-term workaround is for the site to give users a list of available userids after the inevitable error message saying that the user's preferred name is unavailable. Don't make users go through the guess-and-be-punished cycle more than once. Tell them some variations of their name that will work (e.g., jakobN, jnielsen, jakob362, etc.).

The long-term solution is obviously to make identity management a part of the architecture and allow users to log into the Internet once and for all and then have all other sites confirm the user's identity with a central password manager.

WYSIWYG Analogies for the Internet

Using the Internet takes constant awareness of what information is stored on what machines. What email is on your laptop and what is on the server? Should you "leave mail on server" or download it? What websites do you need to go to get certain things done?

The Web alleviated this problem somewhat by allowing users to click on links instead of having to type in machine names: as long as you stick to simple browsing, you don't need to know what is stored where.

But go beyond browsing and you are thrown back to having to know about the differences between different machines. If you write for the Web, you probably have one version of the text on your local machine, another copy (now in the right template) on a staging server inside the firewall, and a "live" copy on the real webserver that is accessed by customers.

Making updates requires the writer to know about many obscure steps and to keep track of the article as it moves from machine to machine.

One of the greatest advances in computer usability was the invention of WYSIWYG editing: What You See Is What You Get software shows documents on the screen in exactly the same format as they would have if they were printed. This unification between two concepts freed users from having to think of two different states of the document and made it obvious what the impact would be of using various formatting commands.

We need new forms of unification to advance Internet usability. In this modern world, we no longer need unification between screen and paper: in fact, it is harmful to pretend that there is a single view of a Web page and that it will look the same on other users' screens. So I am not calling for literal WYSIWYG.

One interesting unification is the "Edit This Page" feature in the Web authoring platform from UserLand Software. There is simply no distinction between the website and the writing interface: authors navigate the live website just like other users, and when they want to change the text on a page, they click a special "Edit This Page" button (that is not visible to regular visitors without authoring privileges).

"Edit This Page" is metaphorically a WYSIWYG unification for the Internet age. It removes a distinction and gives users one less thing to worry about. Epinionshas a similar approach: whenever you visit a review you wrote, there is an "edit" button right on the page. So you don't need to do anything special - you see a typo; you fix the typo. Right there on the site.

The IMAP approach to email is another attempt at unification: making it possible to deal with email on both the client and the server without having to know what's where. Unfortunately, you still have to know a little: if you bring your laptop on the airplane, you only have whatever email it has stored as a local copy. Once we get ubiquitous wireless Internet it will hopefully be possible to get a truly simplified approach to computer networking where we don't have to remember that there is a network.


Share this article: Twitter | LinkedIn | Google+ | Email