On a daily basis, the electronic devices I interact with to access data on the Web are of two kinds: computers, along with keyboard, mouse and with screens usually around 15-25 inches in diagonal and with a resolution hovering around 1280-pixel-wide, and mobile devices with tiny keyboards and/or small tactile screens with resolutions around 320×480 pixels.
The user experience on these two kinds of devices are entirely different in their focus, spacial context or time context.
NY Times mobile app, similar on iPhone and Android
Data, however, has been steadily converging in the past few years, and the promise of One Web has become a reality. Most major (text-based, at least) content providers generally have an offering un traditional media, on “desktop” web clients as well as mobile. The latter two can be part of the same web space, with minor content adaptation and separate presentation. Also interesting are all the recent “mobile applications” and “mobile widgets” that use the Web as a source of linked data, and dress that data accordingly.
Recent diving into the logs for a number of websites I take care of showed some overwhelming trends in sites mainly aimed at the urban creative class: on the mobile version of the sites, up to 98% of the traffic was caused by either indexing robots or browsing devices such as the iPhone. Practically none of the visitors were browsing the site with devices sporting pre-CSS browsers and monochrome screens…
in Japan, a country with a rich history of mobile browsing (notably with i-Mode), and a stronger legacy of low-tech mobile browsers in almost every handset, I have observed that close to 70% of the traffic for mobile sites are bots, with googlebot nearing 55%. The rest is almost exclusively from KDDI headsets – KDDI being the only carrier offering a mobile browser for free.
This seems to suggest that most of the rest of the customer base has now switch to what Japan calls “PC browser”, aka full-featured, CSS-enabled browsers for mobile platforms, and that these browsers directly access the “full-featured” version of the sites. Add to this the fact that most “mobile websites” make the mistake of miniaturizing rather than mobilizing and it indeed makes little sense to go for the poorer experience.
NY Times mobile website
as experienced on iPhone
Not all phones on the market feature one of those CSS-enabled browsers with zooming capabilities, but a couple of players (opera mini and webkit) have been invading the landscape at a very fast pace. It actually looks like webkit is soon to be crowned king of the mobile device market: after being used in both the iPhone and the Android browser, it looks like it will also come soon on Blackberry, too.
Truth be told, the sites which I used as research subjects are aiming at a fairly wealthy, well-connected, urban audience. While my numbers are obviously not relevant for populations on the other side of the digital/mobile divide, they are certainly the tip of trends to come for the first world. And the trend says: do we still need mobile web sites?
We are still overwhelmingly designing Web sites for whatever computer screen width is the norm, or at least the least common denominator. How many times in the past few years have we seen sites re-designing with a fixed width around 970 pixels because “no-one uses 800×600 screens any more”? Fixed width designs are undoubtedly convenient, and do make sense if all devices used to access the site are consistent in their size and interface.
NYTimes.com: fixed width design at 972 pixels
This, however, may be changing soon. Recent rumours are spreading about Apple preparing the launch of a mobile tablet, which mode of interface would be very much like the iPhone, but with a 8 to 10 inch screen. Beyond gadget envy, what is exciting about such a tablet (and the increasing sales of other netbooks) is that we are finally bridging the gap between tiny mobile devices and big computer screens.
When the range of web-enabled devices becomes entirely continuous between the small and the very large, between the ultra-portable and the very static, will it still make sense to build specific “mobile” (read: miniaturized) websites?
I believe that there are two ways forward:
- Hyperspecialized “applications” using Web-based linked data as a backend. This is definitely an ongoing trend, with Android, Apple, Palm etc. all building a lucrative application marketplace. These applications are costly to build, however, and incompatible between one another. So long as one player (the iPhone for now) reigns almost supreme, it makes sense to build an app for it, but if competition leads to a true balkanization of platforms, it will no longer be cost-effective to build similar apps for a dozen platforms when a single platform could do the job: HTTP+HTML+CSS+Scripting…
- A maturing of web-based designing with fluidity in mind. Can we create designs that scale regardless of screen size or context? Can mobile stylesheets, media queries, content adaptation, and APIs for contextual enhanced features such as geolocation help us build single interfaces that scale? And what are the future challenges for User Interfaces in such a converged market?
8 opinions
[...] Freshly posted: "The Death of the Mobile Website?" http://lab.pheromone.ca/2009/08/26/the-death-of-the-mobile-website/ [...]
Intéressant. Il y a risque de balkanisation, mais en même temps, le développement en mobile iphone vs blackberry exige des expertises en UX similaires et les contraintes Apple et BB sont très grandes. C’est donc plutôt un coût en UX qu’en développement.
Question: au Japon, les WAP et autres adaptations mobiles, c’est terminé?
Coût en UX et en développement. Les librairies (et langages) de développement sont complètement différents d’une plate-forme à une autre: le NY Times, par exemple, a dû doubler le temps de développement pour donner exactement la même expérience pour leur app sur Android et iPhone.
Quant aux services iMode et assimilés au Japon, il semble qu’ils survivent bien pour certains services (musique, ringtones etc) mais la tendance dans l’utilisation des navigateurs et la vente énorme de terminaux puissants devrait en sonner le glas dans les 2-3 années à venir.
Il y a une troisième voie, à base de versions mobiles des mêmes sites : là c’est moins cher en RD et tout à fait dans la philosophie de la “mobilization”. Voir ce que font plein de sites avec leurs sous-domaines
m.*; voir aussi l’idée de fixer un cookie sur la base de la demande expresse du client et de là, faire de la micro-adaptation (j’aime bien cette option-là), par exemple chez Mezzoblue.En tout cas merci pour cet article. Food for thought (tiens pas de
span langdans le XHTML autorisé, dommage).[...] vachement bien le dernier article de @olivierthereaux http://lab.pheromone.ca/2009/08/26/the-death-of-the-mobile-website/ [...]
[...] revolutionary yet, but I have started with an article over at the Pheromone lab (my employer) on “The Death of the Mobile Website?” and interface/device [...]
Hi all,
Pardon, mais je ne suis pas courant en Francais…
I have been working on mobile website software for multilple screen display sizing for some time. I have a project on Google Code, if anyone is interested:
http://code.google.com/p/mobilesiteos/
It works well enough, but does require server scripting (I program in Perl). Anyone knowing of similar projects, please feel free to let me know (dwight_vietzke@yahoo.com).
Great article. I of coarse couldn’t agree with you more about the movement of websites towards ‘same content for all’ as a worthwhile trend. It does however make it difficult to create ‘exciting’ content, when you are concerned about reaching all device types. Pages tend to be simple (not always a bad thing) and you always have the problem of know what capabilities the user’s device can handle, ie: javascript, flash, xHTML as XML, etc.
Standards too are a problem, since it seems like there are almost none at all at times. The newer mobile devices (with near full-featured browsers) are making it easier to present pages across many devices, so it would seem there is hope.
Oddly enough, integrating things like Google Checkout and Adsense code into my software was a challenge as they are both not very ‘mobile friendly’. That is, you have either code that works for desktops, or code that works in mobile devices but not single source code that works in both. For example, I try to write all pages as xhtml Mobile Profile complaint. But Google code uses attributes and techniques which aren’t MP compliant. Usually for no good reason other than they haven’t bothered to change yet. So it causes you to filter and negotiate around these obstacles.
So for the web developer, making simple pages work for different size devices isn’t the problem as much as it is integrating all the ‘normal’ features code supplied by others that we consider standard for website function.
[...] a comment » A few months ago I was writing a post on the Pheromone Lab entitled “The Death of the Mobile Website”. The basic point of it was, as the landscape of web-ready devices become less segregated between [...]