10 Violated Usability Conventions In 2008

These are not original mistakes, in fact most of them have been violated ever since I started caring about usability. Nonetheless, these are the most glaring ones of 2008.

  1. Styled push buttons
    Most common examples: Admin interfaces (WordPress, Habari), personal websites, high-profile expensive looking websites. Most common excuses: “The default push button doesn’t fit the design”, “We’re trying to create a uniform look across platforms”, “Design matters”.
  2. Other than white background in searchboxes and inputfields
    Most common examples: Personal weblogs.
  3. “Click here” links
    Most common examples: High traffic weblogs (Joystiq, Lifehacker).
  4. Bad link designs
    Most common examples: Small weblogs. Most common excuses: “This is a minimalist design”.
  5. Inability to distinguish links from visited links
    Most common examples: All types of websites. Most common excuses: “Oh right, I forgot that”.
  6. Links open in new browser windows.
    Most common examples: Extremely high traffic websites (Digg).β€”Sidenote: These guys forget Jakobs Law of the Web User Experience: “Users spend most of their time on other websites”.
  7. Full Flash websites
    Most common examples: Movie websites, photographers websites. Most common excuses: “We’re special!”.
  8. Dropdown navigation
    Most common examples: Content-heavy websites (Adobe).
  9. Windows that change size
    Most common examples: Popup image slideshows on news websites.
  10. Content that requires registration
    Most common examples: Digital newspapers (NYTimes). Most common excuses: “Our content is so good, it’s worth requiring registration”.

