Warning (512): /home/zastica/zastica.com/app/tmp/cache/ is not writable [CORE/cake-1.3.8/libs/cache/file.php, line 267]
Warning (512): /persistent/ is not writable [CORE/cake-1.3.8/libs/cache/file.php, line 267]
Warning (512): /models/ is not writable [CORE/cake-1.3.8/libs/cache/file.php, line 267]
Zastica • Usability

3 posts found in (usability)

Newsletter Usability

I just spent the last few minutes reasons Jakob Neilsen’s Alertbox on newsletter usability. I always find the Alertbox fascinating and insightful, but this one is particularly informative. For me, it put into words exactly how I feel about a few topics in web design, not just newsletters.

Use good subjects

Probably the most important part of your newsletter is the subject. It’s the first thing your users see, and you never get a second chance to make a good impression.

But while dashing through their inboxes, people simply don’t have time for word plays, puns, and the like.

Be clear and concise, and avoid wordplay. You might think it’s clever, but your users will treat it like spam and are more prone to ignore the entire newsletter.

In addition to subject lines, users now pay more attention to message previews

Technical and usability improvements have lead to showing the first few words of an email along with the subject. The first few words of any email are very important to users when they decide whether or not to open the email at all.

Newsletters or social media?

I’ve had a few people ask if they should start a newsletter, or just use facebook. Data from the Neilsen’s study shows that newsletters are vastly more important to loyal customers than social media:

In our latest study, we asked users to “receive updates” from companies. Only 10% elected to do so through Facebook, while 90% opted for a newsletter.

Social media should be seen as engaging with potential customers, to entice the to try your business or service whereas newsletter are better for communicating with current customers.

Your newsletter subscribers are usually your most loyal customers and fans, so it’s important to treat them better than the more fickle audience on social networks.

But you should also make sure to send out the newsletter announcing, say, sales or new products before tweeting such news.

Video on the web

I’m quoting a quote here, but this perfectly sums up how I (and I would guess a large number of people) feel about video on the web.

As one study participant said, “I probably wouldn’t watch this. It’s a video, not text. I expected an article, not a video. With video, you have to watch the whole thing. Even if it’s just a minute, I’m not into watching video.”

Users were hesitant to click on videos within newsletters if they weren’t sure what they would get.

It’s not just newsletters, it’s the web in general. You can’t scan a video, so users have to make he choice to read it or not before seeing any of it. Most of the time, hey choose to not watch. Essentially, users will watch a video only when they know why (for example a friend suggested it) they should watch it in the first place.

User Login Form Usability Ideas

If you have a site where users are able to have data associated with them, you probably have a login form. You may ask users to enter their email address, or a username for your site, or even an OpenID url. If they enter the correct information, they are granted access to otherwise protected areas of the site. But, if they don’t enter correct information for some reason, they get presented with an error message and have to try again. There are two major hurdles to login form design that I am going to address.

Show their username again

When a user’s login attempt fails, it’s a pretty standard practice to unset their username and password and force them to re-enter them both. This is a bad design pattern. Users should not be forced to remember and reenter their username. Consider this workflow:

  • A user comes to your site, and enters their username and password. The username is entered into a regular text input, so it’s plainly visible to the user and anyone standing over their shoulder.
  • The user’s information was incorrect, so the page refreshes, they see an error message. The user thinks, “Oh, I must’ve mistyped my password”. However, both the username and password fields are now empty.
  • The user tries to login again, however they are momentarily disoriented by having to remember which username they use for this site. Sometimes, users might even have multiple logins for the site, so they have to remember which one they just tried to login with, and even if that username is correct.
  • The user enters their username, and the password again, and hopes to get the information correct.

If the site left the username in the field, the user would not have to remember which username they tried to use, and could focus on typing the password correctly. By leaving the username in the form, you can eliminate a point of confusion for the user, and ultimately help users use your site.

Unmasking passwords

In one off his AlertBox columns, Jakob Nielsen takes the radical position that

Usability suffers when users type in passwords and the only feedback they get is a row of bullets. Typically, masking passwords doesn’t even increase security, but it does cost you business due to login failures. — Jakob Nielsen, June 23, 2009

Personally, I don’t agree with him 100%, but since he’s the world’s foremost expert in usability there must be something to his claim. Security considerations aside, masking passwords does hurt usability. (Masking passwords means displaying bullets instead of letters and numbers — ‘••••••••’ instead of ‘password’) Why? It’s because it forces your users to think about typing their password correctly, and thinking is bad for usability.

It doesn’t matter how many times I have to click, as long as each click is a mindless, unambiguous choice — Krug’s second law of usability

I don’t think that password masking is going away anytime soon, nor should it. It is still a security concern if someone can stand behind you and learn your login information. People routinely store all their life’s information in their email inbox, so if their email account was compromised by a nefarious individual… well it would be bad.

Neilsen goes on to say, “users are sometimes truly at risk of having bystanders spy on their passwords, such as when they’re using an Internet cafe. It’s therefore worth offering them a checkbox to have their passwords masked”. This is a Good Idea, and offers a sufficient compromise between security and usability.

So, for optimal login form usability,

  • Don’t remove passwords after failed login attempts, and
  • Unmask passwords by default, but give the user the option to mask the password, for example when someone is nearby.

Add Dates to Your <title>s

One of the things I noticed from my old blog was that old content can often get mistaken for new content by people who do not read your blog regularly. The main reason is that people can see, right in search results, how old the post is and how significant it might be. Check out this image:

example image

There are two search results here — one that has a date and one that does not. The first one doesn’t give the user any indication of how old that page might be, while you immediately know that the second search result was created on Dec 14, 2009. six months from now, that page might be irrelevant, users can decide for themselves whether they want to visit the page.

If you’re using CakePHP like I am, this is very easy. In your posts controller’s view() function, add this line of code. (Assuming that $postdata is the database entry.)

$this->pageTitle = ''.$postdata['Post']['title'].' - '.date('M j, Y', strtotime($postdata['Post']['published']));

And then in your app_controller.php file, do something like this with the beforeRender() function. beforeRender gets called automatically by Cake just before any view begins to render.

function beforeRender() {
    //create page title
    $title = 'Zastica ';

    if(!empty($this->pageTitle)) {
        $title .= ' &bull; '.$this->pageTitle;
    }
    else {
        $title .= ' &bull; '.$this->params['action'];
    }

    $this->pageTitle = ucwords($title);
}

What happens is that if you set a pageTitle in any controller or function, it is automatically formatted, and your site’s name added. If you don’t set it, it just becomes “SiteName • $action”. As you can see in the image, “Zastica • Seattle” vs. “Zastica • Business Card 1.0 - Dec 14, 2009”.

The bottom line is that it helps users figure out how relevant your site’s content is from search results.