Kara-mail (空メール) is a user interface design pattern commonly seen in Japanese mobile web sites. As all Japanese mobile phones have an email address, registration for mobile sites usually requires an email address. However, entering an email address is relatively time consuming for a user to do. So instead of asking the user to input the email address, sites have a user send them an empty email, hence the name kara-mail (kara is Japanese for empty). After the site receives the email, the site will reply with an email containing a sign up link. Upon clicking the sign up link, the user can then complete the sign up process.

On Doorkeeper, we use kara-mail to allow users to easily sign up to attend an event via their mobile.

Kara-mail Registration with Doorkeeper

Because mobile spam is particularly annoying, mobile carriers have a setting that will allow users to block all email that do not come from other mobile devices or a specifically whitelisted domain. To help users whitelist our domain, we link directly to the carrier settings page. Additionally, as most Japanese mobiles do not support copying of web page text, but do allow copying of form input text, we put our domain in a form input so a user can easily copy it.

Depending on the mobile carrier, we show an appropriate link to the settings. The links are

For more tips on designing for Japanese mobiles, see our Keitai Web Technology Guide.

For international corporations, the Japanese mobile market can be attractive. High 3G penetration, affordable flat rate data plans, and long history of mobile have lead to a market where most people use mobile Internet. However, the market is also challenging to enter. The following are some of the biggest challenges foreign companies will face when entering the market.

1. Possible Transition Towards Smartphones

The Japanese mobile market has traditionally been controlled by the three major carriers, who have dictated device specifications to handset manufactures. This tight control meant that handsets stayed fairly standardized within the carriers.

However, Japanese subscribers are increasingly adopting smartphones. According to a report by seed planning, as of the end of financial year 2009, 3.4% of subscribers had smartphones and by 2015, 40% of all subscribers are projected to have smartphones. The smartphone market is currently dominated by the iPhone, but traditional keitai manufactures are fighting back with Android-backed smartphones with features usually found only in keitai. For instance, KDDI is releasing the IS03, with a 1seg television receiver, a FeliCa electronic money chip, and applications for their music and navigation services.

Unlike the North American market, where only smartphone users tend to use mobile Internet, in Japan, keitai and smartphone subscribers alike frequently access the Internet. As such, although the future of traditional keitai is uncertain, it is essential to support them, while planning for the upcoming smartphones.

2. Japan-specific Technology

Galápagos syndrome is a term used by Japanese to describe the domestic mobile market. Keitai have evolved differently from the mobiles in the rest of the world. For instance, SMS is not used in Japan, and instead push email is universally supported. Additionally when compared with smartphones, keitai have a number of technical limitations that mean not only will keitai optimized templates be required, but also the back-end technology will need to handle these limitations. Our Keitai Web Technology Guide covers this in more detail.

3. Established Market with Big Players

With 10 years of history, the Japanese mobile market has had more time to mature than the rest of the world. This means if you are only now entering the market you are likely competing with existing sites for users or SEO. For instance, if you are a brand looking to launch a site in Japan, likely there are already many mobile commerce sites selling your product which you will need to compete with. To be successful in Japan, international companies will need to overcome the already entrenched local competitors.

4. Design and User Experience

Keitai sites generally follow similar patterns with look and feel. Furthermore, keitai allow only limited options with regards to styling of pages. As such, for design and site flows, it is important to work with local people who are experienced in building keitai sites to create an appealing experience for the Japanese audience.

If you are looking to bring your mobile web service to Japan, please contact us and we can help review your current site flows to identify challenges for the Japanese market.

For over a year, we have been helping with the organization of Mobile Monday Tokyo, a leading networking organization supporting the local mobile industry.  One challenge we faced with Mobile Monday Tokyo was at-the-door check-in, as finding a given participant required scanning through a list of over 200 registered participants.  To address this, we settled on distributing tickets with QR codes, which are ubiquitous in Japan.  As every standard Japanese mobile phone is equipped with a QR code scanner, this is a fast, easy to use, and cheap solution for handling at-the-door check-ins.