36 thoughts on “10 Violated Usability Conventions In 2008”

  1. Luke Dorny says:

    #10 cracked me up.

    Great list.

  2. Tobias says:

    How about websites that start playing music/sounds when you visit them, nasty if your listening to music.

    Good list.

    1. Joen says:

      Very nasty, definately one for the ages.

      I’ve noticing that happening more rarely in 2008, that’s why it’s not on the list.

      Commonly today it happens if a video is set to auto-play.

  3. Rico says:

    Thinking about #3. Wouldn’t “Continue” instead of “Click here to continue” lessen the chance of a clickthrough? I mean, there’s a reason why big blogs use it…

    1. Joen says:

      The “click here” problem remains in both your examples; it’s not one of the wording.

      Good hypertext is descriptive. For instance:

      Click here to read about the next episode of Lost.

      … is bad.

      Be sure to read about the next episode of Lost.

      is good.

      While the avid reader will know that both links refer to the next episode of Lost, the second link is not only easier to decipher, it is also descriptive of what you’ll find at the other end of the link. The added benefit of this is that it is search engine friendly. When Google crawls a “click here” link and finds an article about Lost, you get a useless search result. If Google had crawled a link that said “read about the next episode of Lost”, the search result would be useful.

  4. Bramick says:

    10. Content that requires registration

    This makes me so mad!

  5. David Hamill says:

    There are some nice points here. But also some I disagree with. Points 1 and 2 aren’t necessarily a bad thing. It’s how they are handled that matters.

    In some uses point 6 is actually useful. As long as the user is aware it’s going to happen (or expecting it).

    1. Joen says:

      It’s certainly true that handling makes a huge difference. If a button clearly looks like a button, and a searchbox clearly looks like a searchbox, people are likely to manage.

      It’s more difficult than not styling either, though. Finally, usability conventions are guidelines. If you know the convention, it’s easier to break it with style.

      As for links opening in new windows — hmm well, in very odd obscure cases, it is useful, but as you point out yourself, it is of vital importance the user knows what’s going on. And in case of AJAX / inline javascript links, popups, and links that open new browser windows, I have yet to see an elegant solution to distinguishing between the three.

      Good points.

    2. Joen says:

      Here’s an old article I found, where we discuss how to distinguish between link types:

      http://noscope.com/journal/2007/08/visualizing-inline-links

  6. David Hamill says:

    Yes but people need to design web sites to look good. If you tell web designers to make things dull, they won’t listen. Better to explain how to make nice looking site usable. That’s why web designers don’t want to listen to Nielsen on many occasions.

    Which of your 10 errors does your quote link in the comments section fall under? Is it number 4?

    There are plenty of instances where a link is more helpful when it opens a new window. BBC Radio is a good example.

    1. David Hamill says:

      Sorry missed the smiley from the second paragraph :0)

    2. Joen says:

      I appreciate your response πŸ™‚

      To judge myself, the “quote comments” link falls under “mystery meat navigation”, or “saturnic navigation”, where features, sections or important links are hidden behind ill-descriptive icons, only to reveal their titles on rollover.

      You give a good example yourself, and as a purveyer of “good usability”, you should be in complete agreement with me that usability conventions are there as guidelines. Quite simply, the convention states how things are the most user friendly and simple. We, the designers, can then go ahead and make them look pretty, or choose to disregard conventions altogether.

      For instance, I have chosen to disregard good usability in removing the search button. As such, my search is less user friendly, a sacrifice I consciously made.

      These aren’t the ten commandments, you know.

  7. Tania says:

    Nice list, although the way your site loads in my browser poses several usability problems of its own. The worst is the fact that one has to scroll horizontally to see the searchbox properly. Also disturbing is that no banner loads at the top, and the actual content begins to appear more than halfway down the page.

    1. Joen says:

      Horisontal scrollbars are inherently evil, I know, I hate them myself. The width of this layout is based on a number of things, one of them being that 75% of my visitors have a screen resolution capable of showing things. This high (too high) resolution allows me to flaunt my background fetish and show off good artwork in the background.

      It’s a convention, and I’m breaking it.

      As for the topmost square, that is an aesthetic attempt at indicating a strong vertical layout, making use of the fact that the very same topmost area is usually ignored due to “banner blindness” anyway. You mention yourself: there’s no banner. Whether this is a successful attempt, I don’t quite know.

      In a desperate attempt at defending something that’s admittedly not quite user friendly, I’ll quote you William Butler Yeats:

      Had I the heavens’ embroidered cloths,

      Enwrought with golden and silver light,

      The blue and the dim and the dark cloths

      Of night and light and the half-light,

      I would spread the cloths under your feet:

      But I, being poor, have only my dreams;

      I have spread my dreams under your feet;

      Tread softly because you tread on my dreams.

  8. khaled says:

    It’s funny you should mention Habari in your first item, because to my knowledge until very recently (and we’re talking still unreleased and still in trunk) Habari still uses unstyled push buttons; Mike and myself kept hammering this drum again and again, but alas the masses just didn’t care to listen.

    1. Joen says:

      I mention Habari and WordPress specifically, because they’re positioned as David and Goliath. WordPress is the Goliath, and 2.7 is a strong offering. But it’s not perfect, and one of the problems is — yes — styled buttons.

      I’ve followed Habari with great interest, and I’ve seen huge potential in it. Recent developments, however, have somewhat turned me off it again.

      One of the turnoffs was a discussion with Heilemann on exactly that, styled push buttons.

      To be quite honest, I have no problem with styled push buttons when they’re done right. The problem is, they’re almost never done right; they’re usually knee-jerk “woo we can style this baby” reactions.

      Such a pity.

  9. khaled says:

    You and me both buddy. I’ve had no real time to see what’s been brewing on the habari front to be honest. I only saw the trunk version a few days ago and my heart sank when I saw it. The styled buttons, the removal of the single drop down menu to having it with another side opening menu, just adding unnecessary complications to an extremely elegant menu concept that’s effectively bastardised it.

    I would provide it to the people on the mailing list but I doubt it would do any good. I don’t have the energy to write massive emails that peeps don’t read or misinterpret, but how do you convince peeps that they have a great interface design, that just needs some tender loving care in certain areas – which aren’t the ones that have been chosen?

    What’s annoying to me is that it’s still better than the WordPress interface, which again I only recently had a proper look at. I dunno why I don’t like it but I think it’s attributed to the face that there is soo much going on that they seem to be loosing the plot of what is actually important. What’s even more amusing to me is how they seem to have scrapped the Happy Cogs ideas and just come up with something that has good ideas but ultimately feels far too clunky.

    1. Joen says:

      To be honest, I think good things have happened to WordPress in 2.6 and 2.7. Major headway, but certainly steps back. It’s like a dance, two steps forward, one step back.

      I think it boils down to open source development once again. We’ve been through it with WordPress, and I think I can in fact dust up an article called “About WordPress, Usability and Open Source Development” which goes into this exactly.

      The problem is feature creep. Everybody wants to make a mark on the product, so they chop out their little niche. For good products, there’s a profit element to it, if not directly then indirectly (Mozilla). This closes the development group to a number which is possible to control contributions from, and wherein discussion makes sense.

  10. Owen says:

    Joen said:

    To be quite honest, I have no problem with styled push buttons when they’re done right. The problem is, they’re almost never done right; they’re usually knee-jerk “woo we can style this baby” reactions.Such a pity.

    Only getting involved in the project will make that happen. Heilemann never provided a “right” way to do it, he just kept pounding the idea that OS chrome should be used.

    If you (or someone who knows how you want it done and has the time) would step forward to provide buttons that were “right”, Habari could cross itself off your list. The distinct advantage of Habari over WordPress in this regard is that if you provide a solution that works and offers an advantage to Habari users, we’ll use it.

    1. Joen says:

      First of all, thanks for your comment. Openness is the key to success, and let me start this by saying that I truly, honestly, want Habari to succeed. Really.

      If you (or someone who knows how you want it done and has the time) would step forward to provide buttons that were “right”, Habari could cross itself off your list. The distinct advantage of Habari over WordPress in this regard is that if you provide a solution that works and offers an advantage to Habari users, we’ll use it.

      See the thing is, OS chrome is for all intents and purposes, right.

      When you quote me above saying that styled buttons can be done right, I’m essentially saying that if you absolutely must style the buttons, then in some situations, it can be made to work. That doesn’t mean it would ever work better than not styling them at all.

      In the case of admin interface design, very special rules and conventions come into play. They come into play because we know a number of things about the viewer of said interface: 1: only the admin or someone with a login will ever see this interface (it’s the other side of the moon, so to speak). 2: this admin, or admins, are likely to be using this interface a lot, and for a long time.

      Keeping these two things in mind, I find it safe to establish a few core values for such an interface: it must be responsive, it must never ever get in your way, and it must allow admins to get their job done quickly. Respecting these three values, I cannot see any good reasons to sacrifice usability over style, which in every instance it would be, if you styled push buttons.

      Unstyled push buttons, on the other hand, respect these core values for a number of reasons:

      • The interface would look like an extension of the operating system

        In turn, that means people won’t have to learn how a button looks, because it is a system button.

      • It would feature a design that would age with the operating system, meaning there’s a chance it’s designed for timelessness. Styled buttons, in my experience, lose their luster very quickly.
      • Because the button is a system element which users are likely to have seen oodles of times before, it earns a certain anonymity, which doesn’t add detail to an interface. Clever designers can use this anonymity to create minimalistic interfaces. (I hear minimalist is part of the Habari philosophy?)

      If it’s any consolation, WordPress 2.7 doesn’t get it right either.

      The bottom line is, I have never heard a single good excuse for styling push buttons in admin interfaces, and I haven’t seen a single button style that was an improvement over “unstyled”. I find it arrogant to call for other designs when no design is a perfectly suitable solution.

      You know how you’re innocent until proven guilty? From what little I have heard of this “nightly Habary development” debacle, I get the impression that “patch” submissions are awesome unless proven lame. Someone submits a button design that garners some oohs and some aaahs and suddenly we the people have to prove that it is a bad idea? Wrong. Turn it around for a second: someone has to prove that styling the button is a really fricken brilliant idea before the patch ever gets in. Take the other philosophy to the extreme, and you’ll end up with this.

      Let me ask you this: should Google style their search button?

    2. Only getting involved in the project will make that happen. Heilemann never provided a “right” way to do it, he just kept pounding the idea that OS chrome should be used.

      Well, I like to think that the month I spent designing the system from the ground up, the time spent coding and tweaking and retweaking it and the hours and hours of telling everyone why and how much I thought it would be a bad idea to style the buttons might’ve made my opinion heard, but…

  11. Owen says:

    Joen said a lot of good stuff, and I agree that these are valid points of view and in most cases should be of primary consideration when deciding whether to style a button. I’m not discounting any of that. What I’d like is for someone to reconcile those ideas against the following, which seem to me like reasonable dissections of actual usability (and aren’t voiced exclusively by me):

    If only the admins see the interface, and they use it a lot, will they not become as accustomed to the styled buttons in this single interface? Is there a way to measure the inefficiency caused by having a very-button-looking thing rather than an OS chrome-looking thing, and if so, what level of inefficiency is acceptable (if any) in deference to other considerations? I can certainly see an argument against styling buttons to look like something that’s not button-looking, but I’d hardly say that about what the buttons look like currently in Habari.

    Assuming some inefficiency exists, wouldn’t pairing the styles of buttons with the styles of other controls (in Habari, there are “drop buttons” which are similar but different than actual buttons) increase the usability of those unfamiliar controls? And could that be an acceptable trade in loss of usability on a common button, which is still easy to figure out, for increased usability on an uncommon but now similar-looking control?

    If the button is an OS chrome button and ages with the OS, doesn’t that have the potential to clash with the style of the surrounding interface? For example, look at the transition in size of title bars from Windows 98 to XP. If a button substantially changes form in an OS, this could undeniably cause damage to layout of controls surrounding the button. If a consistent custom style for buttons negates this issue, why is the OS chrome better as a long-lasting solution?

    When switching between browsers, different styles of buttons are used. One might suggest from this evidence that it’s possible to create multiple button styles that also don’t add detail to the page and still allow a button to feel “anonymous”. Doesn’t it seems possible that one could design a button that looks like no other OS or browser chrome, yet still has that quality? I think this remains the case with Habari buttons styles. Moreover, why is the onus of style responsibility laid entirely at the feet of the site designers, and not the browser and OS coders?

    Is there are way with OS chrome to indicate visibly whether a button has a particular consequence? For example, in Habari we’ve added subtle color markers to buttons (in addition to their text) that indicate what status a comment will be assigned when that button is clicked. The comments have similar color indicators. Is this not an improvement in usability that is unavailable in standard OS chrome buttons?

    I think that in spite of all the great reasons to keep OS chrome, there are some good reasons to deviate. It’s never been the intent with Habari to say that the OS chrome buttons are ugly and need prettied up, which I agree happens all too often with other apps and I abhor. What I think is that consistent buttons, not just across browsers and OSes but internal to the software as required by nature of the controls we implement, and color hints offer natural improvements to usability.

    If we remove the assumption that the OS has usability “right”, and compare the OS UI and the web app UI on usability in their own right, there is plenty of room for styling buttons. I, for one, have never seen a real-world button that looked like the ones in OSX, so doesn’t that mean it’s not as usable as a button that looks like one that exists in the real world? Since we’re establishing the OS (of which there are many, with many styles) as the baseline, we’ve already crippled an objective look at usability by saying that any deviation from the OS look is impure. This is a bit silly, when the OS look itself is a fabricated representation of a real world interface.

    Should Google style their search button? No, I think not. But: 1) If they did, would that make it substantially harder to find/use? 2) There is no usability advantage for them to do so, whereas other applications might have.

    1. Joen says:

      Excellent points! I salute you!

      But I am not yet convinced.

      Before I to the best of my ability try to refute your good points, I’d like to parallel this with the fascination I have noticed among especially Mac users, a fascination with “cocoa controls”. Reading Gruber (I love that guy), I get the distinct impression that most hardcore mac users really want their apps to look native. That entails using Mac UI widgets and OS Chrome. Keep in mind that some of these, including Gruber himself, thinks some of the Mac UI looks dated, particularly pinstripes. So essentially we have a group of UI centric people, who prefer a native look, even if that look is ugly (pinstripes). Gruber recently commented on Picasa Mac, which doesn’t use Mac OS chrome.

      Alright, to the fray.

      If only the admins see the interface, and they use it a lot, will they not become as accustomed to the styled buttons in this single interface?

      Possibly, but a) that is not reason enough to style and b) because, in this case Habari, is the only “app” to use that button style, the recognition factor is bound to be less than that of OS chrome.

      Is there a way to measure the inefficiency caused by having a very-button-looking thing rather than an OS chrome-looking thing, and if so, what level of inefficiency is acceptable (if any) in deference to other considerations?

      Yes. There are numerous usability studies done on the subject. Not by me, mind you, but by, among others, Jakob Nielsen. Here’s his Top 10 application design mistakes and I think the top mistake applies in this case. That, and Jakobs second law:

      Users have several thousand times more experience with standard GUI controls than with any individual new design

      By that logic alone, your arguments for styling have to be fierce, and your “other considerations” have to be absolutely critical.

      Assuming some inefficiency exists, wouldn’t pairing the styles of buttons with the styles of other controls (in Habari, there are “drop buttons” which are similar but different than actual buttons) increase the usability of those unfamiliar controls?

      I would prefer not going too off topic and discussing the drop-button here, but suffice to say, in the example you cite here the problem is not with the button but with the other styled UI control you’re trying to mimic the design of.

      If the button is an OS chrome button and ages with the OS, doesn’t that have the potential to clash with the style of the surrounding interface?

      I guess, but this sounds like an extremely rare example. Remember, changing the size of a button is not so much a problem. In any case, I hardly think this is a consideration worth paying much attention to.

      When switching between browsers, different styles of buttons are used.

      Which browsers? If you’re referring to Opera’s UI design, I have little but scorn left over for that effort. If you’re referring to the fact that Firefox doesn’t actually use OS widgets, I would prefer if they could, but at least their widgets completely resemble the actual OS widgets.

      One might suggest from this evidence that it’s possible to create multiple button styles that also don’t add detail to the page and still allow a button to feel “anonymous”. Doesn’t it seems possible that one could design a button that looks like no other OS or browser chrome, yet still has that quality?

      The “anonymous style” I’m referring to here, is subconscious, and is related to “banner blindness”. It refers to the fact that we’ve seen OS push buttons so many thousand times that we know by heart exactly what they do. As such, they’re relegated to a different part of the rendering engine in your mind, a place where even if OS push buttons were red and blinking, they’d be “secondary”.

      So no, I don’t think you can design a push button that looks as anonymous as a real OS chrome button.

      Moreover, why is the onus of style responsibility laid entirely at the feet of the site designers, and not the browser and OS coders?

      Oh but style responsibility is laid at the feet of browser and OS coders. You can’t hold the designers responsible for the mistakes of Microsoft and Apple, you can only deal with the deck of cards you have been given. In this deck, unfortunately, the card that says “push button” looks either like a piece of gray candy, or a metal plaque.

      Is there are way with OS chrome to indicate visibly whether a button has a particular consequence?

      Yes. In case this comment box eats the HTML code, here it is in code form; it should “compile”:

      <span style="background: red; padding: 3px;"><button>Delete this comment</button></span>

      By the way, notice how the Gmail “delete” button is not red, yet we know what it does.

      I think that in spite of all the great reasons to keep OS chrome, there are some good reasons to deviate.

      Sure there are. I just still haven’t heard or seen any that apply in this situation.

      If we remove the assumption that the OS has usability “right”, and compare the OS UI and the web app UI on usability in their own right, there is plenty of room for styling buttons.

      That is one hell of a ruleset you’re removing there. Remember, you’re not designing the telephone, the door handle or the space shuttle here. You’re designing an interface for a web app backend.

      But sure, if we’re talking an entirely different metaphor, yes, different rules apply. It’s fine, for instance, for video games to style their buttons.

      I, for one, have never seen a real-world button that looked like the ones in OSX, so doesn’t that mean it’s not as usable as a button that looks like one that exists in the real world?

      One some level, yes. However, because OSX is an operating system which is used every day, people will learn which parts are buttons, even if they don’t resemble their physical metaphor. In fact, if OSX had chosen to design completely flat, bordered buttons, people would eventually learn it any way, and you’d have to deal with that. Again, consider Jakobs second law: Users have several thousand times more experience with standard GUI controls than with any individual new design.

      Since we’re establishing the OS (of which there are many, with many styles) as the baseline, we’ve already crippled an objective look at usability by saying that any deviation from the OS look is impure.

      No, you’re oversimplifying my arguments here.

      Yes, there are many OSes and many different styles, and lets keep in mind that unstyled will fit either of those OSes.

      No-one is saying that any deviation is “impure”, there is far more room for deviation than this button-centric discussion indicates.

      What we’re dealing with here, is a web interface for authoring posts and pages. That means we need text areas, push buttons, radio groups, checkboxes and scrollbars. If you leave them alone, completely different rules apply for the rest of the website; rules such as links are usually underlined, “home” button is usually in the top left corner, and search boxes usually have white backgrounds. There’s nothing to stop you from using a pink Comic Sans as your headline, a psychadelic background and oodles of dancing jesuses to spruce things up. Sure it might be distracting, but for what it is, it wouldn’t violate any standing usability conventions.

      Provided that is, that you don’t style your push buttons.

  12. Owen says:

    There’s something going on with the quotes here that I’m not sure whether it’s me or the site. Sorry in advance if the threading goes screwy.

    Joen said, quoting me:

    If only the admins see the interface, and they use it a lot, will they not become as accustomed to the styled buttons in this single interface?

    Possibly, but a) that is not reason enough to style and b) because, in this case Habari, is the only “app” to use that button style, the recognition factor is bound to be less than that of OS chrome.

    Absolutely granted. I am sure that the reasoning for changing the Habari button styles went in the other direction. We thought about how much of an impact a style change initiated by other factors would have on the UI. As part of our consideration we took the idea that if you’re going to spend time in an interface, you’re going to become more familiar with it. I agree that this in itself is not a reason to do it, but it is taken in contrast to styling buttons for visitors who would only see them once.

    Perhaps more simply put, if it was part of the public side of the blog that we were styling, we wouldn’t have done it.

    Joen said, quoting Jakob Nielsen:

    Users have several thousand times more experience with standard controls than with any individual new design

    By that logic alone, your arguments for styling have to be fierce, and your “other considerations” have to be absolutely critical.

    Does this credo impact public sites at which visitors hit-and-run more, where instantaneous recognition of standard controls is essential, or single-purpose application interfaces? One could argue that the use case for styled buttons in an installed blogging application is more similar to a video game than to a web shopping cart.

    Nonetheless, that is the crux of my opinion on this issue. Sure, you use your OS more than your blog app, but you use your blog app back-end enough that, just like with your OS, you can learn fairly quickly and completely that the thing that looks a whole lot like a button is actually a button. And since being different from the OS chrome is the only way that it violates any of what people do wrong with buttons, it’s really not so utterly horrible. As a bonus, it looks like the other controls in the app, and it doesn’t stick out in OSX like a glowing blue crystal in an otherwise monochromatic UI.

    I didn’t take the time to point out last time that I otherwise emphatically agree with item #1 on your list, particularly on sites where visitors aren’t guaranteed to take the time to become familiar with the interface.

    By the way, notice how the Gmail “delete” button is not red, yet we know what it does.

    Sure. Whether it should be red is a question of whether making it red would make it faster to recognize what it does. I don’t think it would because when a message is deleted it does not appear in red. On the other hand, the color-hinted buttons for comment statuses in Habari associate to things you can see on-screen. Is this noticeable to users and more efficient for them? I don’t know for sure, but I think it is.

    What is amusing to me is that on the day all of the Habari button controversy started, I had updated my install. When I looked at the UI, I couldn’t figure out what the heck people were so upset about. It wasn’t that I thought the newly styled buttons looked fine, but that it didn’t occur to me that they had looked some other way prior to the update. So when I look at this particular case of buttons being less usable because they’re styled, I’m skeptical.

    1. Joen says:

      It really is a pleasure to discuss with you. Sound arguments and openness, even if I still don’t agree with you. And yes, there is some funkiness with quotes and so on. I’ve tried som real time debugging and I’ve tried to enable comment editing and turning off “curly quotes” to alleviate the trouble. Sorry about that.

      On with it.

      Perhaps more simply put, if it was part of the public side of the blog that we were styling, we wouldn’t have done it.

      Ironically, that’s the part of the Habari distro where it would have done the least damage, as people are likely to restyle that aspect any way.

      Essentially, I don’t buy this as an excuse to style the buttons. It’s an apology that’s been scoured from the depths of discussion, and it lacks punch.

      Does this credo impact public sites at which visitors hit-and-run more, where instantaneous recognition of standard controls is essential, or single-purpose application interfaces?

      Both, since neither are operating systems or video games.

      One could argue that the use case for styled buttons in an installed blogging application is more similar to a video game than to a web shopping cart.

      You could argue that, and it would be a good argument. But it wouldn’t be a sufficient argument. The reason why it’s okay for video games (and just to be clear, I’m talking larger, primarily fullscreen video games, Xbox and so on) to style buttons and interfaces out of the wazoo, is that when you start the video game, you enter a different paradigm. It is somewhat comparable to when you put a video on (or even read a book): you lean back and prepare for entertainment. When you’re in that mode, you’re prepared to enter a “universe”, to immerse yourself in a virtual game world. In this case, to keep you in that ‘verse, radically different user interfaces can be appropriate. The fact is, you’ll have to learn how to interact with the game any way, which is why most modern games come with tutorials.

      Good example: Dead Space. There’s little or no actual UI because the game company has tried to make the UI part of the game. In this screenshot, the lead avatar is looking at an in-universe projection of a configuration interface, so basically you’re exploring that interface with the main character. Also notice the energy bar on the back of the character. That’s life force.

      Whether such an interface is successful, I don’t know. Usability conventions do apply, even here, but different ones than those that apply to website and website backend interfaces in particular.

      Sure, you use your OS more than your blog app, but you use your blog app back-end enough that, just like with your OS, you can learn fairly quickly and completely that the thing that looks a whole lot like a button is actually a button.

      You make it sound as though it’s a minor detail, as though it’s a problem that’s silly to point out because after all, it’s just a button.

      It’s not a minor detail. The button is, perhaps, the single thing against which the entirety of the rest of the interface is built around. In fact, if you are prepared to sacrifice usability in favor of “fitting with the rest of the interface”, then I’m reading into that that something is wrong with the rest of the interface. Having seen Michaels mockups from early on (he even asked me personally for a usability review, which I gave), I have the impression that Habaris backend interface is mostly good, in parts bordering on awesome. So on one hand you’re referring to a problem I don’t see, and on the other hand if you’re referring to an actual problem of consistency across the latest Habari UI, then I would honestly wager the problem is elsewhere.

      Okay that last paragraph was a bit cryptic, I hope it’s decipherable.

      I didn’t take the time to point out last time that I otherwise emphatically agree with item #1 on your list, particularly on sites where visitors aren’t guaranteed to take the time to become familiar with the interface.

      Very gracious of you. Even so, I’m still not seeing the necessity of styling push buttons in Habari. And as I mention, somewhere in this plethora of text, styling push buttons on websites and website backends should only be done when absolutely necessary.

      On the other hand, the color-hinted buttons for comment statuses in Habari associate to things you can see on-screen. Is this noticeable to users and more efficient for them? I don’t know for sure, but I think it is.

      Firstly, I have admitted that there can be instances where styled buttons can be appropriate. Having not seen that specific aspect, I won’t deny that this could be such a case.

      Gmail as a web interface is somewhat comparable to Habari, as it is used administratively by a lot of people. Gmail elegantly avoids styled push buttons almost across the entire interface, the notable exception being the “contacts” interface (which I also think is the weakest part of Gmail). Take the compose link, for instance. Most other webmail interfaces I have seen, use a push button for “compose”. Gmail uses a blue, underlined link. Have you considered underlined, possibly color-coded links, for comment statuses in Habari?

      So when I look at this particular case of buttons being less usable because they’re styled, I’m skeptical.

      Please keep in mind that you are a highly intelligent power-user with a vast computer experience, including (I assume), experience in actually building computer interfaces. On the other side of the spectrum is my mom. Okay I admit, she’s unlikely to use Habari any time soon. But she loves Facebook.

    2. Owen said:

      [..] On the other hand, the color-hinted buttons for comment statuses in Habari associate to things you can see on-screen. Is this noticeable to users and more efficient for them? I don’t know for sure, but I think it is. [..]

      The colour-hinted buttons as seen in the demo admin interface? (Oops, I mean click here.)

      Because OS-style buttons with coloured lines underneath seem like a reasonable compromise. You keep the I-know-what-that-does! OS-button advantages, but lose the not-adding-extra-detail quality. However, because the coloured lines under the buttons match up with the colours on either side of the comments in moderation, it does allow you to get a lot of relevant information quickly while scanning the page. (Such as “how many unmoderated or spam comments are there?”)

      I must say though Owen, I do think you’re selling Heilemann short. It seems like his voice isn’t attributed as much weight as you’d expect for an expert who’s put a lot of time and effort in.

  13. Morydd says:

    I’m not sure I follow the argument that “native” or “unstyled” buttons are more useable. If we look outside the web, I’m willing to bet that each of us has dozens of buttons around us in the room we’re in. Each of which is styled for the item it’s attached to. The power button on my television is in no way similar to the power button on my computer, which is in no way similar to the power button on my cell phone. Yet, I recognize what they are and what they do in fractions of a second, and even faster after the very first use.

    Also, I use multiple operating systems and distros. XP at work, Ubuntu on my machine, Debian on my server, Vista on my wife’s laptop, and every now and then a Mac. So, that’s at least 4 styles of “native” buttons that I see regularly.

    Additionally, I find white on a dark background very distracting, and black text on white to be difficult to read in any quantity. Yes you have to be careful with your color choices, but they don’t all have to be black and white.

    1. Joen says:

      In essence, Jakobs 2nd law should be response to you:

      Users have several thousand times more experience with standard controls than with any individual new design

      Translation: Users have several thousand times more experience with the controls used in their main user interface, than with the design of the buttons in Habaris and WordPress’ backend.

      I go in depth in my recent comment directed at Owen, particularly this part:

      I, for one, have never seen a real-world button that looked like the ones in OSX, so doesn’t that mean it’s not as usable as a button that looks like one that exists in the real world?

      One some level, yes. However, because OSX is an operating system which is used every day, people will learn which parts are buttons, even if they don’t resemble their physical metaphor. In fact, if OSX had chosen to design completely flat, bordered buttons, people would eventually learn it any way, and you’d have to deal with that. Again, consider Jakobs second law: Users have several thousand times more experience with standard GUI controls than with any individual new design.

    2. Morydd says:

      Perhaps users have more experience with the buttons in their OS than they do with the buttons in the web apps they use (“several thousand times” seems like one of those phrases that means “a lot, but how much more is a guess as there is no actual reliable data”) but users have even more experience adapting to the environments around them. The fact that the keyboard on my laptop is black instead of the beige I was previously familiar with didn’t make it any harder to use.

      I think it rather does a disservice to your users to believe they’re not smart enough to figure out, with minimal difficulty, that a styled button that says delete does the same thing that an unstyled button that says delete does. Yes, the very first time you use a new app, or physical object, you may have to spend a second or two figuring out where the controls are, but that’s the case regardless of what the styling is.

    3. Joen says:

      Morydd said:

      I think it rather does a disservice to your users to believe they’re not smart enough to figure out, with minimal difficulty, that a styled button that says delete does the same thing that an unstyled button that says delete does. Yes, the very first time you use a new app, or physical object, you may have to spend a second or two figuring out where the controls are, but that’s the case regardless of what the styling is.

      I’m not saying people can’t figure out where the buttons are. I’m counting on the fact they can do that.

      What I’m saying is that in an admin interface such as Habaris or WordPress’, there’s no reason why they should have to!

      I still haven’t heard one good reason why it’s worth sacrificing usability over design.

  14. Joen says:

    As a sidenote to this discussion, in my experience, open source design does not work in a democracy, only in a meritocracy. http://en.wikipedia.org/wiki/Meritocracy

  15. ahem

    1, 2, 5 – Guilty your honour!

    In my defence, I obviously run a “high-profile expensive looking website” so I’m guessing it’s all good. I’ll expound on why I violated them (at the time, in 2005):

    1) A mix of “because I could” and “because they need to fit in with all the styled text-areas and input boxes”. The latter not just for colour, but also size and form.

    The whole design was an excersise in taking subtlety as far as I could while trying to alieviating possible usability problems by being as clear and straightforward as possible. I think it worked well enough on the comment form, but that the search-bar isn’t any good for people who don’t have ultra-high-contrast-vision ™ and a perfectly calibrated monitor at just the right angle.

    2) Subtlety. My reasoning was that white would be too jarring. The proper solution is of course to use the border to take away the jarring whiteness of the text-area. In my defence I did make the input-background a lot lighter than the surrounding background.

    5) Couldn’t find a nice contrast colour that would say “this is a link, but it has been visited”. More a problem of limiting my colour palette too much than anything else – must move out of the duo-colour designs.

    The rest I do keep to and am very supportive of. Especially “click here” – I mean, even back in 1997 that fround upon! Also, the irony of horridly styled buttons on the “ajax edit comments” screen doesn’t escape me:)

    Could you explain what you mean by (4) Bad link designs?

    1. Joen says:

      Light 7 candles and do 14 Hail Jakobs and you’re forgiven.

      Obviously it’s all a matter of context, audience and purpose.

      Also, the irony of horridly styled buttons on the “ajax edit comments” screen doesn’t escape me:)

      Yes, I know, they are awful. Lay it on me, I shan’t even defend myself. Save for the fact that I just desperately wanted an edit feature to work in time for this fiery debate. In good time, I’ll give that area som TLC.

      By the way, did the edit feature work as intended?

      Could you explain what you mean by (4) Bad link designs?

      Yes.

      A bad link design is a hyperlink that doesn’t look like a hyperlink.

      The most simple hyperlink design there is, consistst of blue non-bold, non-italic, underlined text. As such, the attributes that make a link look like a link are

      • Distinct color contrast
      • Underlines

      or a combination of the two.

      On some websites very high-traffic websites, Wikipedia, CNN and so on, it would be a very good idea to stick to blue and underlined.

      On more “designer savvy” websites, you could probably go with any contrastful color and an underline, even if it was dotted.

      Bold, contrast-colored text would be a stretch.

      Bad link designs are usually low contrast as compared with the rest of the text, and has little that makes them look distinct.

    2. Joen said:

      By the way, did the edit feature work as intended?

      It did, it was very smooth. Once you’ve edited your comment your name appears twice on it. The only downside to it is the small & wp2.6-like editing box.

      Joen said:

      A bad link design is a hyperlink that doesn’t look like a hyperlink.
      The most simple hyperlink design there is, consistst of blue non-bold, non-italic, underlined text. As such, the attributes that make a link look like a link are

      Distinct color contrast

      Underlines

      or a combination of the two.On some websites very high-traffic websites, Wikipedia, and so on, it would be a very good idea to stick to blue and underlined.

      Ah, right. Completely agree with you. I’d also like to add “hover the paragraph to underline+colour” links to that. It makes it impossible to scan an article in one go.

  16. Owen says:

    Joen said:

    Please keep in mind that you are a highly intelligent power-user with a vast computer experience, including (I assume), experience in actually building computer interfaces. On the other side of the spectrum is my mom. Okay I admit, she’s unlikely to use Habari any time soon. But she loves Facebook.

    Ye Gods. You mean I have to account even for Facebook users now? πŸ™‚

    I think we’re at an impasse. My most persuasive arguments for an exception to the rule don’t seem to move you from an unfaltering adherence to it. I think that even if I am sacrificing some usability in one place, the gains in other places are worth that cost. You’re of the opinion that there is no compensatory gain in doing this, only the cost. Of course this is oversimplified for brevity – no need to rehash individual points.

    I think the only thing to do now, if we want to see what’s right for usability in Habari, is to run actual user tests. I found a place that will do user tests for $100 for 5 users. Assuming that a fair test plan can be concocted, what might it look like, and how would we interpret the results? I think that the test should at least determine how adversely the non-standard buttons affect users, and whether the color hints provide any usability benefit. I’m not a rich guy, but I’ll put up the cash if someone helps to write an unbiased test plan just to see if there is a case for an exception. I think it would be an interesting and useful experiment with tangible and potentially definitive results.

    1. Joen says:

      You mean I have to account even for Facebook users now? πŸ™‚

      You don’t have to, but you should, and there’s no reason not to πŸ™‚ (which essentially sums up usability advice).

      You’re of the opinion that there is no compensatory gain in doing this, only the cost.

      The thing is, I really can’t take credit for “discovering” this usability convention. I don’t even think Jakob Nielsen can. I’m just reiterating it, because I want to help.

      I think that the test should at least determine how adversely the non-standard buttons affect users, and whether the color hints provide any usability benefit.

      I would never ever recommend against real world usability testing. Working on various projects, I have seen myself how effective even home-made ad-hoc usability tests can be. We bribed a bunch of kindergarten kids with pizzas and candy (which they were given after the test) and watched them solve a few tasks. It was frighteningly effective, and the things we thought were obvious were completely ignored. I’ve been beaten back to the drawing board by 10-year-olds, so many times it’s not even funny any more. Well, yes it is, but you get the point.

      Be all that as it may, I’m giving you this advice so that you can take shortcuts. It’s not like these things haven’t been tested oodles of times before; usually whenever Jakob Nielsen writes something in his, admittedly ugly website column, his observations stem from real world usability tests and results. Sure, the Habari website is not Amazon.com, but perhaps some of the lessons learnt are the same?

      In my mind, usability testing of the Habari interface would be far more beneficial if users were given tasks such as “write a post”, “publish a page”, “delete a comment”, “mark a comment as spam”, “change your password” and so on. Giving them a task that says “point out the push buttons” seems futile. If you must test for styled buttons, and do not believe me, Heilemann or Jakob Nielsen, then at least test two interfaces for usecases like the ones I mentioned; one interface sporting unstyled buttons.

      I’m so convinced that styling buttons in Habari is a generally bad idea, that if you provide conclusive usability results that prove me wrong; results that show without a doubt that styled or unstyled made no difference, then I promise I’ll send you a signed poster for free in the mail. — You know, in good faith and all.

Comments are closed.