Andrew Harris, User Interface Designer, University of Melbourne [HREF1] Enterprise Applications. aharris@unimelb.edu.au
The demand for mobile access to web based services is set to increase dramatically in the near future. Like most universities, our web development teams are struggling to keep up with the demands and changes on standard browsers, let alone developing for the mobile web.
Our approach was to develop a framework that gives maximum accessibility to mobile devices with minimum initial development effort, allowing for expansion as demand and resources allow.
Most University web teams are aware that they need to start offering mobile-oriented web services. Mobile users have different needs and expectations and require a different approach to the provision of these services. On the other hand, until there is significant demand, it's hard to justify a large investment in time and effort creating a mobile web.
What we were looking for was a way of providing meaningful mobile services on a tight budget, but with room for expansion in the future.
If you go looking around in your server logs for evidence of mobile browsers, you're likely to be disappointed. On the University of Melbourne home page in the last month (Feb 2008), devices with screens smaller than 500 pixels wide accounted for 650 visits. Not very exciting statistics, but it's an indication that people are willing to try using these small devices. The reason for the low numbers may not be about demand as much as supply.
In broad brush figures, there are more than 3 billion mobile subscribers worldwide [HREF2], but only about 600 million personal computers [HREF3]. It isn't too great a leap to say that for every visitor to your website with a computer, there are at least five potential visitors with mobile devices.
Three factors are driving a dramatic increase in mobile data usage.
The level of change and hype is set to accelerate dramatically later this year with the introduction of mobile devices running the Google sponsored Android [HREF4] mobile phone operating system.
The vast majority of students and staff on campus already carry an internet capable mobile phone and most would use a mobile service if it was quick, cheap and convenient. At busy times, there are often substantial queues of students waiting for access to computers in the library and student labs.
Many internet transactions conducted on campus such as checking email, conducting library searches, checking timetables and room locations, do not require the processing power of a laptop or desktop computer and need not involve the transfer of large amounts of data. These are services that are quite suitable for mobile use.
The conclusion has to be that the lack of visitors to our websites from mobile devices is probably more about our poor offering of suitable mobile services than it is about demand. We're just making it too hard and too expensive for users to be bothered.
Try using a mobile phone to access the internet and you immediately notice a number of limitations that greatly affect the user experience and which need to be taken into consideration when designing services for delivery to mobile devices.
With problems like these to overcome, it's tempting to question why anyone would ever want to use a mobile phone to access the internet, however there are also a number of intrinsic advantages.
Mobile devices are:
Despite these advantages, most users will never have considered using a mobile phone to access university web services, because existing services typically:
For years, most people have had a perception that the Accessibility guidelines published by the W3 were designed for people with disabilities. In fact, the message of 'One Web' espoused by Tim Berners Lee is about device independence. It's just that until recently the only 'other devices' we have had exposure to were those used by people with disabilities.
Now, we are finding that sites that have been built to be Accessible perform better on mobile devices, while anecdotally we are hearing that users with disabilities prefer to use sites that have been designed specifically for mobiles.
The bottom line has always been that Accessibility is good for everybody. Now, we are starting to see the user behaviour to back this up.
To understand what needs to be done to make the university web a friendlier place for mobile internet users, we need to put ourselves in the shoes of the typical person on campus, think about the tasks we need to accomplish on a daily basis, and imagine where the mobile web might be of help in that.In general, mobile web users:
Based on these parameters, we short-listed a number of services that we thought might be useful to focus on for delivery to the mobile platform. The sort of services that someone might conceivably need to access as they walked across the campus.
A well designed standard web page can be optimised for viewing on a small screen device by using a special style sheet. The web designer builds using accessible, standards-based HTML and uses an alternate 'handheld' style sheet to provide an enhanced experience to the mobile user.
The advantage of this approach is that exactly the same content is delivered to both mobile and desktop. Mobile devices simply detect and use the appropriate style sheet and development costs are kept to a minimum. It can be ready as soon as an appropriate template is deployed.
The disadvantage of this approach is that the content itself may be too verbose and difficult to comprehend on a small screen. The navigation, designed for desktops, might be too complicated to easily traverse, and there may be embedded images, scripts and content that are costly to download and irrelevant or unusable on mobile devices. Even if the users don't see it, they have to download it.
Even if the web pages currently presented by the website are unsuitable for mobile delivery, some of the content within them might be suitable.
Dynamic publishing systems such as Content Management Systems (CMS) can reuse components of a site or page in a more mobile friendly template. Some systems have the ability to 'scrape' content from external web pages and RSS feeds, so that content not stored in the CMS can be imported and represented within it.
The advantage of this approach is that there is still only one source of content, simplifying maintenance and management of information.
Transcoding or parsing web pages is similar to the reuse described previously, but is not targeted. The process involves viewing a website using some sort of proxy that filters out pictures and optimises content to a lowest common denominator target device.
The best known example of this type of tool is the Google Web Transcoder (GWT) [HREF6], though on many pages, Mowser [HREF7] produces a cleaner result.
The GWT allows a user to view and 'tunnel' through pages and sites that have been stripped of images and styles, linearised (tables removed) and in some ways reorganised. GWT will create a table of contents of a page based on the headings present and will attempt to hide what it considers irrelevant navigation. Longer pages are split up over several screens.
The advantage of this tool is that it can render any site in a way that is as easy as possible for a mobile phone to read. The owner of the site doesn't need to do anything. Of course, accessible, standards-based website perform better, but they probably don't need the help of a transcoder anyway.
The disadvantage is that it is indiscriminate. Once you send a user into the transcoder, they stay in there - all URLs are tunneled, so if you offer a link to a GWT page, you need to make it clear that the user will need to back track or start again if they want to return to your site.
Finally, you can build a customised mobile optimised website.
There is no doubt that the best experience will be created if you carefully craft a website specifically for mobile devices. This is the most reliable way to create the fast, lightweight, consistent, simplified experience that mobile users need.
Of course, the disadvantage is that it takes substantial time and effort.
Having gathered enough information about the needs and problems, we then matched the services we wanted to offer with the resources we had available for delivery. Essentially, deciding which pages we would build as fully customised mobile pages, which ones we would 'scrape', which we would leave to the google transcoder and which we would (for now) ignore.
We decided on a layered model with a few frequently used pages being at the top and each layer representing a step down in expected traffic, and the effort involved in optimising for mobile.
From a simple 'return on investment' point of view, we decided to create only a few central pages from scratch - setting up a consistent navigation that would be used as much as possible throughout the site.
The next 'layer' of pages were those we decided to 'scrape'. As the central pages were created in the CMS maintaining a consistent navigation was simple. Scraped content is simply wrapped in the same template and links are 'tunneled' to maintain a consistent navigation. Some of the scraped content comes from customised versions of existing services such as the Telephone and Email Directory Search. Development of this layer is continuing.
At the moment, our next layer down is standard pages using the university's html template and alternate style sheets. The current university template is built on accessible, standards-based code with a handheld style sheet that transforms reasonably well to mobile devices. Navigation is not great, but the experience of using a page is acceptable.
At the outer level, we will be offering alternative access to more 'difficult' pages via google's transcoder.
Our plan is eventually to develop our own transcoder which will treat our own optimised and templated web pages in a smarter way, allowing users access back to the core pages and at least some consistent navigation.
Working closely with our Application Development team we hope to influence future development to make interfaces more Accessible, standards-compliant and therefore more compatible with the needs of mobile users.
A final, important factor is awareness. While we don't want to encourage users to visit our mobile site until there is a viable service being offered, the only way that traffic (and meaningful feedback) will be generated is by appropriate publicity.
The equation is fairly simple. There are a lot of capable web browsers traveling around campus in people's pockets and handbags. The main reason for their under-utilisation is a lack of viable services. By taking an approach that converts our existing services to mobile usable formats we hope to bring users a new level of convenience and usability without a major investment in personnel and infrastructure.