The travellers' internet: Designing applications for those on the move
Over recent months I have been travelling through Europe and the Middle East. This has meant me accessing my email, uploading photos, writing my blog, and making all kinds of forwarding travel arrangements over the internet at internet cafes, hotels and other access points that were not my usual domestic internet connection.
Over the course of my travels I have made some observations about which types of web application are particularly suited to being used by travellers, and the kind of issues that crop up. In this series of three posts I hope to outline some of these issues, and illustrate where I believe that products specifically of use to people travelling need to concentrate their design and usability effort in order to maximise their usefulness to the market.
Browser compatibility issues
Still one of the most prominent issues I came across was sites that do not use standards complaint code. Different browsers render web pages in different ways, but a well coded web application should function correctly on all browsers, even if the visual display is not entirely pixel perfect.
However many businesses build sites that require the use of proprietary technology from one of the market's leading browsers, usually Microsoft's Internet Explorer, and other businesses choose to 'lock-out' users of browsers that are not the versions they have specifically coded for. This can have extreme consequences when travelling, as often you have no control over the choice of browser, how up-to-date the version is, or how the settings can be adjusted.
For example, one hotel I stayed in had internet cafe management software installed that used a customised and option-limited version of Opera. This of course meant that any site "optimised" to work in Internet Explorer only was inaccessible to me from that internet access point.
Core functionality that relies on JavaScript
I used several internet access points where the use of JavaScript and other scripting languages on web pages was disabled. This again meant that applications that relied on these techniques failed to work for me in these situations.
Most notable in this regard was HostelWorld.com. I used this site to book accommodation in advance in several countries during my travel. On this site in order to search through available hotels and hostels in a given location, the user has to first select a destination country, and then a city within that destination country from drop-down menus on the homepage.
However the menus are built dynamically within the page, which relies on JavaScript to populate them. There were a couple of occasions when I couldn't use it, and we ended up going to other websites in order to book our accommodation. Without JavaScript the menus were not populated. In the time-pressured environment of an internet cafe, the substitute browse mechanism was too long-winded to explore, and there was no <noscript> code in the pages to provide us with alternative access to the information on the site via the search facility.
In this scenario, the failure to invest in alternative mechanisms to make the site searchable without JavaScript enabled is literally costing HostelWorld.com business.
Core functionality that relies on setting cookies
One particular application that I wanted to use frequently, the control panel access to my currybet.net domain, tests whether cookies are enabled before it will allow a successful login. This was incredibly frustrating, as often I would be locked out of my mail because I was unable to change the cookie status of the machine I was working on. None of the intrinsic functionality of the webmail access required cookies, but because access to webmail was behind this control panel login, I couldn't get to it.
The wider implications of this are that cookies may make some operations easier, but whilst travelling I would rather have access to services with some preferences incorrectly remembered, than no access to the service at all.
It was something that we put considerable effort into when I was working at the BBC on the International Facing Homepage project. One of the use cases we needed to solve was the issue of how someone using a machine that neither accepted cookies or executed JavaScript could change their edition and have a persistent experience.
In general (well, perhaps it was only me) it is also important to consider that travellers are likely to be less forgiving of applications that fail with errors or don't work, given that usually they will be using the internet in situations where they are paying for access on an elapsed time basis.