First of all, a progress indicator should show how many more pages are required in order to complete the email. This would allow people to quickly understand that this may be a lengthier process than they expect and give them an indication of how close (or how far) they are to completing their communication.

The mention of I want to write a supporting comment/differing opinion as the first item is a bad approach. While I understand that it will make it easier to quickly assess the level of support or dissent on a particular issues, the approach likes granularity and inspires instant suspicion of darker motives. A better way to approach this would be to include this as a later step in the flow, asking whether the writer supports or opposes the policy or other (the other category allowing for people who are not fully in support or dissent on a policy to offer suggestions).

The next issue is in the breakdown by categories. Here, I would recommend that the system allow for a more granular approach, first letting users decide whether it is a particular policy matter (for example, a bill currently in front of congress), a general comment on a particular topic (maybe using the different governmental organizations as a top category and then breaking it down to the individual issues). The reason for this approach is that it would allow to get a much better redirection and could, undercover, also allow for messages to be sent to a particular person in a particular department, hence increasing the chance of a quick response.

For example, an email on Internet usability could be sent to the webmaster team of the site, as well as to some of the people responsible for Section 508, as well as to someone in the president’s office handling those issues. This would make for a more responsive government.

Instead of using a select box, the issues should be included as links, with a “more info” button next to each of the links. Clicking on that button would state the White House position on that particular issue, allowing to later select if you are writing to support or protest a particular position. This would also help in educating people about the president’s position on listed issues.

As it currently stands, the content organization makes it look as if there were a limited number of issues the president’s office is willing to discuss and as if the issues on the list are not part of the agenda, and therefore should be ignored. The lack of an “other” category re-emphasizes that feeling.

Once you have selected the proper topic, you are presented with a form asking for contact information. That form should include a prominent link to an explanation of the White House’s privacy policy (did you know that, by law, the site is supposed to retain all emails it receives for a period of 12 years?) This will help people better understand how the data will be handled and can help alleviate concerns.

The review screen should present the data in a clearer form. A good way to do so would be to highlight the headers information (from, name, address, etc…) in a separate block than the rest of the message.

That’s about it, off the top of my head. I’m sure others will find more fault with the system but I hope that this will contribute to the discussion. I know that some of the TNL.net readers are members of government (or at least read this site from governmental locations) so hopefully, those usability recommendations will make their way to the right place and the system will be improved.

As a side note, I recently heard that Bill Clinton did not use email much during his administration because of the heavy requirements for record-keeping. Email retention is a problem that is the bane of many organization, both governmental and corporate. It looks like this new email system is designed to better handle that kind of data. I wish the webmasters at whitehouse.gov much luck in figuring out how to fix it.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Usability and the White House Email System. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

I can’t get no… satisfaction

As much as we’d like it to, users are not using our software because of love for developers. They are using it to accomplish a task. How satisfied they are with usability of the software package they use is an important consideration that can take them from using your system to using a competitor’s.

The basic concept of user satisfaction rests in the fact that users want systems to be intuitive. They want a program to work in the way they think. However, as we learned earlier, users come in different shapes. What satisfies one user may not be what satisfies another one. What is intuitive to a programmer is not necessarily intuitive to an average user.

As a result, it is impossible to satisfy all users all the time but it is possible to satisfy most user most of the time. In a way, the satisfaction of a user is directly correlated to the other concepts we have explored throughout this series so far (learnability, efficiency, memorability, and error handling): if a system is easy to learn, can be used efficiently, has features the user can remember, and provides easy error messages, a user will be satisfied with the overall experience.

Looks

However, going beyond those critical factors is also a level of graphical design. You can design the best application in the world in terms of usability but, if the interface looks ugly, the user will shriek every time he or she uses the system.

This is generally an issue in the open source community as most programmers are not designers (and the inverse is true) so most open source projects have fully functional UIs that are spartan in their appearance. This is not a bad thing in and of itself but leaves non-programmers with the feeling that those application are less polished. As a result, this lowers the user satisfaction in those system and also lowers the acceptance of open source software.

A way to solve this is for programmers to enter into a partnership with designers and usability people. The usability person comes in and helps on the other factors we covered in the series. The designer provides that last coat of paint that make the application look better. The challenge in working with those people, however, is that a lot of the discussion should happen early in the project so that the underlying structure is in place to allow for look revisions.

Another item to watch out for is designers that get carried away. One must ensure that the application is not so heavenly laden with a heavy set of eye candy that it calls more attention to the look than to the rest of the application. A UI expert once told me that his job was to make sure that no one ever saw what he was doing. A good user interface does not call attention to itself but makes the user feel that it has that polish.

