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.

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さん)

docomo will launch a social network like service, docomo community (ドコモコミュニティ),  on March 2, 2009.  The service bills itself as a way to share photos and journal entries between friends and family members, and seems especially targeted at sharing between children and parents.  This is shrewd marketing on the part of docomo, who along with SoftBank and au introduced content filtering earlier this year, blocking sites in categories including SNS for all users under 18.  Perhaps in part to preempt others from crying foul, the site will not have any user search feature and to add a "friend" will require a user to input the other user's i-mode email address.  The service itself will be free (though normal packet charges apply), and be limited to users with FOMA handsets and above (non docomo handsets will not be supported).

(Hat tip: matsuiさん)

It's been a busy six weeks getting mobalean up and running. 

Incorporating in Japan is relatively easy and cheap. If you can speak Japanese and are able to register your seal (hanko), you can probably do this work yourself. The whole process took us about a month to complete. 

Apart from setting up the company, we've been pursuing development contracts and participating in community events. Since the beginning of the year, we've helped MoMo with their event organization, done system admin work for TLUG and gave a presentation at Ninjava. We intend to continue participating in these events and continue our work in the development community. 

As a development company, mobalean needs to keep learning and developing new technology. Sharing is part of this process, so we will post our findings and other experiences on this blog and also use the wiki for more technical details.

Cheers!