In Dashboard HQ Bookmarks, we came across an interesting, and very common, design problem: how to handle the entry of URLs.

The idea behind Dashboard HQ Bookmarks is to give people a way to get all their bookmarks out of their browsers and into a web page. It’s not social, and it’s not glamorous. It’s just a great way to keep a grip on all the bookmarks you need when moving between the two or three (or more!) different computers you use on a daily basis (work, home, laptop).

To facilitate this, obviously, users need to be able to create new bookmarks, and this is a potential error just waiting to happen. You can ether paste an address into the Address field, or you can type in an address manually. When an address is pasted in, it usually includes the “http://”. When it’s typed in manually, it often does not. But we have to use the entered address to create a link regardless of how it’s entered.

To handle this, we considered adding the “http://” as the default value in the Address field.

Seems obvious enough, right? It’s a standard solution, so we could have left it at that. But this solution meant forcing the user to make a choice every time he created a bookmark. He could either keep the “http://” and start typing the rest of the address afterwards, or he could erase the “http://” and paste in a URL copied from somewhere else.

And with this in mind, do do we highlight the “http://” automatically when the field gains focus, or not?

If our user is pasting in the URL, it makes sense for us to automatically highlight the “http://”. This way, she can tab to or click on the field and paste the address without having to delete anytyhing. But if she’s entering a URL manually, and the “http://” is highlighted, she then has to deselect the text so she can start typing in text after it. Either way, we’d be inconveniencing (read: annoying) the user some of the time.

To solve this, we wrote an if/else statement in Javascript that checked for the “http://”. The Javascript simply checks to see if the “http://” is already in the entered address. If not, it is added automatically.

Now, we leave the field blank and let users enter whatever they want. With one line of code, we eliminated a point of frustration that would have been noticed by every user, every day. Add all these moments up, and it means our users would have wasted countless hours fixing URLs and erasing the default value.

It took us five minutes.

Design is all about the details.

On a related note: I’ve been considering putting up a wiki so people can contribute and collect code samples related to these Design Stories posts and to the examples used in the book. But the wiki software I’ve found is, well, let’s just say it’s not all that friendly. Got any suggestions?

Regardless of whether you use BBC News, CNN, , Yahoo News, or some other page as your primary news portal, you’re constantly faced with the same type of solution. These pages contain lists of links, sorted by time, relevance, popularity, or some other criteria. And this is a good thing, because it makes information relatively easy to find.

That said, even the most basic and standardized designs can be improved. So recently, when I needed to add such a list of links to a home page for a new application, I decided to take a fresh look at the standards yet again.

I started with the usual suspect. I created a simple list of links.

For this design to really be complete, it needed to communicate to users that the order of the links was determined by the order in which the articles were posted. To do this, I could have included a bit of instructive text that said something like, “Sorted from newest to oldest”. Or I could simply have numbered them from one to five and called it a day. I could also have stuck a small “New!” icon next to the topmost link to imply the order. But having recently read the Boxes and Arrows article, “The design behind the design”, by Ross Howard, I felt inspired to try something a little different.

See, it’s always bothered me that the web has no sense of age. An article I wrote two years ago, for example, can very easily come up as a top search result today. Hence, I get email occasionally from people who have questions about something I haven’t thought about in two years. Their question is fresh. My answer, however, might be a little rusty. But if the web showed signs of age, the user reading the two-year-old article would clearly see that the article was old, and might therefore seek more updated information elsewhere, or at the very least, adjust his question while writing to me. (There are many other reasons that indicating age could be helpful to web users, but I’ll save that for a different post.)

So to communicate the meaning of the sort order in this case, I decided to try to communicate the age of each link. I started by changing the font size for each link based on its popularity. The link for the most recent article used the largest font, and the font size decreased with each link as the articles aged.

This alone changed things quite a bit. The larger font not only stood out more in terms of size, but also in richness of color. The larger font appeared darker and heavier, which made it stand out even more. Hmm.

This reminded me of something I saw in Google Reader. Jeffrey Veen recently wrote about some design work he’s done for Reader, and upon checking it out, I noticed a tag cloud unlike the others I’ve seen around town. This one used color changes as well as font size changes. It looked like this.

It included instructive text that said, “The more items a tag has, the bigger it appears. The more of those items you have read, the darker it is.”

I thought this was a bit convoluted for instructive text, but I also thought the dual-purpose tag cloud was a great idea. So I rolled with it.

Modifying my link list, I changed the color of each link to from from dark to light as the list descended from newest to oldest.

Yes, this meant the developers would have to write some more code, but in this case, they liked the format of the list so much that they didn’t care. (In other words, I got lucky.)

