Chrome Usability Makes It Unusable

27 November 2010

I love Google, and trust it more than most tech companies to be a good shepherd of all things tech.  I tried hard to adopt their browser Google Chrome, but I couldn’t stick with it.  Two major UI blunders made it nigh-unusable for me.

The first, and most unexpected, was their status bar truncation.  Even with a 1600×1200 window, Chrome will truncate URLs to a ridiculously short length, perhaps 30 or 40 characters, replacing most of the path with an elipses (“…”).  Unfortunately, the URL is of utmost importance when clicking a link, especially in this day of Search Engine over-Optimization (SEO), targeted ads, and rotating headlines.

The worst culprit is CNN, who runs several headlines for the same article, seeming to pick at random, in an attempt to either tie their article to multiple wordings of the same story, or to test viewer preference between headlines.  CNN will even link the same story multiple times on the same homepage with different headlines.  For example, today there is a headline that says “Black Friday’s black eye“.  What an indecipherable headline!  Hover the URL and you see the real story they’re pitching in the status bar, if you’re using any browser besides Google Chrome:

http://news.blogs.cnn.com/2010/11/26/thefts-stampedes-make-black-friday-blue-for-some/?hpt=Sbin

The actual story is that there were poorly run stores that let customers trample each other instead of handing out vouchers to a well-managed line of waiting customers on Black Friday.  Just like last year.  And the year before that.  I can pass on wasting any time on this article, but only because I stopped using Google Chrome.  I did hunt for an option to disable this pointless URL-shortening, but with two viable browsers (Safari and Firefox) I’m not exactly sold on hacking the Chrome source to fix such a blatant problem.

The second major issue I had was Chrome’s New Tab behavior.  When I open a new tab, about half the time is to select a bookmark, and the other half is to type in a url for address bar history auto-completion.  In Safari and Firefox, opening a new tab puts the cursor in the address bar of a blank page so you can immediately start typing.  In IE and Chrome, the new tab is made to visit the URL “about:blank”, which then loads (after a brief second of processing during which I would normally have my URL half-typed), and clears the cursor.  Making me move the mouse (or painful-to-use Dell laptop trackpad) up to the address bar, triple-click-delete or home-shift+end-delete, then finally start typing my URL.

I expect both of these behaviors exist because Chrome is primarily targeted at Google’s Android mobile platform, where keyboards and large-windows are non-existent.  It’s great that they target these platforms so well, but I’ll wait until they put some of these basic touches on the desktop browser before I put any more effort into adopting Chrome.  Don’t worry Google, I still love you anyway.

Turning Bad Feedback Into Good Feedback

26 November 2010

One of the biggest challenges designers face is interpreting feedback from users. I’m thinking of the rabid online communities around video games especially, but this applies to any product subjected to users’ brutal gaze before the product launches.

This article on addictive social games included a perfect example — even more telling that it was provided to show how “useless” feedback is:

McMillen said Super Meat Boy was designed without the aid of metrics. And while there was one focus testing session for the game, most of the feedback was thrown out. (One tester suggested that having a static loading screen would be preferable to a cutscene that couldn’t be skipped for the first few seconds because the level was loading in the background.)

The developer apparently disagreed with the tester’s solution and said “What a stupid idea, focus testing is worthless”. This is a very common type of feedback in game forums – bad solutions. Stuff like “Make my character overpowered” or “Throw out this level entirely”.  But solutions aren’t the goal of focus testing to begin with! What you’re looking for are problems.  Then you can have your experienced designers find the best solution to those problems. The trick here is converting the user’s bad solution into a problem, then working back to a better solution.

In the Super Meat Boy example, the user’s solution translates to a meaningful problem that most likely made it into the released game. I’d guess the user’s problem description should have looked like this:

“The cutscenes get old and take too long. I was unable to skip the cutscenes.”

Adding cutscenes to pretty up loading screens is a fine idea. But it sounds like this user may not have realized the cutscenes were skippable at all. Notice the developer says “Couldn’t be skipped for the first few seconds”? Is there any indication to the user that those cutscenes can be skipped after the first few seconds? Or do users mash the spacebar, see that it can’t be skipped, give up, and go get a sandwich? A silent delay in skipping cutscenes could easily cause extinction of the user’s attempt-to-skip behavior.

Maybe text could show up that says “Press spacebar to skip” once the background loading has completed. Or a progress bar could be overlaid at the bottom of the cutscene. Or the cutscene could switch to a blank loading screen after a keypress to help speed up loading (however slightly).

These are some possible solutions that should have been explored as a result of the user’s feedback. From the sound of it, the developer treated the focus testing feedback as change requests, rejected them, and tossed the whole exercise out the window, bathwater and baby. If feedback had been translated into stories about the user’s problems then focus testing would have have been a valuable tool for improving the game.