http://code.google.com/p/chromium/issues/detail?id=12035

Comment 116 by drew.ramos, May 11 (41 hours ago)
Thanks for the comments! Here are some download links: http://www.filesavr.com/chromium43024 (build of
revision 43024, this is the one I use since it looks like the current Chrome for Mac beta, omnibox-wise) and
http://www.filesavr.com/chromium46672 (build of revision 46672, fairly close to the latest dev build).

Thanks also for ending the speculation about the tab close button. I’m familiar with the aesthetics issue; in feedback about Camino’s tab UI, it runs a very distant second to complaints that we have site icons at all (which is to say we hear it about once a year). Since you seem to be saying that the tab closing behavior optimization didn’t require the close button positioning, I think there’s even less to support putting it on the wrong side; I don’t think the aesthetic issue is strong enough to warrant violating the Mac OS X UI grammar.

Something I haven’t seen mentioned,but I was under the impression that G Chrome also had a very slight delay before closing a second tab. I have the feeling there is a very short moment (in ms) during which the button is non functional. That would avoid the accidental closing of a tab by ‘double clicking’, I think. Or maybe I’m just too slow with a mouse… a real possibility.

(oh, and one more for the Mac UI police. The close button on the last/only tab should be disabled or hidden. That is the default on all Mac apps; even Firefox finally implemented this after I filed a bug)

As one of the designers (though not the primary one) who had a hand in Chrome’s tab closing behavior, here are a few bits:

* Serial closing of tabs is used by an enormous number of users (including many team members). It is quite common in scenarios where users have opened several tabs related to a single task, and are ending the task. While it’s also possible to pop open a new window for a task, or drag tabs out to create one, most users don’t go through this extra step. Another common scenario is when users have opened a large number of links as a “to-read list” from e.g. an RSS reader or news aggregator, and are finished reading them; sometimes users will have closed the tabs as they go, but not always, especially if (similarly to the first case) the pages are in some way related.

We tried to optimize both closing from the right and from the left (or middle) because users prefer one or the other depending on whether they’re stack- or queue-based readers. (Interestingly, this same distinction often determines whether users want newly opened tabs to take focus by default or not. We’ve avoided inserting an explicit option to control this behavior but users can control it via modifier keys while opening the links.)

* Whether the close button is on the left or right side of a tab on the Mac had nothing whatsoever to do with serial closing behavior. It was 100% an aesthetic decision. Putting tab close buttons right next to favicons made tabs look unbalanced and confused targeting. Working around this by removing favicons dropped too much information on the floor. One of our Mac people even confessed to liking this arrangement because “now window close is on the left and tab close is on the right and it’s easy to train my muscle memory” or something to that effect.

Yes, this is atypical for Mac UI. On every OS, we elected to defy convention if we felt there was sufficient justification. Some cases required more justification than others. This particular one has not been very contentious; a small number of OCD users (and I say that with love because I am one) complain and no one else cares much. Things like the amount of space above the tabstrip or whether clicking in the address bar selects all have been more contested.

As for the tab close button versus the search field’s cancel button, those are two entirely different actions. There’s a vast difference between cancelling a search (or filter) and closing a document (because tab contents, like window contents in document-based applications, are documents; Safari makes this very clear in its AppleScript dictionary, where document is the all-purpose term for “current web page” and where, prior to Safari 4, “tab” wasn’t even a term). The fact that the similar glyphs perform two separate functions argues for putting them on different sides, to help the user differentiate: this glyph on the left side makes the document and its container go away, while a similar glyph on the right side just cancels filtering.

As for Windows, I’d hope that Google would follow whatever interface guidelines exist for Windows, too, but this post isn’t about Windows.

Yeah, you’re certainly right that there’s a cost for everything. Still, I do find this Chrome feature very convenient (and I found the Firefox way a inconvenient even before Chrome came out).

About *why* I close many tabs: When needing to check several pages, sometimes it’s just faster to open them all at the same time, then check them one by one. This way it’s not necessary to wait separately for each page to load before being able to check them.

Now the truth it that why exactly I close them at the same time rather than one by one after checking them I do not know. To be honest I did not pay very much conscious attention. But I did certainly notice that it happens.

Another, more common reason why I close many tabs at the same time is simply that sometimes there are too many of them, and I want to get rid of some to clean up… If I only want to keep one tab, then I use Right click -> close others. But if for some reason I need to keep several, then I just close the unneeded ones. Tabs tend to get clustered by related content, so those that I close are usually next to each other.

I don’t really use the close button, I mostly prefer middle clicking, however, the shifting of buttons still makes it possible to keep close attention not to close the wrong tab.

Think e.g. about the “Erase search text” button that pops up in the right side of the search field in Apple’s own products (Finder, Safari, iTunes, …). This is a “close button” of sorts – would you also say that it should be on the left side for consistency?

And what about tabs themselves? By your argument, shouldn’t we use a traditional MDI user interface on Windows, to stay consistent with Microsoft user interface guidelines?

It’s important to keep in mind that there’s a cost to everything—every feature, every setting—so it’s important to evaluate the reasoning behind a feature/setting, the number and type of users who “need” a feature/setting, and so forth, when deciding what to implement and what not to implement, and even how to implement it. There may actually be a better way, either in cost or usability, to help users accomplish the task they want to accomplish than the way the users themselves suggest.