Is this use of ambient signifiers going to make a big difference on the resulting web page? Probably not. Will some people be annoyed by the tiny font used for the last link in the list? Possibly, but I can always adjust how much the font size decreases so this doesn’t happen. Am I saying you should immediately run out and do this on your own page? No.

The point is that ambient signifiers are a great idea, and almost completely untapped on the web. So take a look around and see what you can come up with. How can you use ambient signifiers to make a page more understandable or a task flow more intuitive?

Want to see another idea? Consider the recent Boxes and Arrows redesign that brought a tag cloud to the forefront of their persistent navigation.

Have fun!

Update from Etre: “Dao Gottwald ’s “Aging Tabs” Firefox add-on makes unused tabs fade with age - thereby making it easier to identify those pertaining to the current task.” 

OK and Cancel buttons are omnipresent on the web. Of course, they aren’t always labeled OK and Cancel and they don’t always have the same purpose, but we’ve seen them a million times nonetheless. The combination of the two buttons has maintained its position as a global standard for a very good reason: almost any action you perform in a web application can be canceled. This is seen often in round-trip interactions, in which the user starts an interaction on Page 1, completes it on Page 2, and is then returned to Page 1. It’s also seen in inline interactions, such as changing the title of a Backpack page.

Typically, the set of buttons is displayed as two side-by-side HTML buttons. This is true in many desktop applications as well. Sadly, this design has persisted for years and has found its way into millions of apps. See, the unfortunate side-effect of standards is that people often stop questioning them, and progress almost completely stops regardless of whether the standard is the best solution.

Here’s a typical OK/Cancel button set:

In this case, the object of the interaction is to create or edit a title and then either save or cancel it. Simple enough. So what’s the issue? Well, there are numerous ways to solve any given design problem, and even something as simple as this requires a few decisions.

The first decision to make is about the position of the buttons. It really doesn’t matter much in terms of usability whether the buttons are right-aligned or left-aligned to the field above it, but I generally stick to the left side for a few reasons. First, left-alignment keeps everything flush to the left edge, forming a nice, straight line from the top of the form to the bottom. Second - and this is simply an aesthetic choice - it seems to create a visual “end” to the form. As you complete each field, you move steadily downwards, and placing the action buttons at the tail end of it seems to anchor the form. But that’s just me. The most important reason will be explained in a moment.

The second decision to make is how to label the buttons. Sure, using the standard OK and Cancel requires less effort on a case-by-case basis, because you can simply label them without really thinking about it and move on, but are these terms really helpful? “OK” will work fine in a lot of cases, but more meaningful button labels can go a long way towards setting a user’s expectations about the result of clicking the button.

What does clicking OK do in this example? It probably saves the title. But elsewhere in the application, saving a setting might return the user to the page where he started the interaction, such as a Profile page. In that case, simply clicking OK doesn’t set a clear expectation. There, we should use something like, “Save and return to profile”. And since that’s true, we should maintain consistency and use meaningful button labels everywhere in the application.

On a more basic level, it’s simply more polite for us to set clear expectations regardless of what the user is doing. It makes things more understandable for them, and it makes us look good as a result. Do you need more reasons than that?

Despite all this long-winded logic, labeling the button in a meaningful way is really no big deal.

All we really need to do is change the label from OK to “Save title”. Rather painless.

The final thing to think about here is the thing that goes unchallenged by designers most frequently. It’s the fact that equal weight is often given to both buttons, the two of which trigger remarkably different results. I can understand why this started. Two options equates to two buttons. But this is not what we want to do. Instead of thinking about the number of options, think about the most likely option.

The most likely option for users who have decided to create or edit this title is to save the changes. The less likely option is to cancel the changes. But by giving both buttons equal amounts of visual importance, users have to actually read the labels - on both buttons - to decide which one to click.

Applying Fitts’ Law, which dictates that the time it takes to hit a target is a function of the distance to the target and the size of the target, the ideal solution is to take some of the focus away from the Cancel option by turning it into a text link.

(UPDATED: I changed the link color to black in this screenshot and removed the underline. Those who left comments here are right - a standard blue, underlined link stands out too much. Thanks for your contributions.)

This way, the “Save title” button is prominent and easier to hit with the mouse, while the Cancel link is less prominent and slightly less easy to hit with the mouse. Is it any more difficult to see both buttons? No. But it’s slightly more difficult now to click the wrong one. Your eye is drawn to the large button. And it’s easy to recognize, subconsciously, that the large button is the probably the one you want to click.