What began as a simple tool for checking-in attendees, evolved into a fully featured event management system.  Tailored to the needs of Mobile Monday Tokyo, we built a system that helps to

• register participants with minimal friction
• quickly check in attendees at the door
• engage the community of participants
• gather information about attendees
• sell tickets online

This event management system has helped to smoothly run many Mobile Monday events in Tokyo.

Enter Doorkeeper

The challenges faced by Mobile Monday Tokyo are similar to many other types of networking, industry and similar events.  So today we are opening this service to the public as Doorkeeper to allow everyone to take advantage of the easy ticketing and check-in it offers.

Doorkeeper delivers a compelling and cost-effective solution for many event organizers.  With Doorkeeper, we only take a small commission on tickets sold through our system.  No setup fees, no monthly fees, no other hidden fees.  You can use Doorkeeper to host your free events for free.

Why not try out Doorkeeper now?  Visit http://www.doorkeeper.jp/ for more information and to create your first event.

Also follow us on Twitter: doorkeeper_app

We are proud to announce that the Mobalean wiki has been merged with the Keitai-dev wiki. The Keitai-dev wiki was created in 2004 to serve as an English language resource for Japanese mobile development. At Mobalean, we created our own wiki with a similar purpose in mind, so this merge is natural. With this merge, the Keitai-dev wiki becomes the premier English language resource for Japanese mobile web development.

Mobalean will now handle the management of this wiki, and continue to expand it with content relevant to Japanese mobile development. Thanks to Starling Software, the previous host of the Keitai-dev wiki, for creating this resource and helping us merge these two resources.

IMJ Mobile has released Mobile User Book 2010,  a collection of 8 surveys (in Japanese) about the following topics:

• Mobile Video Usage
• New Mobile Services and Technology
• e-Commerce Sites
• iPhone
• Cloud Computing (what is the connection to mobile?)
• Industry's Usage of Mobile Sites
• Usability of Mobile e-mail Magazines
• Flash Mobile Site Usability

The book is available for download as a free pdf, so if you're interested in mobile in Japan, it's worth checking out.

matsui-san has written a new blog post on ke-tai.org, describing KEITAIALL, a service for viewing technical specs for Japanese mobile phones.  I'm a fan of the site's simple and clean design, that allows you to view information about handsets at a glance, or search for a specific model.

The information provided includes:

• Carrier
• Model Name
• Manufacturer
• Sale Name
• Series
• First Day of Sale
• Browser Version
• Generation (2G/3G)
• Cache
• Screen Width
• Flash Version
• Ranking According to Share

matsui-san ponders about the licensing of this data, and points out that you can view all the data in xml by visiting http://keitaiall.jp/inc/choice.xml.  If developers are free to use and adapt this data as they choose, it could be a great boon to developers.

Betrend has released a report on mobile access in Japan based on accesses to their mobile platform for the month of October 2009.  The results of the report follow.

Access by carrier

Handset Capabilities

Top handsets by carrier

docomo

au

SoftBank

In the past, a mobile site had to be built using carrier-specific markup to properly function for that carrier. However, now it is possible to use XHTML to build a cross-carrier site, as all Japanese 3G handsets support some form of it [1]. Unfortunately, it is not the same dialect of XHTML: Docomo use i-mode xhtml (based on XHTML mobile profile), au uses XHTML basic, and SoftBank uses XHTML Mobile Profile 1.2. Nevertheless, although there are some differences between these versions, they all share a common base, making it possible to make a site that will function more or less the same across all carriers.

Given that not all handsets support XHTML, if you were to build a mobile site using XHTML, what percentage of handsets would it support? I've scoured the web for the answer to this question, but haven't been able to directly find the answer anywhere. However, as the number of handsets subscribing to 3G vs 2G plans are available, if we assume a handset supports XHTML if and only if it is 3G, we can use these numbers to find the answer.