Feel

Another issue with heavy UI is that it sometimes hobble performance. However, it is possible to increase the satisfaction of a user by diverting his or her attention when using the application. Such diversion must be transparent so that users do not catch on, similar to the sleight of hand pulled by magicians, getting you to focus on one thing while they are doing something completely different. For example, much has been made about how speedy Apple’s web browser, Safari, is. But truth be told, it is only marginally so. The way the Apple programmers made it feel faster was by painting the first window more quickly, which give the impression that the application is more responsive. By comparison, the Mozilla browser feels like it’s taking longer to load because it first shows a logo, before displaying the application. The difference between the two is that, in the case of Mozilla, the user has to wait an extra few seconds to see the browser window. As a result, it “feels” slower. Granted, other improvement to the Safari browser make it run faster but, for the large part, most of the speed improvements on the Mac OSX platform have been in making applications look and feel like they are moving faster.

Who’s my user

Before concentrating on those issues, however, one must figure out who are the users of the system: are they technically proficient or not? What age group do they fall in? How do they use the software? What other software do they use? This is where the concept of personas, which I will cover in more details later, comes in. Before designing your program, figure out what types of users are going to use it.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Usability 101: Satisfaction. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

Things break

You may design the perfect system but eventually, your system will fail. How it does so, however, can make all the difference in the world in terms of usability. As a general rule, users are at their most vulnerable stage when a computer program breaks. It may be because they’ve lost some work or it may be because they don’t like it when computers tell them that what they did did not work. Either way, anyone evaluating software will consider switching application if errors are too common. You may build the best application in the world in terms of future but none of that will matter when your program breaks… unless you can steer the user in the right direction.

Anatomy of an error message

In order for an error message to be helpful to the user, it needs to include a number of elements:

• The message should exist: This may seem like a no-brainer but oftentimes, the main problem with an error is that no error message is attached to it. For example, imagine an email package. For some reason, when trying to send an email, the email package fails. If the user is not notified that this error happened, he or she will assume that every worked great. From the user’s standpoint, no error has happened and he or she will continue using that function. Now ask yourself, is it better for the user to send one email and be notified that there is a problem or is it better for the user to send 20–30 emails before learning that people on the other end did not receive anything? The answer should be fairly obvious. Notify the user when the error happens, every time it happens. The error may be due to a flaw in the software or a flaw in the way the user is using the software but if the user doesn’t know, he or she will assume that the problem is with the software.
• The message should be understandable: Often, error messages provide absolutely no information to the user. A message that says “Error 12312 Bad Syntax” provides absolutely no information to the user. As a result, you should think of what a normal person (read: someone who does not program) needs to understand what the error was. Sometimes, something as simple as a plain explanation goes a long way in helping the user feel better. An example of a good error message could be, for example “Sorry, your file was not saved because the hard drive is full.”
• The message should be precise: A message that just says “Syntax Error” is not really doing its job properly. The reason is that this kind of error could be coming a number of times from a number of places. This is not helpful to the user (as the user is not aware of what the problem is) and is not helpful to the programmer (as the programmer will not be able to know what happened when the user says that he or she got this error). A precise error message makes everyone’s life much easier as it gives a clear set of information related to the particular error to both the user and (when the user speaks to a programmer) to the person in charge of fixing the problem. If your error messages are clear, your product will be easier to fix.
• The message should be correct: When error messages are inputted at the last minute, there is often a tendency to shove any error message anywhere. As a result, an error message could be popping up that has nothing to do with the error at hand. Check your error messages carefully to ensure that they are indeed providing information about the right type of error.
• The message should be consistent: Oftentimes, people get carried away with error message writing. However, you should consider setting up a standard way of presenting your error message. Generally, an error message pops up in a separate box (in a GUI interface) to increase a user’s attention to it. In a non graphical user interface, it would probably appear in the same screen. If you are switching back and forth between the two mode, choose one way to present your error messages. Once you’ve done so, figure out the format of your error message. For example, an error message could be including the following elements:
  • A message or icon specifying that this is an error (eg. “Error:”)
  • A clear description of what the error is
  • A line break
  • A short explanation as to what the user can do to fix this
  • A line break
  • An OK button to allow the user to close the box
• An error message should be helpful: We are talking about usability here. So let’s not forget that this error message should be usable. One way to make it so, for example, is to provide a short description as to how the user can fix the error. Another way is to give the user a button to notify the programmer of the error (this would, hopefully, send more information to the programmer so he or she can fix the error in a subsequent release of the application)

