Nobody Likes Annoying Interfaces

December 26, 2011 in Web Development

I came upon this blog post by Seth Hoenig titled “Open letter to sites with annoying interfaces” yesterday. In the article he talkes about how some web sites and/or apps hide user interface actions until a later state. The post is a little bit funny and there might be a little bit of truth to it, but mostly it’s inaccurate.

The examples he covers are gmail’s edit-contact page and the button used to edit a project’s description on github. I’d like to talk a little bit about those and then give another perspective on hiding UI elements.

The Gmail example

Gmail’s contact editing is not stellar. But the fact that mr. Hoenig completely misunderstands how it works, really is an excellent indicator of how the whole contact editing page could be better.

Mr. Hoenig believes the delete contact button is only shown when you edit a contact’s name, but really the button he’s referring to is the “clear title” button. What’s wrong about that is a) it shows a trashcan icon b) the tooltip for the icon is “delete” which is really ambiguous c) there’s no other delete button visible.

In order to simplify it’s interface and reduce clutter, the gmail team chose to put the delete button in the “more” drop down menu:

more drop down menu

I’ll admit that it’s very low affordance for that button, but then again, how often do you actually delete contacts? The action is also available from the same drop down when you’re in the contacts list view, in which case you would have a pretty easy time finding the action behind the drop down. So personally, it’s not that big of a problem, in my opinion.

But the problem with the “clear contact name” button is still there, and personally I don’t understand why you would even need a button to clear the name, since it’s hard for me to think of a use case where you would want to clear somebody’s name, especially where it’s not enough to just manually select the text and delete it.

The tooltip is totally misleading as well and the icon doesn’t help. Gmail team: You really should just get rid of that button.

The github example

Now, in the case of the github example, it feels to me like editing a project’s description is an uncommon task. I remember having done that possibly once or twice, and yet don’t remember having any problem finding the button.

Of course you could make the argument that it might be better to show the edit button closer to the description when you hover, but then again, some descriptions might be a bit longer than others, and the position of the button would be different between projects. So this solution is probably fine for the task at hand, in my opinion.

Hiding actions — good or bad?

Hiding user interface elements / actions is a totally valid user interface pattern in my opinion. If you have a lot of actions and tasks you need a user to be able to do, you really have 3 options:

  1. Cluttering everything up with a lot of buttons
  2. Putting the buttons on different pages/dialogs
  3. Hiding them until they are in context

If you clutter everything up with visible buttons everywhere, it becomes much harder to find the buttons you are looking for. It also makes the design more busy and confusing and hurts readability of the content you are viewing.

Having to search for the buttons in different dialogs and contexts is not great either, so personally I feel that 3) is a great solution that both highlights the content you are viewing, doesn’t clutter things up and makes the appropriate actions available when you are searching for them.

There are some other examples of how web sites and apps hide actions until in context, which I would love to talk about in more detail, but I’ll probably leave that for a separate post.

  • Groxx

    I *think* that Github used to allow editing repo descriptions by simply clicking on the text, but the fact that I barely remember it matches your experience – it’s a rare task. As they now have both a description and link field, having a separate control makes a bit more sense.

    Though they’re also wrong about the hover-area for that edit button – it’s the entire gray area below the main nav buttons.

    • Arnor Heidar Sigurdsson

      I didn’t know it used to be that way. You’re right though, interesting that the entire area triggers the edit button to be visible. The description area might be a little bit too small.

  • Arnþór Snær

    There is one point with the github example I’d like to add. I don’t see either you or Seth mentioning it, but I think it’s an important one.

    Seth suggests that since the button is not that ugly that there is no reason to hide it unless the mouse is in a certain area. The problem with this is capturing the attention of the user.

    Like you mention, editing github project description is a rare action. If the button is always visible, then it’s current appearance blends in visually and the user could miss it.
    However if it’s always visible and more noticeable then it’s visibility is out of proportion to it’s frequency of use and importance. Having it appear when the user’s pointer is the description area, is likely to *capture the users attention since it’s the only element on the page being animated*. Like style changes on link hovers.

    Personally, I like option 3 coupled with one big “edit project” button somewhere just outside the project scope. Generally speaking, I like always visible [edit entire object] action and contextually visible [edit attribute] action.

    One app that might benefit from this kind of thinking is OS X Address Book. It has an always visible “edit entire contact” action, but the user is barred from double clicking a single attribute (a phone number or a title for example) to edit that… it feels like the UI is forcing me to do things it’s way.

    • Arnor Heidar Sigurdsson

      That’s a good point and one that I didn’t mention at all.

      Regarding your second point, the OSX Address book, personally I never use it, so I haven’t noticed. I did open it up just to see what you meant, and I agree completely.

      I’m actually a big opponent of context sensitive buttons in general. I think most normal users have a hard time understanding the relationship of “this thing having a different state, results in another button having different actions” — especially if the button doesn’t change (like the caption changing into “Edit Arnor Heidar”) and if it’s placed outside of the bounderies of the object being affected.

      I should probably blog about that.

    • Arnþór Snær

      >I’m actually a big opponent of context sensitive buttons in general.

      Can you give an example of a context sensitive button so I can better understand what you mean?