This, incidentally, is also why I prefer to keep the buttons left-aligned. It simply looks better to have that large HTML button aligned to the left edge of the field above it than it would to align the Cancel link to the right edge.

So why is it so important to keep the button on the left and the text link on the right? Because any user who uses the Tab key to move through form fields will reach the “Save title” button first, again putting focus on the most likely choice while simultaneously taking focus away from the less likely choice.

UPDATE: Jakob Nielsen has posted an Alertbox article called “Command links” that provides guidelines for when to use text links to trigger commands. His recommendations are very much in line with the example I’ve offered in this post. He recommends using command links for:

Continuing the Design Stories series, here’s a look at the design of character counters (the little text messages used to indicate how many characters can be entered into a text field).

Many sites skimp on the grace that character counters can offer and use something that takes the least amount of work to build, but can be quite frustrating for users. For example, an input field with a set character limit should communicate that limit to users, but many sites leave this important element out. When this happens, you often end up with the ability to enter anything you like, even though the entire string cannot be stored.

In these cases, users are informed of their mistake via an error message.

This method blames the user, essentially telling him that he should have known before pressing the Submit button that he couldn’t enter more than 50 characters. This is no good.

In another method, developers prevent users from being able to enter more characters than the limit allows, and users simply run out of space. So you’re typing along, humming a happy tune, and then your keyboard appears to stop working.

Also not good.

Some sites, hip to the notion that we should communicate to users what’s going on, have opted to use a form of a poka-yoke device. Instead of waiting until the user presses Submit to show an error, these sites warn the user using a bit of instructive text.

This helps. It’s definitely better than the previous solutions (which, clearly, are not solutions at all). But there’s still a big problem. Sure, we’ve warned the user that she can only enter 50 characters, but we’ve also made it her responsibility to count the characters herself.

With all this in mind, the best solution is to present a decrementing number of characters, telling the user every step of the way how many characters can still be entered.

Now, we accomplish several good things. First, the user is aware that there is a character limit from the very beginning. Second, the user knows with every keystroke how many characters can still be entered into the field. Finally, we’ve completely eradicated the user’s risk of hitting the Submit button and getting an error.

Instructive text is a good thing, but when it comes to character limits, instructive text with a decrementing variable makes a far superior poka-yoke device, guaranteeing our users will successfully get past this form element and onto the next step.

Continuing what I did in the “Interface Surgery” sections in the book, I’ve decided to start a series of blog posts called “Design Stories”, about the thought process that goes into the design of interactions. I’ll post these whenever I work on something I think would make a good case study.

First up: the 5-star rating interface. This design pattern can be seen everywhere from Amazon to Yahoo! to Yelp, but the individual implementations are often done very differently.

For example, rating widgets are often split into two parts, shown in two different areas of a page. One part is the display version of the 5 stars, the one that tells users the current rating. The other part is the interactive piece, where users choose how they want to rate something, such as a book, CD, or the helpfulness of an article.

The interactive piece can be done very differently from one site to another. Some use text as the rollover for each star, to make it clear what each star means as a rating. Some require that you click a star and hit Save. Some only ask that you click a star. When all you do is click a star, however, there is no feedback, except that the star is now yellow (or some color other than the non-selected white).

So these are the issues that I had to consider as I designed the interaction.

Also in this case, I needed to combine the two elements into one. I needed a way to show the current rating and enable users to select a rating of their own.

To do this, I split the display piece and the interactive piece into two states. I started with a simple display of the 5 stars, coupled with a link to begin the rating interaction.

I thought that when the user clicked the link, the set of stars should go into an editable state. This is indicated by a change in color from yellow to white. Of course, the user also needs a way to save the rating and return to the view-state, so I changed the “Rate this widget” link to Save and Cancel links, which also helps indicate to the user that the widget is now editable.

To start the interaction, the user simply clicks the link, then clicks the star she’d like to use to rate the widget.

At this point, the user can click Save, Cancel, or another star. Let’s assume she chooses to save the rating.

Upon saving the selection, the current rating for the widget is updated and the new rating appears, again in a display-only state. This indicates to the user that the interaction is complete and her rating has been saved.

Later on, we decided to put a little text next to the “Rate this widget” link that showed how many users have rated the widget - something like “(Rated 7 times)”. This not only tells existing users how much stock they can put into the rating (a single rating isn’t a clear sign that something is good or bad), but also tells the user that her rating has been added.

Finally, we added some business logic to the interaction that prevents a single user from rating the same widget multiple times. As in, if she chooses a different rating on a future visit, the average is updated, but the number of reviewers does not change.

The result? A single design element that both displays the current rating and offers a way to save a new rating.