A note on presentation

As I pointed out earlier, error messages generally do not make a user feel good. Because of that, there are certain things that you should consider in the presentation of your error message.

• Color: One would think that an error message should be printed in red to call attention to itself. To use color solely as the way to present an error message is generally a bad idea. The reason: there are people out there who are color blind. Presenting the message in a particular color will not make an iota of difference to them.
• Language: If your application is used by people in different countries (and if you’re an open source developer, you are probably hoping it will be), consider the fact that error messages will have to be translated. Yes, it’s a pain but oftentimes, it is something that is overlooked and causes much annoyance on the part of the user
• Icons: Be careful of what icons you use to present your error messages (if you plan to use icons). A good example of this was the small bomb on the original mac computers. When an Apple Mac crashed, it would show an icon presenting a little bomb: Users in many country were terrified by this icon and would not touch the computer, for fear that it would explode. This is a true story, which should highlight how careful you should be when considering icons.

So remember that errors will happen but that what will make all the difference in the world is if they are handled properly.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Usability 101: Errors. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

What is memorability?

The concept of memorability, within the usability context, is that a user can leave a program and, when he or she returns to it, remember how to do things in it. How many times have we all gone through a training exercise with someone who knew the system only to come back to it and be completely confused? This is the issue that memorability tries to address.

Why is memorability important?

Memorability is important largely because users may not be using your application all the time. In some cases, they might get some training on it, then go off on vacation, then come back and be too swamped with other things to use your piece of software. There are a variety of reasons for which a user may not be using a piece of software for an extended period of time. When they come back to it, though, you need to make sure that they remember how to use it. In some ways, memorability can be tied to learnability in that it works in the dark recesses of our brains, with cues reminding a user how to use a particular function. Most users will probably not be interested in spending a lot of time learning the system unless they get more out of it. As a result, you need to get the basic stuff to be intuitive.

This is a challenge unto itself as intuitive behavior is not something that is easy to figure out. For example, if you are a Unix geek, opening up a shell window and doing a lot of things at the command prompt seems intuitive. If you are someone who is still new to computers, it is complicated.

As a result, you will find that some of the memorable things are usually due to one or two factors:

• An action from the user had a reaction that the user did not necessarily expect. If that reaction left the user with a good feeling, he or she will remember it. The opposite is true too. This is similar to putting one’s hand into a fire: you may do it a first time and get burned; The next time you see an open flame, you’re not going to put your hand on it (unless you want to get burned). In that case, the action caused a reaction that people remember.
• Some symbol, icon, or other visual presentation type that allows the user to make a free association with the task at hand. For example, the “Home” icon on most browser is a little house. The reason for this is that people assume that this house is their home. Thus the home concept is communicated to them via a visual cue.

Testing for memorability

One of the challenge on OSS development is that most of the development generally happens without user input. In order to establish memorability, user input is needed. The only way to measure how memorable a system can be is to sit a regular user down in front of the system a few times. The first time, the user will get an idea as to how the system works and complete a set of established tasks.

After that first session, continue coding but do not change the interface (unless something glaringly obvious was shown to you by the user in terms of not working). A few days later, sit the same user down in front of the system and ask him/her to complete the same set of tasks, this time without your assistance. If the user is fumbling around, trying to figure out how to move forward on a task, you have a memorability problem: the user is not remembering how to do a task. After that observation cycle, talk to the user about the specific task on which he/she stumbled. From there, you might be able to guess what would make things more memorable.

However, how one user remembers things is not enough to create a system that is memorable to all. As a result, using the same user over and over again will work great for that one user but may get further and further from making the system memorable for other users. As a result, you will have to run through the set of tasks quite a few times before you get a good handle on what most users will remember.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Usability 101: Memorability. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

What is efficiency?

Efficiency relates to how fast a user accomplish tasks once he or she has learned to use a system. The basic idea behind it is that, as you use a computer system more and more, your level of expertise in use of that system increases, thus lowering the amount of time that it took you to do a particular task. A good example of this is in the concept of shortcuts or quick keys. For example, many people use CTRL-X to cut a piece of text on a PC (alternatively, Mac users use Apple-X) and use CTRL-V to paste text (or Apple-V on the Mac). This is a very basic concept that allows people to be more efficient: Without this, a user would have to highlight the text with their mouse, then go to the edit menu, pick the cut item in the menu, then go to the place where the text is to be pasted, go back to the edit menu and click on the paste item in the menu. Using the quick keys, they highlight the text they want to cut, press CTRL-X, go where they want to paste the text and press CTRL-V. In this process, two extra time-consuming tasks have been removed. While it may not seem like much, if you consider the number of times a user might use those function in a given day, it adds up to quite a large amount of time.

