Disclaimer

Before I get any further, I want to point two things out.  Firstly, Google Chrome is a very early beta product.  It’s not ready for your Gran to use yet, it may not be ready for you to use yet, depending on your disposition. So tread carefully.  And let’s take this as an IR beta, and not a Google beta.  I don’t expect it to be flawless, neither should you.

Secondly, I’m an OSX user (you’ll find that many people in the field of user experience favor Macs).  As such I’m testing Chrome on an iMac through Parallels Desktop which is running a Win XP Pro Virtual Machine.  Results are indicative of this setup.

Breaking Conventions

Google seem intent on breaking some well established conventions with Chrome.  We’ve seen with the iPhone that breaking established conventions can be a liberating thing, something that frees designers from the shackles of the past and allows them to come up with something truly great.  There is, of course, a downside. Unless your new interface is truly intuitive, which is very difficult to do in an IT system, there’s going to be a steeper learning curve than usual.  There’s also going to be mistakes and failures.  And when you knowingly introduce failures and mistakes, you run the risk of user abandonment.  Sometimes this will be abandonment of a task, but in cases like Chrome, and the iPhone, it will be abandonment of the tool.

Interface Differences between Chrome and FireFox 3

The image to the right highlights some of the differences you will notice between Chrome and a more conventional browser, in this case I’ve used FireFox version 3 on Windows XP in vanilla form.

I’ll be addressing each of these differences in turn.

Standard OS Interface Elements

Something that’s been a pet peeve of mine over the years has been where applications choose to change some interface elements that are intended to be common throughout the Operating System’s interface.

Unfortunately, this is something Google has chosen to do with Chrome.  You’ll notice in the top right hand corner of the Chrome window that it appears to be using Windows Vista interface elements, even though it was running on Windows XP. Is this important? Yes.  The problem here is not that it is using Vista’s icons, but more that it is not obeying any customisations made by the user.  For example, I know users who have poor eyesight, they tend to increase the size of these controls so they can easily minimise windows without accidentally closing them.

Window Controls in Chrome and FireFox

If you enlarge these controls through Windows XP, the controls on Chrome do not change.  It’s also worth noting that the buttons don’t have the characteristic coloration that controls on other windows do, this is also likely to confuse less experienced users.

To some users, the large red button that closes the window has now become the small blue button, but only for Google Chrome.  And that last point really is key.  Google Chrome performs differently to the rest of the OS.  It’s the one car in the showroom with the steering wheel on the roof.

State-Sensitive Objects

You’ll see on the screenshot earlier in this post that I’ve highlighted the status bar and the tab bar in Chrome.  The reason I’ve singled these two elements out is that they behave inconsistently.  The status bar only becomes visible when there’s something to display, and it works fairly well.  Essentially, it only shows up when you mouse over a link (to display the destination URL) or when the page is still loading.  It’s working on the principal that at all other times, there really is nothing interesting that needs to be fed back to the user, so there’s no need to eat up valuable screen space and display extra interface elements that may confuse users.

What’s more interesting is the approach to tabs.  Unlike FireFox, Google Chrome always displays the tab bar, regardless of how many tabs you have open.  FireFox hides the tab bar if only one tab is open.  In Chrome, the result is that you have a state-sensitive status bar (i.e. the status bar only displays when the browser is in a certain state) and a tab bar that is not state-sensitive.  This is likely down to the push by Google to emphasise the tabbed aspects of Chrome.  It’s a selling point, something they want to push, so I suspect the decision to keep the tab bar constantly visible was taken with more a marketing hat on, rather than a UI one.

Personally, I’m ambivalent about this.  I feel it warrants being pointed out, but it’s not a huge issue.  Just a difference that people need to be made aware of.

Auto Feed Discovery

As highlighted in the image towards the top of this post, Google Chrome does not feature automatic feed discovery.  This seems like a strange choice given that Google runs one of the most popular Feed Reading services on the planet, Google Reader, as well as the hugely popular FeedBurner.  Whether this is a feature that’s yet to be implemented, or something that’s been intentionally omitted in the name of simplicity remains to be seen.  But it would appear that yet another common interface element is gone, at least for now.

Miscellany

There are a few other things that I just briefly wanted to mention that doesn’t fit in with the “breaking conventions” theme of this post.  So consider this a miscellaneous section.

Task Manager

Google Chrome Task Manager

I have a real issue with my browser requiring its own Task Manager and it seems strange that Google are pushing this as a feature.  Windows Mobile has been mocked repeatedly for it’s use of a Task Manager, in fact Apple referenced it in a keynote about the iPhone, that’s how laughable the feature is.  The reason it doesn’t work is that Windows Mobile runs on mobile devices.  People don’t want to manage their mobile devices, they just want them to work.

