Tag Archives: Platform Support

Deciding which smartphones to support

Deciding which platforms to support and to what extent we should support them is a complex decision.

On the desktop, the vast majority of problems reside in how we should support Internet Explorer (IE) prior to version 10 (which is a very standards-compliant browser). Both IE8 and IE9 are still widely used but have numerous deviations from the HTML and CSS standards. Many features are not supported, and those that are are often buggy. However, since the problem has persisted for such a long time on browsers that have historically been the most popular, the open-source community has constructed many libraries that fill in the holes. Furthermore, the issues and workaround have been extensively documented on the web. Hence the problems are for the most part contained and controllable.

There are also differences and bugs among the “standards-compliant” browsers. However, in recent years, as HTML5 and CSS3 have stabilized, most of the issues have been fixed. In addition, users tend to use the most recent versions of these “standards-compliant” browsers, meaning that we don’t have to deal with the old buggy versions.

On the smartphone and mobile platforms, the situation is very different. Although most mobile browsers are based on the standards-compliant WebKit rendering engine and aspire to be standards-compliant in their Javascript implementations as well, the reality is that there are still a lot of differences.

On the smartphone side, the issues are almost exclusively on the Android side rather than iOS. By far the major reason why these issues persist is because the Android OS is very often not updated by the manufacturers of the phones. As with the desktop browsers, early smartphone browsers contained numerous bugs or lacked many features. Although these bugs were resolved in future iterations and were included in subsequent Android OS releases, a huge number of Android devices did not receive the fixes. The manufacturers simply did not bother to adapt the new Android version to their devices, or, due to the fact that they skimped on RAM to develop “budget” phones, they could not update them due to insufficient hardware resources.

As a result, there remain a huge number of Android phones on old versions of the OS, and hence on old versions of the browser; versions which contains a lot of old bugs.

Bugs in the Android browser tend not to be as severe as the bugs in Internet Explorer. They mostly reside in the HTML5 and CSS3 implementations, both of which were not stable in the webkit code at the time the old Android browser was forked. Other bugs are in “touch interface” implementation, which also was not in the original webkit code. However, since web development in the HTML5/CSS3 era has evolved to emphasize animations, feedback and interactivity, these bugs are very significant.

A table of Android OS versions per phone

To decide which Android versions to support, we use this table (Android端末一覧) on Wikipedia that lists every smartphone model sold in Japan and which Android version it is upgradable to.

We can observe that almost all smartphones that were introduced up till September, 2011 have only been updated to 2.3.4. Up till April, 2012, many new phones ended up being stuck at 2.3.4-6. Only after April 2012, just a year ago, do we see the majority of phones being upgradable to Android 4.0. Hence support for Android 2.3 is inevitable.

Just for comparison, the current version of iOS, iOS6.1), is installable on even the iPhone 3GS, a model that was first sold in Japan on June 2009. June 2009 is a month before the very first Android phone was sold in Japan and that could only be updated to Android 1.6.

Assessing the current and future popularity of Chrome on Android

In developing websites, especially those like Ponzu/Kamishibai which make heavy use of Javascript and CSS3, it is extremely important to decide which browsers to support. Older browsers will tend to not support the features required to make advanced features on the website run, and so the decision has to be make whether to support that old browser at all.

In Ponzu/Kamishibai, we currently support the following platforms;

  1. Newer versions of Safari, Firefox and Chrome on desktop platforms. The decision to not support older versions is based on statistics that show that users of these browsers tend to update quickly to the newest version.
  2. Internet Explorer 10 on windows.
  3. Internet Explorer 8 and 9 are supported through browser-specific code modifications. More technically, we have separate CSS and Javascript files that are uses only on these platforms to make up for deficiencies. Hence testing tends to be less thorough compared to the more fully supported platforms. Supporting older versions of Internet Explorer is a necessary vice, due to the fact that Windows XP (which only supports up to Internet Explorer 8) is still prevalent, and that IT departments within corporations usually restrict updates.
  4. On iOS, we support the latest version only, with brief testing on older versions. This is due to statistics that show rapid adoption of newer versions of iOS. For example, iOS6 was found installed on 85% of devices after only 5 months. Furthermore, iOS6 can be installed on even the iPhone 3GS, a device released almost 4 years ago.
  5. On Android, we support the Android stock browser on Android version 2.3.6 and Android version 4.0. We also support the latest version of Chrome on Android.

Android fragmentation due to slow adoption of new OS versions

Android support is complicated due to two issues.

One is the fragmentation of the Android platform itself. This is well documented and data can be found on Google’s website. As of May 1, 2013, close to 40% of users are on “Gingerbread” (version 2.3.*), an OS version that was first introduced on December, 2010, and superseded by “Ice Cream Sandwich” (version 4.0) on October, 2011.

