We ♥ web applications!
At mobalean we love to build innovative web services for Japan and the world. Our experience will help transform your ideas into successful online services.
At mobalean we love to build innovative web services for Japan and the world. Our experience will help transform your ideas into successful online services.
Mobalean is lead by Henri Servomaa, the original founder and mobile developer. At Mobalean we strive to develop services which are loved by our clients and users. By working in an agile manner, quickly adapting to changing requirements, we can deliver quickly and often.
Hailing from Finland, Henri has a long history with computers and the internet. With a background in Electrical Engineering and Computer Science, he has worked in Japan as Software Developer and System Admin since 2001. In 2005, he joined a company to develop mobile sites for the Japanese market and has been involved in mobile ever since.
Cleve Lendon is a Canadian engineer who has been contracting for Mobalean. He came to Tokyo in 1994, and has lived here ever since. He has broad experience as a software developer, which includes development of mainframe software, Internet applications and mobile apps (Android and iOS). He is especially skilled at writing Java applications (vd. Simredo 4, Grafikilo 15). When not programming, Cleve enjoys improv acting and studying languages, such as Latin and Esperanto.
Our strength is crafting web services for both Japanese and international markets. We bring our technical and cultural experience to help you adapt your ideas into successful products.
We develop with Ruby on Rails and use the best agile practices and tools, such as test driven development and continuous integration to achieve quality.
We are the leading provider of technical expertise about the Japanese mobile web. Mobalean started when the smartphones were just appearing on the market. Our Keitai Web Technology Guide is a quick starting point for learning about the initial challenges of Japanese mobile development. Although the technology stacks have changed since the proliferation of iOS and Android, some of the idiosyncrasies remain. Most notably, the Japanese market is still very much dominated by the big three carriers: DoCoMo, au and Softbank. Developers can find more technical details in our Keitai-Dev Wiki.
Please contact us with your specific requirements.
Email address: firstname.lastname@example.org
If you prefer to call us, feel free to do so under +81 (0)70-6251-7245
For users of Skype, please call mobalean
Last Updated: August 20th, 2010
This guide will provide you with a technical overview of the features available and challenges faced when building a mobile site for the Japanese market. With the information provided in this guide you should be able to identify the technical hurdles you will face when bringing your site to the Japanese market.
There are two major classes of handsets in Japan: Smartphones and Keitai. Smartphones are devices such as the iPhone or Android based phones, and use mobile versions of standard browsers. Keitai on the other hand are designed specifically for the Japanese market and use traditional Japanese mobile Internet browsers, such as docomo’s i-mode browser (keitai browser).
Smartphones make up about 4% of the mobile market, with about half the devices being iPhones. As these phones are largely of foreign origin, they support global standards and won't be covered in detail in this guide.
Keitai are manufactured under the direction of the three major mobile carriers (NTT docomo, au by KDDI, and SoftBank) that almost entirely control the Japanese mobile market. The information in this guide pertains to these carriers' 3G handsets, which account for more than 99% of all keitai.
It is assumed that the reader will be reasonably familiar with web technologies on a high level. As such, the envisioned main audience are technical managers and leaders of companies who already run a web site and possibly a mobile site as well. Mainly, this guide should assist in planning for technical feasibility and cost estimation when creating a new mobile site or porting an existing one for the Japanese market.
However, while the main outlines are clarified here, there are many low-level details that developers and designers will be faced with when creating a mobile site. Complementary documentation or knowledge of those details is necessary for creating a site that works and is well received in the market. Please contact us for more specific assistance.
Each carrier in Japan offers its own data transmission service. This service determines the exact characteristics of the browser. Because of this, the carrier is the primary classification for a keitai, determining generally what markup is supported and so on. The following graph shows the breakdown of subscribers by internet type.
|2G Discontinuation Date
No approval is necessary to start an off-portal or "katte" mobile site in Japan. However, the carriers offer the possibility to register a site and be listed on the carrier's portal. One of the main benefits of being on-portal is to have access to the carrier's billing for selling virtual goods and services online.
Carriers take a 10% commission on any revenue generated via their billing, and thus it is in their interest to nurture on-portal sites by offering access to specific services, full documentation and support. Also, for search results on the carriers' portals, on-portal sites will always be placed before off-portal sites.
However, the registration process as well as the restrictions and requirements on the site itself make it costly to create and run an on-portal site.
The primary benefits of an on-portal site are:
and the disadvantages are:
While the on-portal registration itself is free of charge, the time and effort spent on paperwork is non-negligible. Mediating agencies commonly charge about ¥1,000,000 for completing the process on all three carriers for one site.
Holders of attractive content can benefit from the easy carrier billing. However, being an on-portal site is not in itself a guarantee or a requirement for financial success.
All the 3G Keitai support some dialect of XHTML. For best results across all Japanese carriers, use XHTML mobile profile basic (XHTML-MP basic), as defined by the W3C, as the base for your markup.
The Shift JIS and UTF-8 character sets are supported. UTF-8 is not supported on SSL pages for au handsets with 6.2 browser (about half of the browsers in use currently). Shift JIS is lighter weight for Japanese text, using roughly two-thirds of the size as the same text in UTF-8. There are some special characters that exist in Shift JIS that are not available in UTF-8.
The best practice for international sites is to store text internally as UTF-8, and display Shift JIS to the user when necessary.
Markup can be styled using CSS. However, docomo phones require all styles to be in-lined as demonstrated in the following:
<span style="font-size:small; color:#ff6666;">text</span>
Furthermore, there is only a limited range of styles that can be applied. For instance, bold text is only supported by some handsets, and italic text is largely unsupported. Styling that does generally work includes setting text and background color, font size, and text alignment.
Japanese mobiles have supported email since nearly the beginning of mobile Internet service. Each subscriber is assigned an email address by their carrier. Email is used for phone-to-phone communication in much the same way as SMS is used abroad.
There is no restriction from sending email from keitai to PC and vice-versa. However, be careful when sending large volumes of email from PC to keitai, as the carriers have fairly tight anti-spam restrictions. There are a number of mailing services designed to send mass-mailings to keitai. Keitai also support HTML-email, known as deco-mail, and mail attachments such as images and video.
Email is also typically used to simplify the sign up process for mobile sites. Instead of asking the user to enter his email as part of the sign up, sites usually prompt the user to send an empty email to a specific sign up email address. This triggers an answer email being sent back to the user which contains a unique link back to the site to complete the sign up. This process is usually referred to as “kara-mail”.
SSL is supported by keitai. However, mobile phones are fairly restrictive about what certificate authorities they support. Furthermore, wildcard certificates are not supported.
There are also other technical limitations, such as the character set issue mentioned above, that can make the integration of SSL pages within the site rather tricky. If SSL is deemed necessary, the usage should be restricted to the minimum number of pages, and all flows and functionality must be checked with a variation of actual handsets.
JPEG images are universally supported. GIF (including animated) is almost always supported. PNG is unsupported by older docomo phones.
As each image in a page causes a separate request to be made, images should be used sparingly. Especially older docomo phones do all requests in sequential order, so the loading time increases significantly if many images are used.
Flash Lite has a long history in Japan. Both in-line and full flash is supported. In-line flash is not interactive, whereas full flash supports simple navigation and interaction. Flash is most often used for decorative navigation and games.
|Flash Lite 1.0
|Flash Lite 1.1
|Flash Lite 2.0
|Flash Lite 3.0
|Flash Lite 3.1
All carriers provide a method to uniquely identify a subscriber. SoftBank and au always send the subscriber identifier, whereas docomo provides three options for obtaining a subscriber identifier but it has to be requested explicitly. The first method docomo supports is available for on-portal sites only and is via usage of an URL parameter. The second method is via special markup and requires the user to explicitly confirm sending it each time it is requested. Lastly, the third method is similar to the first one, but is not guaranteed to be sent and does not work under SSL.
The Japanese language has effectively four types of characters. Kanji, coming from Chinese characters. Hiragana, which is often used for writing native Japanese words. Katakana, which is used for writing foreign words. Alphabetic characters are also often used. A combination of all four of these are often used together.
An input field can specify which of these input modes to use. This is helpful to a user when the format of the field is known, like a phone number.
Keitai are able to display narrow katakana characters which occupy half the screen width of an ordinary katakana character (hence the name half-width). Half-width katakana allows for more text to be fit into the same area.
Emoji are pictograms that can be used to add graphical flair to a page. Because they use character codes, unlike images they do not trigger additional requests to the server. However, these codes vary from carrier to carrier, so a page needs to be adapted to a specific carrier to use them. There are several server side libraries for doing this, however, be aware that there isn't a 100% correspondence between the carrier's sets of emoji.
A web page can collect location information from a user by using the location of the transmitting tower or GPS if available. This is done by special markup commands that vary from carrier-to-carrier.
A QR code is a two-dimensional bar code that can contain information such as text, an URL, an email address or a vCard for instance. All keitai come equipped with a QR code reader to quickly scan the information. Japanese sites frequently use QR codes in print advertising to allow users to access their site without the need to manually enter the URL.
The purpose of this section is to discuss features which are not available for the majority of keitai users. As a result, relying on those features to be present will limit the audience of your site or can cause usability issues.
Keitai ship with two browsers: one that is designed to access the carrier's specific mobile service and another for accessing PC sites. However, as data for PC browser access is charged differently (and is not necessarily included in unlimited plans), users do not normally use it. Only about 16% of subscribers use the full browser function, and of them, only some 32% use it more than once per week [携帯白書2010].
All au and SoftBank keitai support cookies. However, until the i-mode 2.0 browser, docomo keitai did not. This means a site cannot rely on cookies being present to function for the Japanese market. To persist session information, a session ID parameter is usually used in the URL.
SMS is practically unused in Japan, and Japanese handset owners are not necessarily familiar with this term.
Only docomo and SoftBank support SMS. au offers a similar service called c-mail which only works within the au network. SMS is offered by docomo and SoftBank as a means to send a message to a handset overseas, at a hefty price premium (docomo ¥50, SoftBank ¥100 per message).
Almost all docomo handsets support Java, in the form of either DoJa or Star profile (Star profile is backwards compatible with DoJa). It is reasonably straightforward to convert a MIDP application to DoJa.
au first introduced Java support with EZ Appli, however the last phone to support it was released in 2004. From Summer of 2007, au reintroduced support for Java again through Open Appli.
Most SoftBank handsets support Java (MIDP profile). Unlike applications for docomo and au, however, SoftBank applications cannot be downloaded from an arbitrary web site. Instead it must be downloaded through a trusted domain. There appears to be only one company acting as a trusted domain to businesses, which charges between ¥78,750 and ¥245,700 per three months of hosting for the application.
In general, rules that apply for developing international mobile sites, such as keeping pages and flows simple and small, also apply to Japanese keitai sites as well. The differences with Japanese keitai sites is mostly related to dealing with carrier idiosyncrasies and understanding (and setting) the target.
Due to docomo having the largest market share while also having the most restrictive browser, sites are usually built for docomo first and then adjusted for other carriers. Dynamically detecting the carrier and keitai, and apply specific customizations can be used to achieve an optimized experience for the user.
The combined use of SSL, URL links with parameters, mailto links with parameters, form inputs and so forth can cause characters to be displayed badly or inputs to be misinterpreted. Pay special attention when you are using these features.
Apart from docomo, the carriers have no public information available in other languages. Even the Japanese public carrier documentation is far from being comprehensive. To resolve issues and answer questions, it is often necessary to search through Japanese developer sites or ask the local (often Japanese) experts. Please contact us for assistance.
Although functionality can be tested to a good extent by using a browser, it is imperative to do testing on actual devices to verify there are no technical issues and check the user experience.
Metrics such as page and image loading and rendering speeds can be used to measure the user experience. A page should display a response to the user in at most 7 seconds, as anything longer will cause the user will navigate away. To fully experience the display and navigation of a site, it must be used through the handset interface.
Japan has an advanced keitai ecosystem filled with idiosyncrasies. Applying common mobile knowledge and techniques will allow you to build a basic keitai site. However, building a site that works well across all keitai requires great effort unless you have extensive experience within the market. mobalean can provide you with the local expertise to overcome this challenge. Don't hesitate to contact us for assistance.