in User Interface

The Curious Case of the Gmail Buttons

Earlier this week, when checking my email, I noticed that our friends over at Google had made a couple changes to the buttons above the inbox.

New Gmail Buttons

For reference, this is what the buttons looked like before the change (and without my custom theme):

Old Gmail Buttons

The first change, adding the Move To and Labels controls, are welcome changes.  The other change, redesigning and removing the spacing between the buttons, not so much.  The reason for placing the buttons flush against one another is likely the result of, after having added more buttons, deciding that this increased quantity of buttons warrants the need for grouping them.  While that’s all good and well, the decision to actually have the buttons completely flush against one another was a bad decision indeed.  Unwittingly, the geniuses at Google have not so much created a group of buttons but really instead created what visually is–particularly for the rapidly scanning and hunting Steve Krug archetypal web user–one big honking button.  This means that every time I want to take the very very common action of deleting something, I can’t just target the delete button, I have to scan the Gigantor-button to find the part within it that contains the delete section. And after having used this redesigned version for a few days now, I am still finding myself scanning for the delete portion.

This type of UI flubber, a bad design choice that on one hand really only leads to a fraction of a second’s delay, is what I call a micro-annoyance.  Now, let’s say this micro-annoyance appeared on some registration form.  That wouldn’t really matter too much since I would only have to deal with it once.  But when it appears on something that I use every day, all day, all the time, that changes everything.  Suddenly it is significant.

What’s truly annoying, though, is how easy it would be to fix this issue.  Just add a couple pixels of spacing between each of the buttons.  Something like this:

Gmail buttons with spacing added between buttons

You basically get the best of both worlds – you keep your button grouping, while also removing the micro annoyance of making me scan for the Delete button every time.

  1. I’ve lost my buttons altogether – well… there are three of them present (without any labels to identify them visually). They seem to work OK when I hover over them with the mouse I can identify them (preview shows what they are) but they are essentially “blind click” buttons now – Anyone else have this problem? Solution? I’m running updated MSW7 and always update my computer regularly… not sure what happened but the new “look” isn’t helping me much at the moment.

  2. Hi Damon – I’m going to check out Information Dashboard Design. Looks like an interesting read.

    On one hand, I definitely agree that use of icons would make something like a delete button pop, such as using a trash can or a red circle with an ‘x’ in it or whatever. I’m guessing one reason they didn’t use icons don’t scale that well and get less useful for less common operations, such as “Mark as Read” – a Labs feature I added – not sure what the icon would be for that.

  3. I don’t remember which book I got this concept from, perhaps “Information Dashboard Design” which shouldn’t contain the word dashboard as it is a great book whether you want to do dashboards or not, but basically if you have them flush, your eye/brain can’t help you. Your eye/brain can do amazing things for you almost instantaneously without you consciously thinking about it for things that match certain criteria for patterns. And when you ignore these things in your design, the user ends up having to use their slow conscious thinking process. “Let’s see, that’s a button I guess, but it isn’t delete, how about the next section?”

    Personally, I think they should use some icons because then your eye/brain can *really* help you out: no slow reading is required.

  4. My understanding of Fitts Law is that it relates to targeting in relationship to size and distance. I guess this could be interpreted to imply that there should be no distance between buttons. But it would seem as if other factors are at play here, such as the ability to visually distinguish where one button ends and another begins. The current design, with a 1-pixel border, doesn’t make that easy at all. In other words, when I want to use the delete button, it is not so much an issue of being able to target the button with my mouse, and really more an issue of being able to see where it is. Applying Fitts law, then, the decision to place the buttons flush against one another should perhaps have been accompanied by also making them somewhat larger.

  5. Fitt’s Law, in fact, suggests that menu buttons *should* be flush against each other, preventing another kind of micro-annoyance — missing a button entirely because you’ve clicked on the small gap in between them, or just plain spending extra time aiming at a button and avoiding clicking the gap between the buttons. I’ve long been of the school of thought that moving from one button to another in a toolbar or menu area should produce no flashing cursors and no “dead spaces” between buttons. This structure should absolutely be combined with a clear rollover state behavior indicating which button you are rolling over (I don’t use gmail so I don’t know if the new or old UI had this) — this corrects errors of pressing the wrong button better than simply putting a safety gap between the buttons.

Comments are closed.