So how do we do this?

One of the main challenge to the OSS community in terms of improving usability will stem from the fact that most OSS developers do not interact with everyday users when they are developing a system. The challenge here is in figuring out how to increase the speed at which a user can do a particular task. A good example used in the usability community to explain this concept is that of the microwave. The basic question boils down to which is faster, cooking a cup of water for 1 minute and 10 seconds or 1 minute and 11 seconds? From a purely mathematical answer, one would say that the former is the fastest. But from an interface standpoint, it isn’t. A user can more quickly type 1–1-1 than 1–1-.. This seems completely counter-intuitive to established mathematical formulas but highlights some of the complexities of usability design. What this highlights, however, is that one must think of those things before coding. This means that basic usability issues should be part of the design cycle of an application.

Highlighting efficiency

Here are a few points that one should consider as part of this process:

• Are my error messages clear? A user receiving a message along the lines of java.lang.foo error 1023123 will be confused. However, if the same message says Your request could not be processed, please press enter again, the user will be working more efficiently. Clear instructions are part of a good usability system. In this case, the user is not spending a while trying to figure out what happens and is asked to do something to solve the problem!
• Does my system give feedback? This is important because users left without feedback tend to hesitate before moving on to the next step. A good example of how not to do this is the send e-mail screen in Squirrelmail, an otherwise really nice open sourced webmail application. When one presses send, the screen comes back to an empty message, giving no indication as to whether mail was sent or not. This lack of feedback left me confused and wondering whether the email had been sent or not the first time I used it. In this case, a simple Your email has been sent message would have done the trick.
• Is there a convention for this function? In the control key example, I showed how people might expect CTRL-X and CTRL-V to act as the cut and paste functions. Do not go against those basic rules as it will confuse the user. Generally, mainstream applications follow the same principles for basic functions. Here’s a quick sample of commonly used function (for Mac, replace the CTRL with the Apple key):
  • CTRL-A: Select All
  • CTRL-B: Bold text (in editing mode)
  • CTRL-C: Copy
  • CTRL-F: Find
  • CTRL-I: Italic text (in editing mode)
  • CTRL-N: New
  • CTRL-O: Open
  • CTRL-P: Print
  • CTRL-Q: Quit
  • CTRL-S: Save
  • CTRL-U: Underline (in editing mode)
  • CTRL-V: Paste
  • CTRL-X: Cut
  • CTRL-Y: Redo
  • CTRL-Z: Undo

  Reusing commonly used functions will allow users who have used other systems to easily make the jump to yours, without have to relearn a lot of tasks. This will make them more efficient as the learning curve to move to your program will be lessened.