I think Web browsers are similar.  My browser is a gateway to services, in the same way a phone is a gateway to a service.  The best browser, much like the best phone, is the one that allows me to most easily access and make use of the service I am trying to connect to and utilise.  Making me consider things like memory and resource usage is not going to achieve that, I just don’t want to think about it.  I want my browser to just handle that back end stuff, and leave me get on with what I want to do.

Options

The Options available in Chrome

Another of my pet peeves is options.  Many applications have many different ways of structuring and organising options.  Currently there are very few options available in Chrome, which isn’t a bad thing.  I’d personally like to see more customisation opportunities, and it is required before it becomes mainstream, but at the moment it’s fine.

What’s not fine is the structure, grouping, wording and logic of the existing options.  I won’t go into any details, as I could spend an entire post on it, but it needs a complete overhaul.

Have you been using Chrome?  If so, what do you think?  If not, why not?

Over the course of a few months I’ve attempted to access 100s of pages using two mobile devices, an Apple iPod Touch and a Nokia N95.  Two vastly different devices, both of which claim to give you the internet in your pocket.  The iPod Touch mostly succeeds, with the obvious limitation that you are tethered to a Wi-Fi hotspot.  The N95, whilst more mobile, is restricted by a smaller screen and an awkward mobile browser.  Using these two devices, I kept on noticing the same problems on many different websites.  Armed with this experience, I’ve come up with the following steps that should be taken when designing a website, with an eye on mobile devices.

Test, and be harsh

If you already have a website, the first place to start is to assess what’s already there.  Use multiple mobile devices and see how the site holds up.  And be harsh.  Always assume that you’re the best user who will ever come across your site, assume that all other users will be less skilled and less capable than you.  If you can *just* complete a task, assume that it’s too difficult for the majority of users.  And remember, every action becomes more difficult when using a mobile device.  Pointing and selecting is less accurate, typing takes longer, and the reduced screen size means that reading is more difficult.  Use the guidelines below to assess your site.

Focus on Data

Your efforts, with regards to mobile users, should be on reducing the number of page views.  The best way to achieve this is to identify the data held on your site a user is most likely to be seeking, and put it at their fingertips.

For example, last week I was visiting a theme park, Alton Towers, and forgot to note the address.  So whilst on the road, en route as it were, I had to use my N95 to find the address.  This proved to be incredibly difficult.  Not only is the site media heavy, and therefore slow to load, but the address is hidden behind a number of links.  To compound the situation, the links aren’t clearly worded, so it may take a number of attempts before you follow the correct path.

As if to confuse you that little bit more, instead of just giving you the address they give you a “Sat Nav Reference”.  To the rest of us, this is a post code.

The Alton Towers site is a clear example of a site that has not been optimised to help a user achieve a goal.  As this is a site for a theme park, it’s fairly easy to determine the questions people will ask of it.  Firstly, when is it open.  Secondly, how much will it cost.  And thirdly, how do I get there.  If I wanted to visit the theme park, these are the questions I would want answered, and I’d want them answered quickly.  If it’s a spur of the moment visit, it’s likely that I’ll be seeking this information on a mobile device.  The bad site design, complexity of the link structure and media heavy pages make this very difficult to do.

The three questions identified above are actually fairly obvious.  This holds true for a number of other sites.  For example, if I’m visiting a Hotel’s website, I want to know room availability, price and location.  If it’s a cinema, I want to know what films are playing and at what time.  Performing this simple exercise, identifying the “in demand” data on your site, is the basis of a good design that will work well both on desktop and mobile devices.

Accessible Navigation

Obviously, it’s not possible to fit all the information onto one page, and even if you focus your efforts on the most required information, it’s inevitable that at some point navigation is required.  To that end, navigation should be as clear, consistent and accessible as possible.  For mobile users this means keeping it as simple as possible.  Collapsing, hierarchical menus are fine in full browsers, but they don’t work well on mobile devices.

One of the examples I’ve come across recently is that of my local cinema.  A cinema website is one that can never work on a single page, you have to at least select the location you wish to visit.  So it is essential that such sites have excellent navigation.  The image to the right is a screenshot from the website belonging to my local cinema.  As you can see, navigation is down the left hand side of the screen.  What you can’t see is that this navigation tracks your position on the page and follows your position (i.e. when you scroll up and down the page, the menu remains in the same position relative to your browser, as opposed to relative to the page).  I can’t tell you how bad this is.

On a mobile device, one of two things happen.  Either the javascript isn’t executed properly, resulting in a completely non-functional, sometimes un-displayed, menu.  Or, the Javascript does work, hiding the bottom few links from view because the mobile screen isn’t as big as a regular screen, it can’t display the full menu.  If this was a normal list of links you could just scroll down to see the bottom of the menu, but seeing as the menu moves when you scroll the options are always hidden.

