Google Chrome - Epilogue and Reader Feedback

I got a lot of great feedback from my previous post higlighting why I hated using Chrome yet continued doing so. The feedback ranged from the dismissive to the supportive. In the process, some readers highlighted good and bad things about Chrome I missed that I wanted to highlight in this follow-up post.

Before I get into the feedback though, there were a couple of points I wanted to expand on:

On the status bar

When I wrote the blog post, my complaint about the status bar mirrored that of the search bar: It overlayed the contents of the page. That presented other problems, which had to have their own solutions. When it comes to the status bar, my suggestion wasn’t to go the Safari route by making it a permanent bar (which in my opinion is inferior), but that the status bar as a whole is a useless relic from the olden browsers.

Having had a bit of time to think about it, I think a solution would be to remove the status bar altogether and instead place the hovered-url in the address bar itself. The address bar (or omnibox, as it’s called in Chrome parlance), provides the context of the current and future location of the page.

The assumption I’m making is that people use the status bubble to see what URL a link will take them to. By placing the hovered-url in the address bar, you also eliminate a mental step the user has to go through: Instead of hover, look at the bottom left, click, and then look up at the address bar, you just hover, look at the address bar, and click to commit the action. Moreover, you eliminate a confusing element from your browser!

On the search bar’s behavior

There seemed to be a bit of confusion regarding what I was suggesting when I complained about Chrome’s search bar. My complaint was that it overlays the contents of the website, not that it was inlined to the window. In contrast, Safari’s Search-in-Page UI is far superior in my opinion, since it is still inlined to the page, but it shifts the contents of the page down as it reveals itself. The separate window for searching the contents of a page was a terrible idea and I’m glad it’s largely history at this point.

On Chrome Develepor Tools’ non-native toolbar

Wes Campaigne wrote to highlight a bug he filed over a year ago

The reason I decided to include this comment here because it highlights an aspect of Chrome which I think is the root cause of a lot of issues. Specifically:

It is not as easy as it might seem – we are talking about dragging native window by the tabcontents content. I think in Safari, toolbar is transparent and we are dragging by the window itself.

Chrome is a cross-platform browser and shares a lot of code between its Windows, Linux, and Mac variants. To achieve that goal, they have to fake a lot of native behavior in their cross-platform components. What’s interesting about this though, is that I checked out the Chrome codebase and as far as I can tell, Chromium (the open-source codebase for Chrome) uses a shared component but the UI layer is built specifically for each platform.

Chrome’s open-tab behavior

Chris Karalus writes to highlight Chrome’s new-tab behavior. If you open a new tab, Chrome intelligently places that new tab adjacent to the current one. This creates a natural grouping of related tabs with no explicit user action. This is UX at its best: Interpret the user’s intent, and let the UI adapt to it.

On the download bar

callahad on Hacker News wrote :

Actually, in OS X, the Chrome icon in the dock has a small pie chart overlay during downloads that indicates both the number of pending downloads as well as the aggregate progress of all downloads. If your dock is hidden, you can quickly and easily check the progress by hitting Cmd-Tab. In Windows 7, the “tile” in the Windows “Dock” fills from left to right, like a progress bar, to show the aggregate status of downloads. You can also click on the in-progress download, dismiss the dialog, and the file will open once the download completes.

On the preferences pane

callahad again from Hacker News :

you can actually link to specific pages and panels. Though this doesn’t help you find a preference in the first place, it does make communicating the location of known preferences much simpler.

On integration with OS X

Kurt Landrus writes:

The one feature missing in Chrome and Firefox that keeps me in Safari, is the ability to drag or copy Rich Text from the browser to another app like text edit or MacJournal, Chrome and Firefox only copy plain text. I use this all the time for research.

Conclusion

The response I’ve received seems to suggest that a lot of people weren’t aware of any of these issues. The post also seems to have generated a healthy debate regarding the merits of my arguments and their objectivity. Whether you agree with my complaints or not, I think it’s important to take a critical look at the software we use every day.

On a separate note, it seems like the Chrome team has taken notice of the complaints and there are been bugs submitted to track those issues. Hopefully some good will come out of my ranting!