Monday, 28 May 2012

I18N - Internationalisation Woes

Living in the UK gives you a fraction more exposure to the problems of internationalisation than living in the US does. This is probably because a UK centric company has fewer than 100 million potential customers, where as a US centric company has more than 300 million and on average these customers are richer, and the proximity of other countries with significantly different languages and cultures.

One of my big frustrations has always been the US date format. All other common date formats can easily be programmically manipulated without determining their local origin, but the US date throws a spanner in the works. It also sneaks its way into programming languages, such as the mktime function in PHP, tripping me up every so often.

The countries that use MM/DD/YYYY are Belize, Canada, Federated States of Micronesia, Palau, Philippines, and the USA.
Their populations add up to 435,582,899 people. [Belize (307,899), Canada (34,073,000), Federated States of Micronesia (111,000), Palau (20,000), Philippines (91,983,000), and USA (309,088,000)]
The population of Earth is 6,815,472,221 people.
Therefore, only 6.4% of the population of Earth use MM/DD/YYYY
The other 93.6% don't use MM/DD/YYYY

I wish the US would just concede that they were wrong and use DDMMYYYY or YYYYMMDD, unfortunately that doesn't seem plausible so we all get stuck with an annoying format to deal with.

Today I was looking at the HTML5 input type number and wondering why it did not work in Firefox. The issue is primarily an I18N problem. While I have long been aware that some countries use 1,000,000.00 and others use 1.000.000,00 I did not realise the extent of the other versions such as

1 000 000,00
1 000 000.00

What a hideous mess... Now you might expect people to be able "work out" what those numbers mean, however, having observed people who have never seen the notation $1000.00 assuming the price is $100000 or even $1000000 when they are scanning through reading, clearly demonstrates an important usability issue.

Google Chrome seem to have gone ahead with a reasonable solution, the UI string is localised, but the submitted string is standard floating point (in most languages) i.e. 1000000.00

Of course with no standardisation and agreement we have what could be a useful field unavailable for use :(

I18N is a pain, but when you realise the costs of a single system e.g. Driving on the left/right, metric/imperial, comma/fullstop numbers they are always high. Perhaps the World Bank should introduce a huge fund, we all agree on these factors and the costs of changing signs etc is drawn from this World Bank fund? OK probably not a great solution, but I am happy to look at anything that gets rid of this fiddly problems.

Tuesday, 8 May 2012

Heathrow Terminal 4 Usability Failure

Airports and Underground systems are often used in usability case studies. The clear and simple iconography an well thought out signs help countless people no matter their language. They help clarify how best to sign post and navigate large areas and can provide great material to study.

However, Heathrow Terminal 4 does have quite a usability failure on its hands in terms of the toilets. Above every single tap is a yellow warning exclamation mark with the text, caution extremely hot!

The message is correct the water is nearly too hot to use, and certainly too hot to use for much longer than a very short period of time without burning yourself.

This is a failure on so many levels, but I feel it is an illustration in how a simple related solution removes obstacles in usability.

If the water temperature was reduced a few degrees then there would be no issue with using the water and there would be no need for the signs. In addition there is likely to be a reduction in cost as heating the water to that temperature is likely to be much more costly than a lower temperature. There are many other bonuses such as a more pleasant experience, a cleaner visual aesthetic without the warning signs.

Essentially by identifying the root of the problem then a better solution can be achieved.

Now there are many possible explanations for the choice of adding the signs instead of fixing the water system.

1 .The temperature cannot be controlled or is too expensive to adjust. This seems an unlikely issue.
2. They need to significantly reduce water use and so making the water too hot stops people from using the water. This is possible, but given the automatic taps and reasonably slow flow of water it appears less likely that this is the cause.
3. It may be a temporary solution to a problem which requires extensive work. Again it does seem unlikely that there is much more required than a thermostat setting.

It appears most likely that there is an interdepartmental communication problem and as a department was able to "solve" a problem they took it upon themselves to create their shoddy option rather than the real solution.

This situation can be witnessed in software development very frequently, where one suboptimal choice leads to a second suboptimal choice and then the UI ends up being a horrible mess. It is very common that a feature can be removed/replaced to dramatically reduce the complexity of an interface. The trick is to find these messy points and question the features that have been implemented to see if there is a better way.