As if to compound matters, Vue have decided to hide the information you really want behind one of these, potentially invisible, menu options.  Take a look at the screen flow below.

Upon first entering the site you have to select a cinema.  Then you get a list of films currently playing at the cinema.  To see the show times you have to select one of the films.  Alternatively, you can use the “all films/times” link, which gives you a list of films currently playing, along with the times they are showing and whether they are sold out or not.  This is an incredibly useful page if you want to go and see a film at a particular time, it also mirrors the sort of information you would get from a leaflet or display inside the cinema.  The utterly baffling thing is that Vue have decided to hide this page behind a link that some users may not be able to see.  Considering that this is a cinema, i.e. somewhere people may want to visit on the spur of the moment, you would expect more attention would have been paid to these factors.  In defence of Vue, they do offer a “Text Only” version of their site, but it is not automatically chosen for mobile devices (or at least not the three I tried) and the link to it is hidden at the bottom of the page.  While having a plain version of a site is a good thing, there’s little point if you hide the link to it at the end of a page that may or may not correctly load for users who would want to use it.

The other side of navigation on mobile devices is whether that actually work.  Examples of navigation menus and systems that may not work are those than use Flash, Javascript, Applets, Stateful CSS and AJAX.  If you use anything other than simple HTML, you run the risk of locking mobile users out of your site.

Requiring Information

There’s been a trend over the past few years for site requiring information before letting you access information.  Fortunately, the rise in usability-aware designers has stalled this in its tracks, but it still happens.  When making the decision as to whether users should provide information before being allowed access to the site, you should be aware that this will effectively turn away mobile users.  And if your site acts as a web presence for a bricks and mortar operation, you are turning away customers.  Providing personal information is always a value proposition.  Users weigh up the effort and risk against the potential benefits.  On a mobile device, very few sites will win.

The Solutions

So far, it’s been all about the problems.  So let’s lay down some basic rules for designing a mobile-friendly site.

1. Identify the information users are most likely to be looking for. You can do this through common sense, your visitor logs and search engine queries that lead users to your site.
2. Design your site around this information. Make it as easy as possible to access this information and consider the needs of users who are trying to access it.  For example, is showing performance times enough, or can you also show ticket availability.  If you are showing an address, is that enough or should directions be included.
3. Keep navigation to a minimum. The perfect mobile site is one that consists of one page that contains the information that the user requires, and nothing more.  Remember that many mobile users are billed based on the amount of data they use, so every unnecessary page load is costing your visitors money, leaving them with less to spend with you.
4. Simplify necessary navigation. As we’ve seen in the cinema example above, sometimes some navigation is necessary.  If this is true, simplify it as much as possible.  Make sure the navigation is usable, and functions correctly on as many devices as you can test with.  The wording of the navigation must be chosen carefully, being sure to be as descriptive as possible.  The only thing worse than requiring a user to navigate through several pages is leading them to the incorrect page because of badly worded navigation.
5. Focus on information. While there will inevitably be exceptions (banking websites for example), at the moment most mobile users will be seeking information.  They use their phone to find out something, not to complete a task.  So when designing navigation, make it data orientated, not task orientated.  For example, the theme park website used above would better serve its mobile users if a link was called “Directions and Opening Hours” as opposed to “Plan Your Trip”.  Planning a trip is not something I, or anyone else, would want to do using a mobile device.
6. Strive for “Extreme Usability“. The extreme usability post by Jakob Nielsen covers something we should all be doing.  After focusing on areas of sites that fail, we should be looking at areas of sites that almost fail, or only just pass.  The aspects of sites that are borderline on desktops, are the ones that will no doubt fail on mobile devices.
7. Test early, test often, test on multiple devices.  When designing for the mobile web, a significant amount of resource must go into testing.  Part of this is down to the huge amount of devices that can be used to access sites and the variance between them.  It’s also important to note that whilst many devices may use the same browser, there are differences in screen sizes and resolutions, button layouts, operating systems and functionality.  Additionally many mobile network operators and handset manufacturers “tweak” browsers to their own end.  Mobile testing is far more taxing, complex, time consuming and specialised than normal web site testing.  You can help catch problems early by storyboarding and involving potential users, asking the question “If you were to access our site from your mobile device, what would you be looking for?”.

I think that’s a reasonable start.  Have you worked on mobile sites before?  Or have you had a negative experience using a mobile device?  Let us know in the comments.

Take, for example, the image to the right (click to enlarge).  There are three methods of controlling something with hugely cryptic labels, a wheel and two buttons.  Can anyone tell me what these actually do?  The wheel controller looks like it moves something, in an arc, from left to right.  The top button looks like it makes some sort of box explode while the bottom box looks as if it causes another box to grow wheels.

