Categories
Links

Josh Clark .vs. Jakob Nielsen on Mobile Usability

Kid gloves are off, and I’m with Clark:

For all of Jakob Nielsen’s many great contributions to web usability over the years, his advice for mobile is just 180-degrees backward. His latest guidelines perpetuate several stubborn mobile myths that have led too many to create ‘lite’ mobile experiences that patronise users, undermine business goals, and soak up design and tech resources.

There are no mobile browsers, just browsers. Handicapping your site on “mobile” is a good way to bug your users and make your site less useful to them.

Categories
Links

Joe’s First Computer Encounter

A Mozilla guy takes a 60-year-old cafeteria worker though the major browsers.

User testing like this is both fun and truly useful to people who make things with a large audience in mind, such as myself. We always attempt to keep what we call “unsophisticated” users in mind, but sometimes you need to go face-to-face to really understand.

Categories
Links

Chrometric – Color-blindness Simulation For Web Developement

This is a useful tool that belongs in every web developer’s utility belt. Color-blindness affects up to 8% of the male population (ladies are safer, only 0.5% are color-blind). Any usability test document that doesn’t test for color-blindness isn’t very good.

Categories
Links

“No Dashes Or Spaces” Hall of Shame

From the Usability Follies dept. It actually takes the same amount of work to check for a valid card WITH spaces or dashes as without. It’s one line of PHP, Perl, Ruby, whatever your flavor of webcode is. No excuse.

Categories
Posts

Usability Question du Jour

Say I’m building a website that deals with data from other websites (social and professional networks, etc), and I want users to be able to enter in their existing profile info into of the application. I can’t just ask for their current username (e.g. http://facebook.com/<yourname>), because some of these websites do not have very friendly URLs (e.g. http://www.spoke.com/info/<somecharacters>/<yourname>) and these may confuse the user. Our mock-up implementation looks like this:

usability_q_1

In the example above, “Sign Up For” send the user to the specified site’s sign up page, and the form element is their ID. It changes based on the site in question, and I don’t think it quite works. What troubles me most (I’m not in love with it being overlaid on the text) is the language, but none of it is something I can’t live without. “Finish this URL” makes it sound like a game, or look like a CAPTCHA, neither of which is what we want. So, UI/UX/Usability gurus: How would you do it? Comments are open.

Categories
Links

Adobe and “Open Government” is Utter Bullshit

Chris Foresman takes on Adobe’s push for government use of it’s Flash, PDF, and other assorted proprietary formats. It’s funny when an article that just presents facts can be so scathing:

After just a cursory browsing, here are some of the usability and data accessibility issues we observed. You can’t select, copy, or paste any text. Your browser’s font override features won’t work, so you can’t adjust the font or its size to be more readable. Your browser’s built-in in-page search won’t work, and you can’t use the keyboard to scroll through the text. …

Sounds pretty open to me.

Categories
Posts

The Safari 4 Beta, Titles, and Ownership Of The Close Button

Safari 4’s public beta has a lot of problems, and while it is “beta” software, I have a feeling that many of it’s biggest usability problems are set in stone. For a company as large as Apple, who releases software how Apple releases software, the “Beta” label means that “we’re pretty close to done, here”. They aren’t going to change the UI very much. Stuff like the awful “tabs-in-the-titlebar” is most likely not going to go away. There are some big issues, and to me, these are the biggest:

At A Glance, The User Cannot Easily Find The Title Of The Page They Are Currently Reading

In versions of Safari previous to 4, the tabs were organized in the (thus-far) standard way: below the menu and title bars, like this:

safari_old1

While not optimal, it works. Like any other application, the user can simply glance at the top of the current window to see the title of the page/document they are currently browsing. For comparison, here is a screen shot from Pages, a part of Apple’s iWork suite:

pages

The current document’s name is presented in the top, middle, of the window. This is, as far as I’m concerned, Good. Some might see this as a bad comparison. Pages does not group disparate documents into a single window, like Safari does. That is beside the point, here. The point is that this is what users are used to, because it is how it works in nearly every other application.

Safari 4’s new tabs create this terrifying labyrinth, similar to Google Chrome:

safari_new

Since the tabs are organized not by any set criteria, but simply by the order they were opened in (or a later, user-defined order, which may be just as informal), the user must now distinguish between not only the two type of tabs (the currently active one and the inactive ones) but having done so, has to hope that the title fits within the tiny space alloted to each given page, active and not. You can see how this gets a little crazy if you’ve got more than 2 or 3 tabs open, or Cthulhu save you, multiple Safari 4 windows open. This is Bad. It’s so bad, in fact, that I hope it’s just some kind of placeholder.

The Window Controls Look As Though They “Belong” To The Left-Most Tab In Any Given Window

Again, Safari 3, this time the top left of the window:

safari_old_topleft

The window controls (Close, Minimize, Maximize), while they are integrated with the title bar, are clearly part of the window itself, and not any one tab. Now let’s have a look at Safari 4 again, this time the top left part of the window, with the new-style tabs:

safari_new_topleft

What is the average user meant to make of this? There are now, effectively, two “close” buttons in close proximity to each other, neither of which is separated from the left-most tab. Their icons are different, but not so different that one could easily tell which is which without knowing a whole lot more about the Mac OS than any random user does.

There is plenty more in the Beta that is worrisome, but these are the two big ones, for me. I hope that by making my issues public that it will push Apple to re-consider some of the planned changes for Safari 4’s release, though I doubt it very much.