Chrome for Mac: The Experience is in the Details

Don’t get me wrong. I love Chrome for Mac. The simplicity, the screen real estate, the speed – it is my current browser of choice. Throughout the development of this site, I preferred to evaluate it aesthetically through the frameless monocle of Chrome.

But something doesn’t feel right. Google missed something.

It’s not just that the software isn’t perfect. Nothing ever is (and it’s still beta software).

I’ve been using Chrome for about a week now, and the little things that bother me are starting to add up. I’m not just talking about lack of in-browser support for PDFs, choppy rendering of heavy sites while altering the window size, or easy indicators of a site’s RSS feed. I know these features will come in time.

I’m extremely sensitive to design inconsistencies. Apple’s done a pretty phenomenal job ensuring that software that’s written their way is consistent in UI and behavior. It’s almost relaxing to use software developed to the Human Interface Guidelines specifications. Every single behavior and placement is expected. Apple cares about every pixel, and the behavior of every single keystroke and mouse click.

This is where Chrome falls short. The tiny nuances that are generated deep in the software stack matter. They matter a lot. I don’t know all the details of Chrome’s implementation, but I know it doesn’t quite feel like a native Cocoa app.

I’m upset that in Google’s genius (I really mean it) decision to place the tabs above the Omni Bar, they screwed up the title bar buttons. In their rewrite of the standard title-bar, they somehow lowered the close, minimize, and zoom buttons by two pixels. This just seems careless.

Chrome Bar Buttons

The implementation of the red “circle x” image that appears when a user hovers over the matte “x” to close a tab is horrendous. There is no other attempt at a 3D graphic anywhere else in the entire application. Nor is there any global light source to justify the half-hearted attempt at a shine on the top. In fact, when viewed against the standard shine on the bar button items, it looks especially tacky. I have another issue with the hover graphic. As it tries to match the same “x” size as its tasteful counterpart, the matte “x”, the circle must take up a larger area. When the title of the page just barely fits in the tab (as seen in the graphic below), the red “circle x” spills into the empty space intentionally left to be aesthetically pleasing, and awkwardly juts up against the text.

redx

The position of the “x” has been widely debated by others, and I buy into Google’s strategy here.

There is one more example that really screams at me. In all standard Mac OS X applications, a user can select text, and then drag the text to any appropriate location. The interface for this is snappy and intuitive. A lighter version of the highlighted text moves with the cursor.

safaridrag

Google has decided to use some type of proxy for this. This is disappointing. Their choice doesn’t even really make sense. There is a small image of a globe. This is for text, images, and anything else draggable. Perhaps it is a “global proxy” for anything you drag? I have no idea, but it’s annoying.

chromedrag

I’d liken it to earlier versions of Mac OS using a proxy outline of a window when dragging instead of moving a the whole window. The upgrade was just flat out refreshing.

I hope someone from the Chrome team is aware of these issues, and cares as much as I do. I can’t wait to see what fixes and features are added with future releases. It’s a beautiful browser, but it needs some serious work on OS integration. Mac OS X users expect a certain quality of native applications. Where would we be if we didn’t deliver that quality?

You just can’t skimp on the little details.