LarryRoth.net

I am very pro usability—anyone who knows me will agree. I fight the fights that need to be fought. I go against the corporate decisions that don’t benefit the user. I evangelize for Donald Norman and hang on  every word that Jakob Nielsen speaks. This is why it seems so very strange that I would be incited by an innocuously titled article, Stop Password Masking, on useit.com.

Dr. Nielsen contends that we—Web developers—should abandon legacy design and stop providing “little dots” instead of the actual characters that a person is typing in for their password. On the surface, this seems to make sense. After all, it’s hard to type in that which you can not see.

I guess I should be upfront and say this is many years as a sys-admin speaking–not a usability expert—but none-the-less I found many things flawed with the post. I would add that the designers of systems have a responsibility to protect users from compromising their account.

But the main point of the article is that by not showing users what they are typing when the type a password, we are decreasing the usability of the page and also the security of the page.

Here is a brief recap of the main points of the article (please read the whole article for yourself):

1. There are very few times when a user is in actual danger of someone “seeing” what they are typing
2. Users make more errors when they can’t see what they are typing
3. More errors means less confidence
4. All this leads to users using simple passwords or copy/pasting passwords

One of his primary points is that a “skilled criminal” can capture you password by looking at the keyboard, not the screen. It’s hard for me to argue with this as I have witnessed this and even done it.

Here’s the rub…I have managed users on systems large and small for the better part of 20 years. I have learned by observation that people don’t have simple passwords because passwords are hard to type in without seeing, they have simple passwords because they are easy to remember.

As a system administrator I know, inherently, that the weakest chain in any system is the user. And it’s not because it’s hard for them to type their password, it’s because they want one password that is easy to remember and is somehow tied in with who they are as an individual.

For this reason, I find passphrases to be a better solution because they are easy to remember and are instantly harder to hack due to their length. If someone has a hint of what you like, they may more easily crack the passphrase with shoulder surfing, but it’s much harder than a simple password.

Lastly, Dr.  Nielsen points out that we should abandon legacy design—I am a HUGE fan of abandoning legacy design when it makes sense. Dr. Nielsen points to both form reset buttons and password masking as being legacy design…as the twitteratie say, EPIC FAIL!

Let’s focus on usability, but only when usability is really the problem. But maybe you disagree with me, leave me a comment.

Excuse the headline. To be clear, I do think that usability tests are very valuable. But often times they provide little data beyond what you are testing—for instance, the labeling of the primary navigation. Yes, seasoned testers can often times extrapolate large amounts of observational data, but sometimes the really niche features of a Web site aren’t so easily discovered. Users seldom provide ancillary ideas for features they may need. Instead the idea for a feature usually only occurs to a user when they needs it. So, when a feature pops up for me at exactly the time I need it, in exactly the place I need it, to me it means somebody really thought the problem through, perhaps even cared about me a little. To me it says: “hey, we want to make your life easier”.

All usability experts focus on the user first. That is, quite simply, what we sign up to do. As such, we often refrain from  ”feature-itis”—defined as adding features for the sake of having more functionality. Additional features often times do little more than round out a sell-sheet of product benefits, hardly ever benefiting the user. But there are many times when a well conceived feature can pay off not only for the user, but for the service provider as well. And I must correct myself, when discussing this blog post with a colleague of mine, Ernie Bello, he rightfully pointed out that it’s not the feature itself, but the execution of the feature that makes it usable or not.

As an example, I had purchased a couple songs from the iTunes Music Store by Canadian artist Sass Jordan. I know, I know, it’s 2009, but I just have this thing for Canadian rock from 2 decades ago. After listening to the two songs I had purchased (about 10 times), I decided to get a couple more. Of course, now I was regretting that I hadn’t purchased the whole album and saved a little money. That’s when I discovered this:

Example from the iTune Music Store

Note how when returning to the album from which I have already bought a couple songs, I am prompted to complete my album. It’s clear, obvious, and exactly where it should be. I am sure that many of you will point out that this is also a benefit for Apple, and that may be the case. But the point is, the very feature I wanted, existed when I needed it, and where I needed it—even thought I didn’t expect it to be there.

My point is that I doubt a usability test would have found the need for this feature. If I were a test subject with a task to buy a song, I would not have thought to tell a usability tester that it would be great to have a feature to complete an album, just in case I change my mind in the future. I didn’t even think about it as a feature until I actually needed it. But somebody thought about it for me, and thought about how I could use it. And yes, with that feature in place, it can be tested and can be validated.

What little features have you noticed or even created that have really made a big difference? Leave me your comments…

Skittles unveiled their new corporate site to much applause and some disdain by the Twitter community. Taking a cue perhaps, from agency.com, they have reduced their site to be nothing but a navigational overlay box on top of content provided by social network sites.

screen grab: skittles.com homepage on March 2, 2009

This works by making their:

• home page a Twitter search feed
• product pages, Wikipedia pages
• media pages both Flickr and YouTube feeds
• friends page a FaceBook page