The Android stock browser is an integral part of Android and is updated together with the OS itself. Hence Android OS fragmentation directly corresponds to browser version fragmentation.

スクリーンショット 2013 05 13 9 35 30

Android fragmentation due to two different Google browsers

Android browser support is further complicated due to the fact that there exists two separate brands of browsers, both of which are developed by Google and both of which may be found as the default browser on even the newest versions of Android.

Up till Android version 4.0, the default browser on Android was always what is commonly referred to as the “stock Android browser”. However in June, 2012, Google released Chrome for Android. Since then, some but not all devices (e.g. Nexus 7) have Chrome as the default browser and do not have the “stock browser” installed.

Will Chrome become the new default browser for Android?

Because Chrome is developed by Google, the question is whether or not Chrome will be the default browser for Android. More practically, the real question is whether Chrome will become a significant proportion of the web audience.

Unfortunately, current statistics point to that not being the case in near future.

The below graph is taken from NetMarketShare which tracks global website usage. The graph is a breakdown of mobile browser usage on April 2013. Chrome usage (which is a combination of Chrome on Android and iOS) is 2.63% whereas Android Browser usage is 22.89%. If we make the assumption that Chrome usage is 100% Android, this calculates to 10.3% of Android users using Chrome. This compares to 28.4% of Android users on “Jelly Bean” (version 4.1.) and 27.5% on “Ice Cream Sandwich” (version 4.0.).

Chrome for Android cannot be run on versions lower that 4.0.*. The above numbers mean that 10.3 / (28.4 + 27.5) = 18.4% of “Chrome-capable” Android devices are running Chrome. If we restrict to “Jelly Bean”, the Android version from which Google removed the Android stock browser on Nexus devices, 36.2% are using Chrome at maximum (assuming that all Chrome users are on Jelly Bean, a rather unrealistic assumption).

These numbers suggest that Chrome for Android adoption is not particularly high, even among newer devices.

It does not look very likely that Chrome will become the number 1 browser on Android for at least a few more years.

スクリーンショット 2013 05 13 10 18 19

Non-Google branded smartphones do not use Chrome for the default

Whereas Google “Nexus” branded devices like the Nexus 7 come with Chrome as the default browser, and without the stock Android browser installed, the same is not true for devices from Samsung.

In this review for the recently introduced Galaxy S4, which comes with Android version 4.2, the default browser is mentioned to have Samsung-specific features which are not available for Chrome. Hence the stock Android browser is not only installed as the default, it has unique features which Samsung intends to use to differentiate from the competition.

It is therefore likely that Samsung has no plans to switch to Chrome as the default browser. Instead, Samsung will most likely add features to the stock Android browser to further differentiate itself. If Samsung were to switch to Chrome, that would mean the browsing experience would be almost identical to other smartphones. Poor differentiation means commoditization, and Samsung will fight hard to prevent that.

In fact, Chrome on Android is pretty badly implemented at this point, and using Chrome as the default browser is likely to worsen the user experience. As Google improves the Chrome code, this is likely to be less of an issue. However, there is a larger issue that will still stop Samsung from using Chrome aggressively.

Android is open-source, which Chrome is not

The comments in this article about Chrome for Android are mostly detailed and provide a lot of insight. Particularly interesting is the fact that while Android (including the browser) is open-source, Chrome is not. This is discussed in more detail here.

Hence for a manufacturer like Samsung, which has resources to modify Android to create a unique user experience, the Android stock browser is an obvious choice. They simply cannot customize Chrome. It is possible that Samsung will switch from the Android stock browser to their own browser based on webkit, but it is unlikely that they will move to Chrome. The same can be said of HTC and other major players.

For less capable manufacturers, they may chose Chrome, but they also might chose a third party which has a more capable browser or which will agree to customize.

Either way, the current situation is such that the first choice for the default browser has disappeared without anything to fill that gap. Chrome in the current licensing status will not fill in that gap, as Samsung will most likely not chose it. As a result, we might see extreme fragmentation in Android browsers.

Conclusion

Chrome is unlikely to become the dominant browser for Android in the near future. This is true even if we only consider new high-end phones since manufacturers seem reluctant to give up their own customized stock browser in favor of Chrome.

The result is likely to be that we will see even more fragmentation of Android browsers. The players will be customized stock Android browsers (from Samsung, HTC and larger manufacturers), Chrome, Amazon Silk and third party browsers (which will be endorsed by smaller manufacturers which cannot customize the stock browser themselves).

The situation is pretty grim for web developers which want to take advantage of cutting edge HTML5/CSS3 features on Android.