In total, over 95% of Japanese handsets natively support some form of XHTML. Almost all au handsets support XHTML natively and furthermore the au gateway handles conversion of XHTML to HDML (the markup that older au handsets used). As SoftBank will discontinue its 2G service on March 31, 2010, current subscribers will need to migrate to the 3G service (and handsets that support XHTML). Finally, although Docomo has, relative to the other carriers, a large number of handsets that are not XHTML compatible, Docomo claims that i-mode HTML (which older Docomo handsets use), and i-mode XHTML is mostly compatible. Therefore, I would suggest that if you are building a site for the Japanese market, you do so using XHTML.

[1] Although many Japanese web sites say this is the case, it does not appear to be technically true.  According to Docomo, handsets from the FOMA  2051V, 2002, and 2001series do not support XHTML.  However, we can assume these handsets are few enough to make this generalization.

mobalean is a strong believer in open source.  Collaboration and sharing are at the core of our philosophy.  So we are proud to announce three contributions to the developer community: a WURFL patch file containing about 700 Japanese handsets, a ruby script for parsing the Japanese carrier data and converting it to the WURFL patch file format, and a major update to the ruby WURFL api.

The WURFL is an XML file containing mobile device information such as supported markup types, screen dimensions, and flash lite support.  While the WURFL has a lot of devices in it, including some Japanese ones, the data for them is both poor in quality, and incomplete.  To remedy this, mobalean has created a WURFL patch containing data on all handsets available from the major Japanese carriers (docomo, au, and SoftBank). 

This patch contains data on approximately 700 handsets and has the carrier values for the WURFL capabilities resolution_height, resolution_width, max_image_width, colors, brand_name, model_name, flash_lite_version, xhtml_table_support, and preferred_markup.  While the base WURFL contains additional capabilities for some Japanese handsets, the values of these capabilities are often wrong.  Rather than trying to validate the data in the base WURFL, this patch takes a blank slate approach, and ignores the devices in the base WURFL (with the exception of fallbacks).  All the data in this patch comes from the carrier's official data, and as such is believed to be correct.

mobalean releases this patch to the community in the hope that other members of the community can help improve it.  As with the base WURFL, you are free to use this patch in any manner you so choose.  Our only request is that if you improve the data within, that you also contribute back this data.  Additionally, we hope this patch can eventually be merged back into the core WURFL so that all WURFL users may benefit from it.

To generate this patch, we scraped the carriers' data using a ruby script.  The script transforms the data into an intermediary result, and from that result into a WURFL patch file.  In addition to the WURFL patch file, we have also released our parsing script.  By open sourcing this script, we believe others in the Japanese mobile community, even those who are not using the WURFL, can benefit.  Additionally, we hope that modifications to the WURFL patch be made via this script instead of directly to the patch.  This way, we believe we can more easily keep the patch up to date with new handsets.

In the process of generating the patch, we wanted a way to test the resultant patch file.  We did not want to parse the XML directly, as that would not take in to account the fallback structure.  So we turned to the ruby WURFL API, but found that it did not work out of the box.  As no one else was currently maintaining this API, we decided to take over it.  In doing so, we've turned it into a ruby gem, and have released version 1.1.0 of it.  We hope that this new, easier to install version will encourage further WURFL development within the ruby community.

mobalean hopes these contributions will be useful to other developers.  If you have any questions about these projects, or anything else, don't hesitate to contact us.

• Basic JavaScript support (based ECMA-262)
• External CSS
• Cookies and Referer header
• Copy and Paste within the browser
• Multi-window function
• Increased page size from 100KB to 500KB
• BMP and PNG support

Of particular interest to mobile web developers will be the external CSS and cookie support (rumors about this were mentioned previously).  The lack of these have caused developers headaches, as while SoftBank and au support them, docomo did not.  It will be some time before developers can assume all Japanese mobiles support external CSS and cookies, but it is good to see that we are moving in that direction.

Once more concrete details come out, we'll follow up on this story.