• Is the behavior of my system consistent from window to window? Some people believe in innovating by providing different ways to navigate a piece of software, depending on where in the software you are. As a general rule, this is a bad idea as it confuses the user. If your first entry screen launches new windows, make sure that all the buttons launch a new window. Similarly, if it overwrites the main window, make sure that’s the case for all sub-items (and make sure there’s a clear way to come back to the previous window!) Users expect application to work in a consistent manner so choose an approach in terms of presenting screens, and stick to it!
• Is my navigation clear? This is something where the OSS community can actually improve on the overall user experience. With Windows 2000, Microsoft has started to change the navigation based on how much users use a particular function (the infamous “where are my tools” menu). This is a really bad idea and flies in the face of convention when it comes to usability. Make sure that your navigation is consistent and do not make it disappear (navigation should not evolve! The other issue here is the concept of mystery navigation. This is more of an issue when people deal with designers. A designer might feel really strongly that the best way to “improve” the interface is to use some cutesy button instead of presenting something that is clear. Trust me, a button that says “main menu” is better than a twisty button that hides what the menu is.

If you follow those basic points, users will become more efficient when using your program. As a result, they will be happier and will tell all their friends to use it. See, usability is already paying off!

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Usability 101: Efficiency. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

1. familiarity
2. consistency
3. generalizability
4. predictability
5. simplicity

Let’s delve further into each of those in more details.

Familiarity

The concept of familiarity is almost self explanatory. It talks to the way people “expect” things to happen. A good example of this is the web browser. Most people expect the browser to be divided into seven areas: an application menu, which mirrors the look and feel of other applications on their operating system (such as file, edit, view, bookmarks (Microsoft Internet Explorer calls those “Favorites”), Tools, and Help); a loading graphic (which is animated when the browser fetches a page); a navigation area, which includes familiar buttons such as backward, forward, stop, refresh, and home; a web address box where they can type in an address to get to a web site; a bookmark (or “Links” as Internet Explorer calls it) bar, which lists sites that are bookmarked; a main window, where the content of the site they are looking at is displayed; and a status bar, displayed below the main window and providing information on whether things have downloaded or not.

As you can see from the list of what makes a browser screen, this is already a fairly large set of components to think of, when designing a browser. Mozilla, my favorite browser, succeeds in mirroring most of this properly. However, the lack of a home button in the navigation bar of the default install of the software may confuse a lot of users (There is a patch to resolve that problem but beginners will not know this. This creates some concern for the user, which easily unsettles them because, if this part is unfamiliar, what else can they expect?

The challenge here is to start thinking like a low-end user. Mozilla is a very powerful tool but how do you make it easier? As developers, we often forget that the people who could use our software may not know as much as we do (or worse, some developers believe that people *should* be experienced enough to use their code). The best way to handle this when working on designing screens as part of an OSS project is to show it to people who are not programmers (family members, or non-geek friends are useful here!). If it takes a regular user more than a few minutes to understand what the program does, you may have a usability problem.

Consistency

Consistency talks to a certain level of expectation. As a general rule, users expect a program to act in a consistent fashion. Consistency issues arise when a piece of software looks different from area to area. For example, if you let the designers loose on your interface, you may end up with different fonts, font sizes, buttons switching positions, etc… This happens a lot when skinning applications.

In order to maintain consistency, ensure that your application reacts in the same way on its sub elements as it does on the top ones. For example, if you use buttons like OK and Cancel next to each other, make sure that they always show up together so that you don’t end up with an OK or Cancel button standing on its own or with something like Go and Cancel in one screen and OK and Cancel in another.

A consistent interface breeds familiarity, which in turns makes your application more usable.

Generalizability

The concept of generalizability expands on consistency but goes beyond your application. Generalizability talks to the wider world of all applications like yours. As a result, it’s kind of a pack mentality thing. If you are working on building a better mousetrap, you have to make sure that people realize that it is a mousetrap. As a result, you have to use some of the elements and attributes of other mousetraps.

The best advice in terms of maintaining generalizability is to look at what similar applications do. For example, going back to the browser, the edit preference screen is generally organized in subsections. In the case of Netscape and Mozilla, they show up in a category list on the left of the preference screen. In the case of Internet Explorer, they show up on the top as tabs. In the case of Apple Safari, they show up as big icons on the top of the preference screen. As you can see from here, there is some level of consistency in terms of organizing that content.

Another example of generalizability is the tabs implementation in Apple Safari. Mozilla and Opera had taken an early lead in establishing tabs as part of their browser offering. Opening multiple tabs showed a tab navigation bar and opening a new tab on the mac implementation of those browsers was done by using Apple-T. When Apple implemented their solution, they bowed to the consistency rule by implementing tabs in the same way as its predecessors.

Predictability

Predictability is, as expected, building a system that works in the way you expect. This is much tougher than one would think as level of expectation are different based on user levels.

For example, advanced browser options in Internet Explorer are under in an item called “Internet Options” under the “Tools” menu. The assumption here is that anything that is user configured is optional and that, in order to configure it, one would use a tool. On Mozilla, the browser options are in an item called “preferences” under the “Edit” menu. The assumption here is that the user would want to edit their preferences. Two different paths to the same area, which can lead to confusion.

Because Internet Explorer has the leading market share, we must fall back on the generalizability principle here as to where a user should expect those options to be. This points to one of the issues related to all the points brought up so far: sometimes bad interfaces are what the user expects. Trying to change that is often difficult and goes against the concept of learnability.

Simplicity

The last item in learnability is simplicity. The simpler the interface, the easier it is to use. Here’s an example: If I create a button called XML in an application, fellow geeks will expect that once they click on that button, they will see the XML version of the document I’m presenting. However, someone who does not know what XML is will look at that button and be confused. As a result, that button should not figure prominently as part of my default interface.

A good way to enforce simplicity is to provide a regular user and an expert user setting. For example, Apple Safari is a very basic browser when you look at the out of the box version. However, several tools can reveal new menus that will be used by experts. If I were involved in development on the Mozilla interface, I would recommend that it ship with a default dumbed-down set of menus. In the preference setting, one could turn on the super-user mode, which would then provide all the remaining menu items. This would allow to create a simple-looking browser, while retaining all the great features under it for more advanced users.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Usability 101: Learnability. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

In Usability Engineering, Jakob Nielsen mentions five concepts to remember when it comes to usability:

1. Learnability: How easy the system is to use.
2. Efficiency: How well the systems’ interface maps to what someone is trying to do.
3. Memorability: How well the system allows people to remember how to do things.
4. Errors: How well the system prevents errors and allows recovery from them.
5. Satisfaction: How satisfied a user is with the system

We will examine each of those points over the next few days, providing a basic framework into usable systems. Along the way, I will touch on some of the open source pieces of software currently available and offer potential solutions to some of the usability problems they have.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Usability 101: Introduction. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

Good/Bad Practice

In this first step, we would highlight good and bad usability issues with major open source products. However, part of this requires an effort in terms of figuring out quick wins in terms of fixes vs. things that may take longer to fix. The idea here is to highlight some of the basic best practices that open source users might consider.

Guidelines

This is probably going to be tricky but what I’d like to see arise out of discussion is the possibility of creating a document (or set of documents) that could help open source developers get a better understanding of usability issues. This might help in educating the community as to what to think of when creating new tools.

Communication

This is another difficult point to address but there needs to be good communication as to what can be done to fix a problem. And, moving forward, communication regarding successful implementation of more usable features in an open source product. If, every time a new version of open source software comes out, it shows improvements in terms of making it easier for people to use, we should try to highlight that. The best and worst issues list will go some of the way but we need to define a clear communication strategy to tout the ease of use of open source products in front of the press and of potential users. This will allow to get over the mental barrier that open source products are generally difficult to use.

This is just a start and I hope it will kick off discussions on the list. In the meantime, why not subscribe to the list!

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Usability Bazaar: Goals. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

The main challenge comes from the fact that most software developers are too knowledgeable to really create easy to use system. As a result, new features are created daily for open source tools but little attention is being paid to making the overall tools easy to use. The challenge is that simple interfaces are hard to design and largely present a challenge that is woefully underappreciated. A good interface is one that is so in tune with user expectations that it becomes essentially invisible.

As a result, the balance in product development always happens between fewer features with an easier to use interface vs. large feature set with increased complexity. Weblog tools seem to manage a careful balance between the two but are unfortunately tied to a particular model, based on entries and list of entries. More complex sites, with different sections and other functionality do not fall well within that mold.

Let me go through an example to get a better idea of what I mean. The site that I am trying to create is for an organization. Most of the people in that organization are people with little to moderate computing experience. They know how to use a browser, they know how to type text into a form. That’s basically the level of knowledge that the system has to meet. However, the system should allow for a number of extra functionality such as the ability to create a set of navigations for a site, the ability to create new pages within that site, and some basic workflow components to divide between contributors (who may create content), editors (who authorize that content to be published and can create/edit/delete sections), and administrators (who will take care of adding new features, creating, editing and deleting users, and look and feel). There needs to be functionality to also allow members of the reading community to do some commenting on stories posted, and for editors to create polls.

So far, it seems like an easy thing to build. However, when one scratches the surface, complexity sets in. How does one get notified that content needs to be updated? How does a story make it to the site? How does the site look and feel change? Using tools like Slash or PHPnuke seemed like a good idea initially but they lock a site into a particular look and feel that can only be changed with a lot of hand-wringing development. Furthermore, the complexity of organization is something that the user community could not wrap their minds around.

As a result, I’ve discovered that simplicity was much more complex. What we, as programmers, expect a user to do is very different from how users expect a system to react. From there, a big disconnect arises. We know that there is only so much you can stuff on a screen. In terms of interface design, the best systems are generally systems that appear to provide less options to the user. For example, the success of web browser arise from the fact that their interface is relatively simple: an entry field (where you type the URL), some basic navigation (go forward, go back, reload, stop, and home) and a content window. By comparison, Microsoft Word has no less than 23 choices on its “standard” menu. I would hazard a guess that most people do not use most of the functions on this menu and that they therefore should be hidden.

In Don’t Make Me Think, Steve Krug points out that proper web design should ensure that users don’t have to think about where to look in order to find the information they need. This is a pretty major step in development that shows that users should be able to intuitively use a system. However, designing such a system is a very complicated endeavor.

Over a year ago, Matthew Thomas pointed out some of the usability issues presented to the open source community. A cursory look at open source applications since then has shown little progress on the simplicity front. As a result, I have started a Yahoo Group entitled Usability Bazaar (with apologies to Eric Raymond for stealing his line.) Please feel free to join in. Together, we might be able to start focusing on those issues and developing open source software that people other than us geeks will use.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Usability Bazaar. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

According to the wired article, some of the reasons have to do with complexities related to going online. In order to resolve those issues, the industry needs to play closer attention to user experience and start figuring out how to make things easier. Return on investments in technology will increase if more people use a system. More people will use a system if it’s easier to use. However, few companies pay close attention to those kinds of details. Next time someone asks you why usability research is needed, point out the relationship between usability and bottom dollars: the business people will immediately see the value.

A question remains, however, on how to get people back. As standard marketing theory often points out, it is easier to convert a customer that has never used a product than to get one that has unsuccessfully used a product to come back. This is a challenge that marketers everywhere need to crack in order to increase overall market shares.

Also of interest in the story is the fact that most disabled people do not go online. This seems to represents a huge market for anyone as the Internet could actually act as a great enabler for disabled people. Site developers should pay close attention to things like the World Wide Web Consortium WAI project which could help lure more disabled people online.

Last but not least is the question of economics and Internet access. Obviously, there is a need for education here as most libraries now offer Internet access for free. However, recent efforts in monitoring what is done online in libraries probably keeps some people from getting online and the remainder is probably either not aware that Internet access is available at their local library, not interested in going to the library (for educational reasons or other), or doesn’t see any value in the Internet. A way to solve this would be through better educational programs related to the fact that the service is available, addressing quick wins by showing people how they can do certain things faster online (for example, showing how people could get a better job or reduce the amount of time and money it takes to do something by going online).

However, all of these points have a pre-requisite. Before addressing the problem, we must first understand who those people are. A demographic make-up of Internet drop-outs could help (are those people mostly from a certain age group, for example) in understanding whether this might become a longer term trend that needs to be addressed or whether most of the problem is going to go away over time (as kids nowadays seem to get online at a faster rate than older people).

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title Mind the Gap. You can follow him on twitter here or receive his weekly newsletter by subscribing here.

Wired is the first publication to test it out and there are ample benefits to the advertisers. First of all, they can track what publication has prompted someone to go to their site and second they can target readers of those pubs with different messages. Interesting concept but what’s the advantage to the customer?

Unfortunately, Digimarc’s approach is not that uncommon in our industry. Designers build sites that are beautiful eye candy requiring tons of plug-ins and then wonder why more people are not using them. The answer is quite simple: customers do not like to download plug-ins and a recent study showed that customers do not even care that much for graphics on a page.

In a reversal of what is happening in the print world, Internet consumers want text. So why do more and more sites insist on having such things as slow flash movies at their entrance? Quite simply because they do not pay attention to what their customer want. In a recent editorial on his Flash weblog Flazoom, Chris McGregor is calling on all Flash developers to focus on the customers.

At the same time, Jakob Nielsen, “the guru of web page usability”, is talking about using Customers as Designers. The message here is simple: Focus on your customers and they will focus on you.

This may sound like a rant on my part but it’s something that’s been brewing over time. Too many companies have taken their customers for granted (the “if you build it, they will come” phenomenon) and have then wondered why their projected growth was not happening. In a word: Not enough work on usability and too much focus on design.

The genesis

But in a way, this is not an unusual phenomenon. Back in the mid eighties, when desktop publishing tools became available, people at the forefront of that revolution felt the need to use most of the tools. As a result, many publications would come out with different fonts for headlines, story, sub-heads, etc… often making the newsletter or magazine almost unreadable. To a large extent, the apotheosis of this phenomenon was the rise of Wired as a publication, and their almost unreadable Mind Grenades. Yes, they were pretty to look at but they were low on content and high on graphical treatments.

Over the years, Wired has become more conservative in its layout but the damage didn’t stop in print. Taking what they had learned about badly communicating in print, Wired pushed the envelope further on the web by using a number of icons and less than obvious names for their sections. It was fine in the name of experimentation and the folks at hotwired eventually pulled back from their to create more understandable sections but many took it as the reason for creating over-bloated pages with bad navigation.

However, I have to admit that most of us back in those days were checking out Hotwired to see how far the medium could be pushed. It was exciting and since few of us had had many years of experience, we spent countless hours dissecting what was working and what wasn’t.

One step forward and one step back

Hotwired went back to a more traditional look (at least by their standards) in 1995–1996 and started organizing its content around sections that made a little more sense. In the meantime, plug-ins came out, Java came out and we all felt a need to implement the latest technologies on our sites. What we didn’t realize at the time was that while we were putting Java Tickers and 2.0 features on the sites, we were closing the door for a few more people who did not have the technology to look at our sites. With each iteration of a new browser, there was a mad race as to who would implement the latest and greatest extensions and we ended up with sites that were, for the most part, unusable by a lot of people.

This is when the split started between two schools of web page creation: the interface designers, who were arguing that the web was more like a software application and that the role of a web page was similar to that of software and should have a clean design that was transparent to the user (I remember arguing that we should never be happy when a user talked about our design because it meant he or she had noticed it) and the graphic designer group, who believed that the beauty of design was more important than its functionality.

On the interface side, people started looking at whether a site scaled back gracefully, all the way to the lynx text browser. As a result, somewhat more boring-looking pages were born but users were coming in, getting the information they wanted, and getting out.

On the designer side, people continued to look at ways to enhance the experience, adding all kinds of sounds and plug-ins to create more interactive sites. Those sites looked great but needed users to keep up with the latest technologies in order to use those features.

A middle group started looking at templatization and automatic browser identification (the smart way to do things but I didn’t realize it back then) and serving different pages based on what platform the consumer was using. Ultimately, that last group was right in that it can now go on and implement new presentation schemes offering the same content in different format.

Why this diatribe?

Ultimately, this issue is one of customer focus. Back in those days, we didn’t have many customers to cater to (the web was not as mainstream as it is now) so we were afforded the chance to make mistakes. However, now, there is little room for those mistakes and there is an established body or work (and a few corpses) to look at when making decision. Ultimately, however, it’s about the customers.

Another example

I used to love Kozmo for their quick delivery and their clean interface. Then they decided to redesign the site to create more space for them to sell other product. From the inside, I’m sure it made sense: try to sell more products to each customer coming in the door. The problem, though, is that this redesign slowed down their system to a crawl. When I was happy with Kozmo, I didn’t care much about UrbanFetch, Kozmo’s biggest competitor in New York. However, the long time it took to load a single page on Kozmo’s site convinced me to take a look at UrbanFetch. I did, their site reacted faster and I started ordering more from UrbanFetch than I do from Kozmo. Why is this relevant? Quite simply because I am now putting my dollars somewhere else because a redesign pushed Kozmo one step back. As a result, their attempt to sell me more resulted in my buying less from them. Not a good trend and I hope for them that I am more of the exception rather than the rule. But somehow, I doubt it.

Back to the end-user

I’d like to propose a somewhat radical idea: take everything your company is doing and explain, for each of those components, the benefits to your customers. For example, why is a cookie for your ad important? Answer: it allows us to better target customers, hence providing them with ads that may appeal to them and be related to what they are interested in. It’s a bit of a stretch but the customer derives value from being presented with something that is more along the lines of their interest.

So what about Digimarc?

In the case of Digimarc, who’s the end user? It’s the reader of a magazine. Why should that reader use such a technology? Because it enhances the magazine. Just keeping the technology as a way to bridge paper ads to web promotions doesn’t really enhance the customer experience but how about using it as a web to link to more info. For example, if you were a subscriber, you would get a version that allows you to delve deeper in a story. I would scan the page, it would send me to the publication’s web site, where I would find such things as links to the companies mentioned, links to other articles about the subject in this magazine’s archives, etc (furthermore, the publication can sell advertising on these online pages to advertisers that are already using the technology in the print edition)… This would add real value to the experience, truly creating a bridge between the print content and the online one. The concept is good but the implementation right now needs that kind of tweak. If you’re an advertiser using that technology, try to push the magazines to follow that concept through, hence unlocking extra value for you.

Conclusion

Of course, focusing on the customer is no guarantee of complete success but it goes a long way in taking you there. Technology is always intrusive, the question is how do we make it less so and therefore increase usage of that technology. Of course, there will always been a few people out there trying out everything new (I am one of those people) but those of us who do are already favorably predisposed toward technology. In other words, we are not the right kind of focus group. If you are a technologist or a techophiliac, you are not the right person to judge whether this will work with the mass public. Ask someone around you who doesn’t use technology as much as you do (parents, friends, people at the corner store) about how they feel about a particular concept and start aligning your thoughts with theirs. Look at what you’re doing critically (does this make sense to someone with average or low computer skills?) and focus on your customer. It’s a tough practice and it’s often a frustrating one, as you will find that what may have seemed obvious to you isn’t to other people. But the end result will be that your customers will love you for it and will keep coming back.

Tristan Louis is the founder and CEO of Keepskor and writes the influential tnl.net weblog, where this was initially posted under the title It’s About the Customer. You can follow him on twitter here or receive his weekly newsletter by subscribing here.