Sunday, 25 May 2014

Usablenet by name, unusable on Windows Phone

E-commerce usability has been written about for ages, so it might come as a surprise to some that Usablenet who claim to have the "best in class" mobile websites have numerous basic user experience failures.

I visited Sports Direct's website today with a simple goal of looking for a sports drink bottle. This should not be a complex task. On opening I was redirected to the mobile version, it had ignored my browsers desktop website preference and redirected the domain. Redirected domains are commonly the worst start in terms of user experience. Here are just a few of the common issues a mobile user will experience when they are redirected to the "m." domain:

  • Failure to take into account the exact entry link. e.g. A directly link to a specific article is selected form a Google search and instead of reaching the mobile version of the article the domain redirect goes straight to the home page.
  • The redirect creates a new set of http request slowing down the experience.
  • The content on the mobile and desktop sites are different, most commonly some "pages" do not have mobile versions available.
I was greeted with a classically bad carousel banner on the page, as I attempted to scroll down the page when the carousel timer kicked in the page was forced to scroll back to the top. This is hideous in terms of usability, I literally can only see the 3 carousel items everything else becomes inaccessible.

I looked at the side menu and none of the categories struck me as likely to contain a sports drink bottle. So I thought lets use that search magnifying glass. I clicked on it and it opened up a screen with nothing but a text box. I selected the text box to gain focus and in doing so was forced back to the main screen. Yes that is right the most useful feature on the website was broken.

I scrolled to the bottom of the page to see that it was made by Usablenet and I could supply feedback. As the carousel was forcing the page to scroll back to the top it took several attempts to actually manage a successful click on feedback.

On entering the Feedback page I reached a generic form which had the first field already filled out. This field was labelled "domain" and the value "" was in the text box. I filled out the remaining fields with my feedback and then submitted the form.

The form did not submit and the focus of the form was forced back to the first field. There was no error message and no indication that any of the fields were incorrect. I tried to submit again and received the same response of the focus jumping back to the first field. I click out of the first field and the text box outline went red. The label of the box was domain, it had been pre-filled with and there was no help text indicating the format that was required for domain.

After trying sportsdirect and I found out that the form would only submit with an http:// prefix. This is a pretty unforgivable double failure. The pre-population was incorrect and there was no error message assistance to help get round the issue.

I then decided to visit the Usablenet homepage, sadly this is not viewable at all on a Windows Phone, the page will not scroll and all you can really see is a chunk of their hero banner. Visiting the site on a Nexus 7 is not much better. Their site includes what I generally consider one of the worse pieces of code to put in a webpage "user-scalable=no". When looking at this site on my Nexus 7 I found the text a little small. This is normally easily remedied with a quick pinch zoom, but if you include "width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" then this wonderful feature becomes disabled.

An additional unnecessary feature is the scroll back to the top on orientation change. If you were to have scrolled down to a specific section and then accidentally triggered an orientation change, well you have to find that part again. Additionally if you have switch to a different orientation to view a specific piece of content (an image perhaps) you then need to scroll back and find that image.

While I understand that Windows Phone is only 4% of the market, surely this should at least we worth a cursory test to confirm it works, especially for a company that claims to be industry leading. Additionally the sites appear to provide a weak user experience even on the most common mobile platform.

Friday, 16 May 2014

Getting the Windows 8.1 Developer Preview update

If like me you own a Windows Phone you might have already installed the Windows 8.1 Developer preview. Perhaps you also experienced some unpleasant bugs and tried a full reset to fix this. You could then have read that Microsoft released an update on the 15th of May which fixed many bugs... But wait phone up update says you are already on the latest version and yet you only have version 8.10.12359.845 not the all singing all dancing 8.10.12382.878

In order to get the new update you need to have the developer preview app installed, which you inconveniently deleted during your factory reset. Good news is after a quick reinstall you will be able to select update phone and grab the new and improved developer preview.

Hope this helps anyone who is also sitting there scratching their head wondering why they aren't finding the new 8.1 update.

Friday, 9 May 2014

Select element; the good, the bad, the very bad and the down right ugly

Reading Mikkel Bo Schmidt's article reminded me of how important the small details are, but not only that, how difficult it can be to make things better.

Mikkel rather skimped on the details of the select element so I thought I would go further.

The Good

Perhaps the most obvious good part is that everyone recognises the select element, it has been around for so long that any regular computer user will know how to interact with it, and many are even aware of how to use the keyboard to skip alphabetically.

The select element is a very compact way of displaying a range of options, it is just a single line and can even take up less width than the text of the options it contains, although this is not recommended as if you select a long option you will not be able to read it, reducing the usability.

The other important benefit is that it works on every device no matter the spec or OS*. Developing a replacement is not a simple matter, does your solution work on every device? Have you considered all OSs, does it work with a screen reader? How much bandwidth is used? Does it work with a keyboard, does it flow with the context of a form, does it support your current and future libraries, will it look dated and require refreshing the look?