I’m all for using metaphors to improve usability, but in this case they just haven’t been thought through.  We’re used to arrows indicating that radio stations will be cycled through, and triangles indicating that volume will be adjusted, but these buttons don’t exhibit the same level of logic (or historic use).

I’ve driven a number of Vauxhalls as hire cars over the past few years and have found the usability of the controls to be universally awful.  In addition to the controls on the steering wheel, you’ll also notice some oddities when using the radio, particularly when trying to manually tune a radio station.  It seems to switch, for no apparent reason, between scanning for stations and manually incrementing the frequency.  The indicators also behave in a strange way.  Pushing them up switches them on, pushing them down just changes direction.  You have to rely on the car knowing when to turn them off, which it isn’t very good at.

It’s been suggested by someone else who drives a Zafira occasionally that these buttons have something to do with the optional phone integration.  If this is the case, and I honestly don’t know, then I cannot understand why they avoided the normal phone metaphors, such as an icon that actually resembles a phone.  And for what it’s worth, out of the numerous people I know who have driven new Vauxhalls, every single one of them have looked down at the buttons and wondered what they do.  Surely if Vauxhall had bothered to test the interior controls for usability, they would have picked up on this.  And while this may not be a big issue when deciding whether or not to buy a Vauxhall, it does leave a bad impression.  The general consensus is, if they can’t get this right, what else are the going to fail at…

I heard a radio advert for a new service called webuyanycar.com.  The theory is that they will buy your car from you direct, to save you going through the hassle of advertising and sorting out a private sale.  So, being curious as to how a service like this would actually work, I checked them out.  Now I wished I hadn’t.  Quite simply, it’s one of the least usable sites I’ve ever come across.  Poor layout, badly worded copy, buggy forms, unclear graphics, this site has it all!

So taking it step by step, let’s see where they go wrong.  Firstly, you have to enter the registration number of your car.  Once you’ve done this you get presented with a drop-down box where you select the year.  The button next to this field is labelled “VALUE MY CAR”.  This is misleading as there are a number of steps required before you actually get the value of your car (which, by the way, was at least 30% lower than current realistic market value).  When creating a multi-page or multi-step process, it’s key to keep users informed as to how far they are through the process.  Suggesting it’s near to the end, and then not fulfilling that expectation results is a high number of abortions mid-process.

The next step in the process is identifying any damage on the car.  This is done through a flash object (as pointed out in the comments, this isn’t a Flash object, it’s actually Javascript mixed with image maps).  I defy anyone to look at the Damage Assessment Tool’s interface they have chosen and tell me which end is the front of the car.  In fact, I believed that the right hand side was the front because of the shape of the headlights.  This isn’t the case.  There are tool tips when you hover over the section but these are badly formatted and buggy.  All in all, if you have to record any damage, it’s an absolute chore and very hit and miss.

Once you’ve added any damage, you then get to the screen which requires your personal details.  I’ve added a screenshot of this screen to the right, just so you can see what it looks like in FireFox 3.  Note that FireFox 3 is currently in the “Release Candidate” stage, meaning that it’s not entirely ready for mass consumption (although once a software project reaches release candidate stage, typically only defect fixes are included and features are not changed).  FireFox is the world’s second most popular browser, used by about 25% of Brits.  As you can see, it’s horribly broken.  To make matter worse, even if you can figure out what fields require what information, you get random validation failure messages (for no apparent reason) that don’t seem to be attributed to a specific field (because the layout is too broken to figure out where they are supposed to be positioned).  And as the icing on top of the cake, the submit button doesn’t appear to work in FireFox.  So even after battling through badly designed and horrendously implemented forms, you can’t get a valuation in the end anyway.

One other oddity you’ll find regards the privacy policy.  As with most websites that require personal information, they will try and sell it unless you tell them not to.  Yet look at the wording for the option.  This was obviously written by someone who either doesn’t understand the fundamentals of web form design, and what the different input types do, or doesn’t understand basic English.  But most likely both.  The first thing you’ll notice is that it says “Click Here”.  “Click Here” is appalling when used as the text for a link, it’s an abomination when used as part of a form.  You’ll also notice the ambiguity is introduces.  If I click there, I’ll deselect the check box.  Usually these are opt-meaning I would want the check box checked.  And what if I click there, forget, and then click there again?  No doubt my details would be winging their way to all and sundry before I know it.  Quite why they can’t just clearly state whether that element of the form needs to be selected or unselected in order to achieve the desired result is beyond me.

This truly is one of the trend bucking sites I touched on in the introduction.  Considering this is primarily a web based business, launching with such a clearly under-designed, incompetent, not-fit-for-purpose website could be a huge mistake.  if they can’t handle something as simple as a web form, how on earth am I supposed to trust them to buy a car off me?  Not a chance.  One of the worst user experiences I’ve had in a long time.