Simple is best right? Maybe not.

So what is the upside for Sktittles? Well today, at least, they have generated plenty of free publicity. Going forward, they will have a lot of fresh content and perhaps some ongoing publicity.

But how about the downside? There are plenty of thoughts that pop into my head.

Perception

How will they be perceived by the social networking community or the social network sites themselves? Within several hours of launching their Flickr page was account “missing” and a “neutrality” warning was posted at the top of their Wikipedia article.

screen grab: the article notice that appears at the top of Wikipedia's Skittles page.

Skittles is “borrowing” a lot of bandwidth from these sites, for free, and what are they providing in return? Users of social network sites provide content, sometimes very interesting content, and that, along with increasing per-page impressions is the fee they pay for using a free service. What is Skittles giving back to the community?

“Social-ness”

The biggest part of being a part of “the social”, and the part that companies often don’t get, is that it’s about 2-way communication. Kudos (excuse the pun), to Skittles for allowing their customers to have an unfiltered voice, but where are they in the conversation? We want to hear Skittles interact with their customers, not just hear ourselves talk about them.

Alienation

What is the experience for many of Skittle’s potential customers? For instance, you now have to be 13 years old to view the site. And even if excluding kids from a candy store makes sense, what about the folks that are Web savvy, but not social network savvy. Perhaps this site will be a little weird to them. Which leads me to the biggest issue, usability.

Usability

Is the site usable? We all know that when considering usability, we must first consider our audience. Some would even go as far as saying that we can limit to a specific target audience, not just any possible site visitor. If we suppose what a target audience for Skittles might be, and even if that audience is entirely composed of social network aware individuals, would they find the site useable?

Well, next we would need to know the tasks the audience might engage in. Let’s also suppose it’s the following:

• find nutritional information – OK, it’s available via Wikipedia, but can I be sure it hasn’t been altered? I also need to do quite a bit of searching (e.g. reading and scrolling) to find it.
• find contact information – perhaps the easiest thing to do on the site and bonus points for not hiding the phone number
• search for information – not available at all. This is a complete failure for many web users who wish to visit a site and immediately search for the piece of information that they need.

So, in 3 tasks that I picked, the site only covers one well. But in addition, I see some other major usability hurdles:

• Poor feedback as to where you are in the site. While this is important in any site, it is very important in a site such as this where the context of the page you navigate to may differ greatly from where you came. e.g. will the user know that WikiPedia is the product page?
• Navigational overlay gets in the way. On many pages the navigation box seems to be on top of the content and it’s not readily apparent how you shrink it.
• Random pop-up explaining how to “drop the box in the corner”. If you have to explain to your audience how to use your site, or worse, how to navigate away from it, you have failed at usability.

screen grab: skittles.com pop-up explaining how to navigate away from their site.

Lastly, while not a usability issue, it is odd that a promotional site would ask you to accept their terms and conditions before they tell you about their product. Given the nature of the content that may appear, I certainly understand the reason, but it seems like a big hoop for someone to jump through just to view your site.

To sum it up, I would say the new Skittles.com makes a great meme and a is perhaps a bit of Internet history, but to me, the site doesn’t make sense. While I think that companies should be involved in social networking, it’s very important how they approach it.

I can’t wait to see what my colleagues at BrandLogic think about the impact this site has on the Skittles brand. And I would love to hear what you think. Please leave me your comments.

The kind folks at 80 works for designers take us behind the scenes to a class that is creating a prototype interface for deaf people to feel music.  It’s a wonderful read just to review the processes that the class uses to work through the problem domain. But more so, it is a great reminder that usability should include accessibility. Thoughts?

We all know that the Apple brand is ease-of-use. But, usability expert Jakob Nielsen contends that this may very well be why Apple has survived all these years:

During its first decade, the Mac offered clearly superior usability compared to competing personal computer platforms…

The Mac’s miserable marketplace performance seems to pose a strong argument against usability. Why bother, if it doesn’t sell?

The counter-argument is that usability is the only reason Mac survived. Compared to the PC, it was much more expensive, had only a fraction of the specialized applications, and was cursed by Apple’s business-hostile attitude.

So why would anyone pay more for less? Because Macs were easier to use.

It’s an inspirational article for usability, with links to many other interesting articles.

The Digital Experience Group of the New York Public Libraries (NYPL) decided to try a bold experiment. Knowing that they wanted as much user feedback as possible and that they had willing participants—namely their web users, the Group created a trouble free survey tool to gather data. You may be saying, “Ohhhh, online surveys! What’s so bold about that?”. As usual, it’s the chosen implementation that helps to make the difference.

The Digital Experience Group created Infomaki, a system that provides a simple, one question survey asking a subject something as easy as “What would you click on to find events?”. After the subject answers that question, they are thanked, and simply asked if they would like to answer another question. Here’s what is so great about this approach: it’s very mindful of the subject’s time and very non-intrusive. The concept is that this will lead to more people willingly being repeat subjects. Also, more random questions will be answered. With a traditional survey, you may tend to get the same questions answered at the start of a survey, but have people drop out, thus not getting sufficient answers to the end questions.