I have seen plenty of "clever" new ideas which work brilliantly on the tested devices and then is completely unusable on others. For example recently the website had an advert which stopped navigation on a nexus 7. There was no way of closing it as the close button was always off screen. What this clever full screen advert did was stop me from using the website. Another control which can cause issues are light boxes. Often they will appear in the middle of the screen, now if this is combined with a minimum width which is larger than the resolution of the screen then you can get impossible to close light box.

So in summary custom controls can easily fail without appropriate testing whereas something as common as a select element will have a far lower chance of irritating your users.

The Bad

Perhaps one of the worst things  about the select element is that you cannot see all of the available options without opening it. Obviously if there is a large range of options then even a custom solution will struggle to display them all at once, but if there are only 3-5 options it would be nice if you did not need to click to read them all.

The Very Bad

As mentioned one of the flaws of a select element is the iOS implementation. While Android and Windows Phone intelligently use the whole screen to present the available options iOS gives you just half the screen to scroll through the options.

Older versions of Internet Explorer have problems too if you specify a fixed width for the select element which is smaller than the width required to display the options text then it will simply be truncated. There are workarounds to this particular issue, but such a common and mature control really work better by now.

The Down Right Ugly

Perhaps the most annoying aspect is that a change to the OS can disrupt your behaviour unexpectedly. iOS 7 altered the behaviour of the select element in respect to wordy options. If your option element contains a long piece of text then it simply gets truncated with an ellipsis, rather than the previous behaviour of flowing the option on to multiple lines. There is a workaround to the issue, but as with all workarounds it can be prone to failure with updates. While I would always recommend seeing if you can keep your select options light on text and really focus on minimising the options length this behaviour is obviously unexpected and shows that relying on standard elements can lead to problems, often it is just small alignment issues, but in this particular instance it can result in the absence of text which prevents task completion.

Don't custom elements have the same problems? Of course they can, but as long as you are not using hacks or undocumented features, and testing has been performed across a wide range of devices, custom elements should be no less reliable than standard elements, but be warned replacing them does require a lot of consideration.

And Never Forget Accessibility

So you thought about adding decent keyboard interactivity into your custom select element, well that is a good start, but how about a screen reader. While iOS may struggle to display a select element well under certain circumstances it does manage to read out the text for anyone using the screen reader functionality. In fact accessibility is a great built in aspect of the select box. If you are creating a non-semantic custom version of a select element remember to use aria role element to help those accessing the element with a screen reader and keyboard.

Friday, 2 May 2014

Microsoft Excel's Unintelligent Defaults (multi-ligual CSV failure)

One of the best thing to do in an application is to work hard on the default behaviour, 95% of users never change their settings so the defaults really are vital to the use of the program.

Excel has wonderful features but its defaults are extremely frustrating. Many of them I simply do not understand, for example if a column has leading zeroes then the user probably wants to keep them! However, I came across one issue which I had not experienced until now.

Anyone who has had to deal with internationalisation will probably be aware of the differences in European decimals for example 1,000.00 in UK & US is written as 1.000,00 in many European countries. Microsoft Windows has region settings which take these into account. Excel uses the region settings as the default method for formatting files. This seems reasonable but it contains a setting called list separator which it uses as the default separator for reading a CSV file. If your region is one where "," is the standard for decimals then this separator will default to ";".

This means that if you double click a CSV file which is comma separated it will open and display in a single column. What is worse is if your data has a ";" in it then this will be used as a separator and the data will be split on this value. So a CSV file which opens with a double click perfectly on a computer in the US will open incorrectly on a computer in Germany. If you were to alter your CSV output to ";" separated then the file would open in Germany fine, but the US client would find the data all in the first column.

You cannot even get the end user to alter their region settings to use "," as the list separator because Excel will ignore this because you have "," as a decimal separator. Microsoft do not appear to have worked very hard at helping the user with the default behaviour.

There is of course a workaround which is to open Excel and use the import option to specify how to handle the file, but this feels like a punch in the face in terms of usability.

So what should use do if you want to allow your web application to output CSV files for end users to multiple regions where you expect many of them will use Excel to consume them?

Option 1: Use the Microsoft proprietary sep=, command

If you put the text "sep=," on the first line of a CSV then Excel will use the separator you have specified in this case "," to open the file. Now all your Excel users are happy no matter what their region settings. However, the down side is that users of any other program, like Open Office Calc for example, have a bit of rubbish on the first line that they need to remove or choose not to import and the end user probably will not understand why.

Option 2: Use the browser location / language settings to determine if you should send "," or ";" separated files

Pretty sophisticated aren't you detecting the region and then forcing the file to save in different formats. However, detection would be an imperfect mechanism and although could be of great benefit in some situations would fail in others.

Option 3: Let the user specify their default

The user is in control and can force the separator to be in the format that they want, everything is now right in the world. Oh except as previously stated 95% of users don't bother setting their preferences.

Option 4: Lobby Microsoft to stop using Unintelligent Defaults

Well I don't see this changing any time soon as a huge chunk of Windows users are effected negatively by this behaviour and Excel has had these massive flaws for many years and many different releases, but we can all dream can't we.