Multi-device support and integration for conferences

To fully support the workflow of a conference participant, it is insufficient to simply provide applications for multiple devices. These devices also have to share information and to work together as one.

For example, a conference participant might want to do the following prior to and at the meeting;

1. Search and browse the sessions and presentations on the PC on his desk at the office, adding some to his “My Schedule”.
2. Do the same on his smartphone or tablet as he commutes home.
3. Do the same on his laptop on the train to the conference venue.
4. At the conference, look up his “My Schedule” on his smartphone or tablet.

To enable this, the supported devices must be capable of sharing information. Ideally, this should be seamless, without the user having to explicitly “sync” his/her device (they will always forget to do that).

Although conferences commonly provide both a website for PCs and smartphone applications, the “My Schedule” feature is often completely independent and is not shared. This is ridiculous.

Ponzu is a single web service that supports multiple devices. It is not a combination of different solutions for each separate device. Therefore, information sharing is built-in.

Supporting participants’ workflows

To understand how to create a great conference system, we have to clearly understand what a participant will want to do prior to the conference, at the conference and after the conference.

Conference IT systems should adjust to the needs and devices that scientists possess. Scientist should not be forced to own certain devices simply to access conference information. The IT systems should be there to help, not rule over the scientists.

We realize that while 100% of scientists have a laptop computer, much fewer own smartphones and even less own tablet PC devices. We recognize that scientists are not necessarily tech-geeks and many will not purchase new fads. There will be “laggards” in the high-tech device sense, but these “laggards” are often the scientists who have a large presence and saying in the scientific community.

We also acknowledge that even though tech-savvy scientists will want to use smartphones or iPads at the conference floor, they will still use traditional PCs in their planning phase at their office. Hence the IT system should seamlessly sync whatever they did on their laptops to their smartphones.

Therefore, an IT system for scientific conferences must work well with laptop computers, and also accomodate new gadgets. Focusing on new gadgets at the expense of laptops is not an option.

Unfortunately, this is contrary to what a lot of conferences are providing.

Looking at competitor activity, it seems that their priorities are;

  1. Provide a native smartphone application.
  2. Provide a rudimentary web site for PCs.
  3. Congre uniquely provides syncing between the PC site and smartphone apps.
  4. Provide a iMode site (only Congre).

Our priorities are;

  1. Provide a cutting-edge experience on PCs so that they can do their preparations effectively.
  2. Attendees can chose whether they want to bring smartphones, tablets PCs, iMode phones or printouts to the conference.
  3. We support smartphones, tablets, PCs, iMode phones on-site.
  4. After the event, they can go back to their PCs and create a report.

How many platforms do we have to support?

The simple question in the title can be reframed as “Do we want to exclude paying participants or distinguished speakers from accessing the conference program?”. Of course the answer is NO.

Although the percentage of smartphone users exceeding 50% of total mobile phone users in the United States, the number is much less in Japan. As of 2012, only about 30% of Japanese mobile phone users use a smartphone. Furthermore, demographics suggest that while younger to middle-aged people are more likely to own a smartphone, elder people, the people who tend to be distinguished professors, are not. Moreover young students are often admitted without charge. Therefore, if we were to calculate the total attendance fees from smartphone owning participants and to compare it with non-smartphone owners, we would probably find non-owners paying more.

Despite this, there is a tendency for conferences to provide native smartphone applications, which will not run on feature phones. Even when there is a website for PCs, it tends to be a very simple and rudimentary search system.

We think that this is a ridiculous situation. Our goal with MBSJ2012 and with the current Ponzu system is to support as many devices as possible, including the millenniums-old but always reliable medium; paper.

Our support strategy is as follows;

  1. PCs: The most ubiquitous digital device among conference participants is the PC. Every researcher has a PC to write presentations and journal articles. They will use their PCs to find out which presentations interest them, and which ones they will want to see.
  2. Smartphones: Smartphones are gaining in popularity and provide a huge amount of functionally. Many researchers will want to use smartphones to check the conference program.
  3. Feature phones: Although not as powerful as smartphones, feature phones are nonetheless capable of browsing websites. If an appropriate website is provided, feature phone users too can easily check the conference program.
  4. Tablets (iPad): Tablets are the ideal device for viewing conference programs on-site. They provide a wide screen while being totally usable standing. However, their popularity is still limited. The people who own tablets are a minority.
  5. Paper (PDF): PDFs are great for downloading and printing onto paper. If you do your homework and narrow down the presentations that you want to attend, then the amount of paper you have to bring is actually quite manageable.

Our commitment is to support all of the above media with the highest quality possible. Supporting five different media is a huge challenge, but was made possible by integrating all the platforms within Ponzu and Kamishibai.