There are a few bugs in the system, but it appears the team is actively working on fixing them. I gave it a try, and quickly got hooked. While obviously, my subjective opinion and observations do not constitute a usability test, I have observed most test subjects glad to answer a single question. But conversely, I have seen that grimace or shoulder slump when a subject can sense you are settling in for a multi-part questionnaire. My experience would point to Infomaki being a well received data collection methodology.

But don’t take my word for it, look at the results of the 48 hour pilot:

[a prior] survey received 7,341 individual answers to questions from 520 respondents, 60% of whom completed the whole survey. This totaled 7,341 individual answers over 14 days. Infomaki, on the other hand, garnered over 6,900 answers from 840 respondents in its initial 48-hour maiden voyage.

Seems like the concept works, but the real measure of success will be the continued interest of the subjects and the quality of data. Let’s hope we here more about how Infomaki works out.

Perhaps one of the most crucial parts of UI design is the feedback you provide to users. Like all the information you display, you need to prioritize and provide the proper context for your users. Or said another way: it’s important that you make sure what you think is important is also important to your users. Why the emphasis on important? Well, I found a great example in Web Position Pro (version 3) that helps to prove my point.

First off, Web Position is a fantastic software application that helps you to track your search engine ranking. This post, by no means, is meant to slam this product. However, I did find one Important Notification in the product challenging to the user.

Upon startup—and after a fresh, fully-licensed install I might add—I was greeted with the following error message.

Error message from Web Position Gold 3

What’s the issue? Well, first of all, the user is presented with a modal window and is being told that a service they never signed up for has expired 4.24 YEARS ago. More pressing, is the use of the word Important. To whom is this message important. Certainly not someone that has let their service expire over 4 years ago! Perhaps it is important to the sales department at WebTrends, but not to the user of the software. It would have been better to present the message in the proper context. One suggestion might be an on-screen prompt, not a modal window, and language that is more honest: “We can help you: sign-up for page critic today!”

Lesson to learn: Save UI conventions such as modal windows and strong language such as important for messages that are important to the user, not just you.

There is a great post on Web Design Tuts discussing How to Design The Perfect Form. The author does a great job of showing many different examples, but in particular, he breaks down form design as:

• Less is more
• Context & Assistance
• Distractions
• Modals

It’s a great read and well worth exploring.

David Churchville has a nice post that poses the question:

Does the agile software development mantra of “Do the simplest thing that could possibly work” lead to functional, but unremarkable software? [1]

He continues by pointing to an example of when functionality might be chosen over usability.

It’s an interesting thought, but I feel the main benefit of agile development is to test early and test often. This testing, if done properly, should help to find usability issues. And then, agile development really helps out by not only finding the issues, but by fixing them before they are released.

Said another way, in traditional software development, it seems all to common that when the deadline slips, one of the items that is often discarded is usability testing. Any early testing—while perhaps not true usability tests—will help out.

[1] Is Agile Development Killing Usability?, http://www.extremeplanner.com/blog/2006/07/is-agile-development-killing-usability.html, posted July 26, 2006, viewed, July 28, 2006

Ebrahim Ezzy and Richard MacManus over at Read/Write Web put together a nice summary of Search 2.0 and how it compares to traditional search. They define Search 2.0 as the third generation search technologies and that they are:

…designed to combine the scalability of existing internet search engines with new and improved relevancy models; they bring into the equation user preferences, collaboration, collective intelligence, a rich user experience, and many other specialized capabilities that make information more productive.

[1]

In their post—which by the way is part 1 of a 2-part series—they examine 5 different Search 2.0 companies. They point out a key feature of each and also compare it to traditional search (e.g. Google).

What was interesting for me is that when I went to try the search engines they mentioned, 2 of them were down, 2 required a setup process, and several of them were simply returning Google results with their own "value add", such as clustering.

Does having to train a search engine or relying on an unknown communities’ rankings really further search? I have always felt that technology should help automate things for us, not require more effort on our part. The lure of Google was—and is in my opinion—the simple page with only one thing to do, enter a search term. And you could be reasonably certain that you would find the information you wanted within the first couple result pages.

I must admit, I did like some of the added functionality in Clusty—although as part owner in a Branding firm, it feels wrong to mention anyone named Clusty.

I noticed a couple of comments to the post with which are worth highlighting:

• …I think the people that want all this Search 2.0 nonsense are the people having trouble coming up with a comprehensible list of phrases to describe what they’re talking about…
• Part of being a good search is… uptime! (and speed).

Check out the post, it’s a good read.

[1] Search 2.0 vs Traditional Search, http://www.readwriteweb.com/archives/search_20_vs_tr.php, posted July 20, 2006, viewed July 21, 2006