In Paris earlier this year, NTT DoCoMo and licensee Bouygues Telecom advertised the millionth customer of iMode in France, a web-like service available on some mobile phones of the smallest French operator. A few months earlier, mmO2 appeared to have been negotiating with DoCoMo to offer iMode in Britain and Ireland, after it became clear that Three, the first UK licensee, would not roll out the service. There has also been some noise about DoCoMo increasing the number of licensees in Germany, to increase its reach beyond the clients of KPN, license owner for the Benelux and Germany. In general, iMode is starting to generate some buzz in Europe, which might make it matter.
iMode is a set of technologies that was developed by DoCoMo for its home turf, Japan. It's a service that makes use of a telco's existing data transmission services. On the basis of regular HTTP traffic over the internet, and of a specific HTML-like markup language, it allows mobile phone users equipped with special handsets to access textual, visual and interactive content. Functionally, it is very similar to the GSM association's ill-fated WAP, or to the more successful Live! service offered by Vodafone worldwide. It features an efficient micro-payment system, allowing content producers to levy small fees on some sections of their sites.
(Note: beyond iMode, most of the indications given in this article also apply to these other services and the competition, as well as to regular web access using other mobile platforms such as Opera on Symbian as featured on SonyEricsson's P910, or PalmOne's Treo handset and its mobile browser. The issue here is features and strategy, more than technology itself, which does differ.)
At this point, it is not sure at all that iMode will meet the same success in Europe or in the US as it has in Japan, for various reasons, including better billing methods, a much larger and consistent market, a huge offer, and DoCoMo's skill at creating a full ecosystem where many parties stand to benefit from the the service. Japanese consumers seem to be very interested in data services, and content producers there have ensured that much interesting material is available. In Europe, no such takeoff has yet happened.
However, if it is successful, iMode will become another diffusion channel which web site owners will also need to serve. Being present on iMode is much more than just converting your site's technology or graphics. The difference in usage is radical, and the offer will need to adapt accordingly. In order to make the best of what iMode has to offer, web builders must be aware of the opportunities it creates as well as of its peculiarities.
There are two major (and obvious) differences in the usage of iMode (or Voda's Live!), compared to the web as we know it:
These two observations will define much of the web builder's behavior towards iMode, and are more important than the technical details. Indeed, the technical conversion is only a very small part of the trajectory that will take you to iMode presence. Defining what you want on your iMode site, how it must be organized and how to present it are much more interesting and difficult questions.
The circumstances of usage are of crucial importance here, because they define largely what information you're going to want to offer, and how. Understanding the context of your users when accessing your site will allow you to tailor the information and the site's organization to support their desires. Knowing the browsing parameters will help you ensure that you're making the best possible use of the handset's features--and not abusing it.
Here are a few aspects, derived from the two observations above, that will help you define and shape the content of your iMode site.
Reference material is the information that people will be looking for in the strangest places. Such content depends on the site's activity of course, but you'll want the conditions of sale of a web shop, the bylaws of a non-profit group, the full faculty list for a university.
Actually, you'll want to make everything available on you iMode site that is on your web site. There is nothing more annoying to realize that what you want cannot be accessed with the particular browsing method you happen to be using at the time. Of course, this does not cover the medium-specific stuff such as Flash games (those wouldn't work anyway).
When you've got long documents, don't shy away from publishing them on iMode. While a handset screen may seem uncomfortable for reading large amounts of text, your users may be stuck on a train with nothing better to do, and they might actually enjoy having access to the real stuff, not only teasers. You should warn your visitors when a link leads to long content (for example, you may specify the target page's size in kb), and ensure that the link's description is clear enough to give a very precise idea of what's behind it.
Long content should be offered only as dead-ends, so that your visitors do not have to load and browse it all before accessing a link. Navigation from a page with long content should be limited to going back to the page's parent (or table of contents), and next and previous page, if relevant (for example if you're offering the different sections of a report: you don't want to force people to come back to the table of contents between each section).
If you have decided not to make something available on iMode, you'll want to make sure that your users don't waste time hunting it down, coming up empty-handed. Put up, where the link to the missing content should be, a paragraph explaining that it's not available on iMode.
When converting all of your content to iMode, you'll be tempted to organize your navigation differently. Be careful with that: you might end up confusing those of your web site users who happen to be accessing your iMode site. Your web site's navigation system should be available on iMode, but needn't be the only option.
When defining your iMode-specific navigation, you'll want to ensure that the core usage of your iMode site is well supported. This could take the form of
highlights or a
selection of the site's regular navigation. Here, you're aiming at catering for 80% of your iMode site's usage, with a list of 3 to 5 most-useful links. Also see
Analyze the logs below.
If you have more than just a few, clearly labeled pages available on iMode, one of the features you'll probably want on your home page is a search box. While typing in text is annoying, browsing through large amounts of content is close to impossible with a phone handset.
With a small screen, you must ensure that your search results are usable. This probably means that an overview of the results should be the first level (say, a very compact list of the page titles of each hit, ensuring that the visitor can see many titles on that results screen), while details are limited to a user-triggered event that requires no page reloading (for example scrolling the hit context or the page description instead of the page's title when a hit has been selected).
While you may rely on your search engine to deal efficiently with exceptional requests, your visitors will probably be particularly interested in a relatively small subset of your content. Your web server's logs will tell you what those pages are. You'll have made assumptions at "Support core usage" above, but hard data will allow you to ensure you're right.
If you have a brick-and-mortar presence that your web site users may want to access (i.e. if you're a store, an organization with offices that customers may visit, etc.), you'll definitely want a
location page as part of your most important iMode links. You can be sure that many of your iMode visitors are actually trying to visit you and have lost your address. Similarly, if you can be reached by phone, your iMode site should help people call you.
If your iMode site's address is printed on ads, some of your visitors will access it before actually viewing your web site. In that case, you'll probably want to trigger people to access your web site using a desktop web browser. Make it clear that your web site exists, give its address, and ensure that iMode visitors know why your web site is interesting.
Again, if visitors are likely to access you iMode site before accessing your web site, you'll want to ensure they don't forget you. Mobile browsing occurs within a totally different context than desktop browsing, and changing of activities and environment pushes humans to forget. To bypass this issue, you might want to let your iMode visitors to enter their email address, offering to send them a reminder or further information. Do comply with your country's private-data-protection regulations.
This is a tricky issue: you'll want to ensure that your iMode site is highly usable, on a handset that has a horribly small screen. This will not allow you to have a beautiful graphic interface (it would be wasted and would probably get between your users and the site). However, you must find a way to maintain brand identity on all your pages (with search engines you never know where people will enter your site), while not wasting bandwidth or screen real estate.
Last tip, an easy one: people who want to access you iMode site are, in most cases, going to enter its URL in their mobile phone. Phone keyboards are a disaster, so you must try to make that entry as easy as possible. Do not waste letters, and avoid symbols: http://i.yoursite.com/ is much better than http://www.yoursite.com/imode_web_site/. Check the "mobile typability" of your domain name with the Mobile Domainatron.
When QR-codes (2-dimensional barcodes) will be widely available on phones outside of Japan, this last tip will be less important. Until then...
Paul Baron's IN-duce has got interesting posts about mobile applications, straight from Japan.