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.

In June of 2009, mobalean release a patch for the WURFL containing Japanese handsets. This patch ignored the existing data on Japanese handsets in the WURFL as it was sparse and mostly incorrect. However, this also made it incompatible with the core WURFL, and applying the patch either required using one of the more lenient libraries, or manually editing the core WURFL.

After half a year, thanks to the hard work of the WURFL maintainers, these incompatibilities have been reconciled, and the data merged into the core WURFL. Any developer using the WURFL can now use it to start building Japanese sites right away.

Because our patch has been included in the core WURFL, we will no longer maintain a separate patch file. All new handset data will go directly into the core WURFL.

The updated WURFL is available through the WURFL project page.

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.

There is a rumour going around that new docomo handsets will support cookies and send referrers.  Kimura.Memo has an article stating that he has received a request from a docomo user agent using a docomo IP address that sent the headers HTTP_COOKIE and HTTP_REFERER¹.  This means it is potentially an actual handset, however it could also be some sort of test on docomo's part.

In the past, docomo's handsets have not supported cookies.  This has meant for a site to support sessions, a session id parameter had to be added to URLs.  As the other major carriers, au and SoftBank, support cookies, this has caused developers some pain.  However, if docomo's handsets will support cookies, this will make things easier. 

Whether docomo's new handsets will actually support cookies remains to be seen.  If only new handsets support cookies, this will probably change little in the short term, as most docomo handsets will still not support them, and developers will thus need to design for the old handsets as well.  However, it would be a step in the right direction, and mean in the future, developers could start assuming all handsets support cookies, much like they are now doing with XHTML support.

Footnotes

1.  An interesting side note is that referred is misspelled in the header, HTTP_REFERER.

CakePHP is a development framework for PHP that borrows many ideas from Ruby on Rails. I first heard about it when reading through the Merb camp keynote, which states Ruby On Rails is more then 10 times faster then CakePHP (and Merb is even faster). At mobalean, we prefer using Ruby, but if you happen to be using PHP, check out Ktai Library for CakePHP1.2.

The features of this library include:

• Handset detection by user agent (docomo, SoftBank, KDDI, emobile, iPhone)
• Carrier detection by email
• Cross carrier emoji lookup
• Entire page emoji conversion
• accesskey attribute for links
• Display emoji on PC

I had a quick look through the code, and unfortunately while CakePHP is Object Oriented, this code is not. This code, like much of the code for Japanese mobiles make extensive use of a "carrier code" variable. If the library used carrier objects instead, it would be much cleaner. Additionally, there is a lot of duplicated boilerplate code in the KtaiHelper and KtaiComponent class that code be removed in Ruby through the use of the Forwardable module. Nevertheless, if you are using PHP, you might be able to find something that helps you.

(Hat tip: matsuiさん)