Category Archives: Platform-support

Responsive web design and the problem with desktop websites

In the current iteration of Ponzu, almost all the views (except for feature phones) share the same code. That is to say that the desktop version, the tablet version and the smartphone version are the same HTML, Javascript and CSS with a little bit of CSS media queries to shrink down the interface for smartphones.

This is responsive web design.

Responsive design is a web design trend but is not without criticism. The most prominent criticism came from Jakob Nielsen, an expert in user interface design, in the blog post “Repurposing vs. Optimized Design”.

Nielsen point boils down to the following sentence;

It defies all common sense to expect the same user interface to be optimal for 3.5-inch screens and 30 inch screens, with no modifications beyond moving a few things around. Diversity in our interactive platforms requires diverse interaction design.

He lists the following as things that ought to be different for mobile vs. desktop design;

1. Most important, the content should be different: shorter and simpler writing is required for the smaller screen because the lack of context reduces text comprehension. 2. The IA changes to defer secondary content to secondary pages on mobile devices. 3. Interaction techniques change due to the differences between finger and mouse-driven input. 4. The feature set is reduced in mobile to lower complexity and to fit on the smaller screen.

Nielsen’s post met a lot of criticism from web designers, and he elaborated his points in a subsequent interview.

Similar points have been discussed in various blogs, and I find this article by Brad Frost, comparing the presidential campaign websites to be very informative, mainly because it compares the extremes.

Brad Frost summarizes the potential pros and cons of optimized-design vs. responsive site in the following.

Access

And while responsive designers can (and do) hide content from small-screen users, responsive design affords less opportunity to fork the content and create disparate experiences, which would deprive certain users of valuable information and features.

The main problem with Mitt Romney’s (optimized-design) mobile website is that only a fraction of the full website’s features are included.

Another common problem with separate mobile websites is URL management. Because desktop and mobile content live at separate URLs, device detection is required to route users to the appropriate site. Unfortunately, many websites don’t go deep enough in their URL redirection, so desktop users will get sent to mobile content and vice versa. This becomes apparent when mobile content gets shared by mobile users on social networks and then gets accessed by desktop users: Issues arise when a mobile URL is accessed from a desktop.
As we can see, having Web content all under the same roof and URL definitely makes it easier to give visitors access to the content they’re looking for, regardless of the device they happen to be using.

Interact

Obama’s (responsive design) navigation fails on a whole load of mobile devices: “And the menu failed. Never even opened. Suddenly, the site was without navigation… at all.”

Scrolling

Romney’s (optimized-design) mobile website has an acceptable page length.

Obama’s (responsive-design) pages contain a massive amount of content, often introducing entirely new sections far down in the flow. The result is extremely long pages that have serious problems.

Peformance

A typical page on Romney’s (optimized-design) mobile website is about 687 KB and, as a result, takes about 8.75 seconds to load. While that’s over the 5-second mark, the pages still weigh less than the average size.

A typical page on Obama’s responsive website is a massive 4.2 MB, resulting in a 25-second loading time.

The picture painted in Brad Frost’s article is that neither candidate got their mobile website right, even though Romney’s site appeared to follow Nielsen’s advice.

The question is how should we design the Ponzu conference system.

The problem is not about mobile. It’s about desktop design.

As I have discussed previously on this blog and others, my take is that desktop web design is too complicated. Rather than making mobile much simpler than current desktop design, my idea is to drastically simplify desktop design. By simplifying desktop design, it will become more adaptable to 3.5 inch mobile screens with minimal layout changes.

Tablets will be the motivation to simplify desktop design. In fact, I think that desktop websites should be designed primarily for tablet audiences.

iMode mobile sites and smartphone mobiles sites are different

When it becomes difficult to support a certain platform, one option is to provide a separate website that is written in simple HTML, and redirect that platform to this website.

This is how we support IE7 and below in Ponzu. Since our CSS and Javascript require at least IE8, we redirect IE7 and below to our website designed from iMode browsers. Since iMode only supports the simplest HTML and CSS, this website is extremely simple. Any browser, probably even old Netscape browsers are able to render to render this correctly.

One problem however is touch-based interfaces. When we render the iMode site on a touch device like an Android smartphone, the links are too small to tap with a finger. Although even the most incapable Android smartphones are able to correctly render the iMode website, the links are un-tappable because they are too small. One solution is of course to have the user zoom-in and out of the window. This is however a pain on old Android devices, because zooming is not smooth and in some cases, you do not have pinch-to-zoom.

We are currently investigating if we need to redirect some old Android devices to the iMode website, and if necessary, whether we can customize the font-size, etc. so that this site is usable with a touch interface.

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.

Rethinking URLs for social sharing optimization

As a scientific conference system, Ponzu requires multi-device support and internationalization (translation). Commonly, websites use different URLs for each of the devices they support, and also for different languages.

For example, a desktop page in Japanese might have the following URL,

`http://www.some.site/ja/about`

whereas the mobile version in English might have the following;

`http://mobile.some.site/en/about`

However, this scheme means that we have different URLs for the same content. Since Ponzu will support at least 3 devices and 2 languages, in total, we have 6 URLs for the same presentation. This becomes a problem when we use social sharing.

If for example, a user browses a conference system on his desktop machine and shares a link to a presentation on Twitter, that link will be a desktop URL. If another user does the same on his iPhone, then the like will be a smartphone URL. There will be two different URLs.

Now suppose we decide to put a “share” button on each presentation. The speech balloon on the button refers to the number of times the link has been shared on Twitter. If we have different URLs for each device/language combination, the count will only be for the current device/language combination of the user. It will not combine all the URLs. Hence, if we want the “share button” to reflect the real count, we have to use a single URL with device/language information residing in a cookie.

A cookie approach will be sufficient for regular websites. However, with Ponzu, we use a hash-based URL structure so that we can use the site offline. On the other hand, we use regular URLs for iMode feature phones and unsupported browsers. As far as I can think of, there is no way to unify regular URLs with hash-based URLs. We will have to have at least two URLs; a hash-based one and a regular one. Still, 2 is much better than 6.

What will smartphone & tablet adoption ultimately be?

When thinking about which devices to support on a conference program system, we have to understand what percentage of conference participants own smartphones or tablets. Furthermore, since planning of a conference will happen many months before the actual event, we need to predict nearly a year into the future.

There are some interesting trends here.

Smartphone adoption in Japan is fast but still around 40%

According to a survey from Impress R&D on November, 2012, the percentage of smartphone users in Japan is 39.9%. Usage skews towards people less than 40 years old, and adoption for those above 50 years is about 20%.

Adoption growth has been linear since September, 2010, and there are no signs of slowing down.

NewImage

NewImage

Compared to the US, adoption percentage is lagging. However, adoption speed is similar.

NewImage

From Asymco.

If linear growth continues, adoption in Japan will increase more than 15 percentage points in the course of 2013, bringing the total adoption to more than 55%.

Docomo BCN 2013 01 30 10 45
There are signs that smartphone adoption may be slowing down in Japan

BCN ranking lists mobile phones by sales data provided by a sample of retail outlets in Japan (which notably excludes the Apple Store and a large number of carrier stores). An interesting recent observation is that feature phones are ranking high in the list.

Of the 10 top-ranking phones provided by DoCoMo (the largest carrier in Japan with 50% subscriber share, but which doesn’t carry the iPhone), 4 were feature phones. The 3rd highest ranking phone was a feature phone. In November, 2012, the situation was even more severe with 6 out of 10 being feature phones, and the top ranking phone being a feature phone.

Another interesting survey suggests that 66.2% of people who purchased a new smartphone at the end of 2012 purchased an iPhone, and only 31.9% purchased Android. Given that DoCoMo retains 50% of subscribers but doesn’t carry the iPhone, this survey, if accurate, suggests that DoCoMo isn’t selling many Android phones but rather selling feature phones. We might be seeing smartphone growth slowing down in Japan with the slowdown being more pronounced for Android and less so for the iPhone.

Android share growth is slowing in the US

Asymco notes that Android growth is slowing down in the US (1, 2), whereas iPhone growth is not. It is possible that this situation is the same as in Japan.

NewImage

The discussion in the comments suggest that as the smartphone market matures, late adopters (who tend to be the more cautious customers) will gravitate to the iPhone, while many early adopters will convert to the iPhone due to better customer loyalty on the Apple side.

Final smartphone penetration in Japan depends on whether DoCoMo will carry the iPhone

If the discussion in Asymco is true and our assumption that a similar situation is occurring in Japan is also true, then we can conclude that DoCoMo customers will either convert to other iPhone-carrying networks, or revert to feature phones. Since DoCoMo has the best coverage of all networks and is the most established carrier, late adopter customers will tend to stick with this network. Hence, although there will be a significant exodus to other networks, the more pronounced result will be low smartphone purchases at DoCoMo, and hence low smartphone penetration in Japan as a whole.

In conclusion, my prediction is that Japanese smartphone adoption will start to slow down in 2013 mainly driven by slowing Android sales. The result is that adoption will be less that 50% at the end of 2013. If DoCoMo decides to carry the iPhone however, smartphone adoption will maintain linear growth or may be even exceed it. In this case, we might see adoption of 60% at year end.

In either case, the feature phone market in Japan will remain relevant. The Ponzu conference system needs to maintain a web site for feature phones at least for the next few years.

Thoughts about the future of viewing PC websites on mobile phones

While studying how iPhone and Android display PC websites on mobile phones (here and here) , I came to the conclusion that physical screen size doesn’t really matter that much; auto-resizing text based on complex software algorithms makes all the difference.

Since there is a large difference in how browsers auto-resize text, it would be unwise to rely on it for a conference system where mobile access is very important. Ideally, you should create mobile versions of all the relevant websites for the conference. If you do not have the resources for this, at least make sure that the websites look good on Android devices, because PC websites are more difficult to use on the default Android browsers. Checking with mobile Safari is insufficient because its software algorithms make up for your mistakes.

Looking into the future, FireFox and especially FireFox OS may change the situation. The current versions of FireFox on Android use auto-resizing very aggressively, and we can expect the low-end phones using FireFox OS (which will use small screens to cut costs) to do the same. These phones may make browsing PC websites on small screens quite bearable. 

If auto-resizing becomes commonplace and web designers can begin to rely on it, then the extra efforts to optimize websites for mobile will become less important. A single design will cover both PCs and smartphones.

Comparing PC website browsing on iPhone 5 and Galaxy Note 2: The iPhone 5 is actually better

In my previous post, I concluded that the Galaxy Nexus with a 4.65-inch screen did not provide a superior web browsing experience compared to the 4.0-inch iPhone 5. On the contrary, the iPhone 5 displayed larger fonts on the same pages, hence reading the content was more comfortable on despite a significantly smaller screen. This was largely due to automatic font-resizing on the iPhone’s Safari browser.

I also briefly mentioned the Galaxy Note 2, and suggested that even with its 5.5-inch display which is 38% larger in length, fonts on PC websites would not be displayed as large as the iPhone 5. Hence, the browsing experience might still be worse despite a much larger display.

I have now obtained some screenshots from the web (I myself do not own a Note 2) so we can compare with actual images.

Below I used Galaxy Note 2 screenshots from TechRadar. I took screenshots on my iPhone 5 from the same website, and adjusted the sizes so that they represent actual physical measurements (meaning that you can directly compare font sizes).

Showing the whole page

The screenshots below were from The Daily Mail website. When displaying the whole page, second level headers were barely legible on the iPhone 5’s retina display. Second level headers on the Galaxy Note 2 were also very small, so we expect them to be very difficult to read as well. Since in both devices, the only text that could comfortably be read was the top level headers, we think there is little difference here.

Galaxy Note 2 full 2013 01 25 19 48

Zooming up on text

The next screenshot is where we move to an article page and zoom in to the text. The navigation column on the right is moved out of the screen. This is the “reading” mode where readers will actually read the text of the article.

As we saw in the previous post, here again we see that the iPhone 5’s font size is actually larger than the Galaxy Note 2, despite the latter having a 38% larger screen. This is due to mobile Safari automatically resizing the text.

Adding the fact that the iPhone 5 has a 326ppi retina display compared to the 285ppi Galaxy Note 2, the readability of the larger text on the iPhone 5 is clearly superior to the Galaxy Note 2.

Galaxy Note 2 zoom in 2013 01 25 19 50

Conclusion

With actual screenshots from the Galaxy Note 2, we can again see that the iPhone 5 provides a superior web browsing experience.

This is pretty damning. As the TechRadar article stresses, browsing the web is THE strength of the Galaxy Note 2. It is where the huge screen makes its mark. We also know that browsing the Internet is the most popular smartphone/tablet activity. Unfortunately, the much smaller iPhone 5 beats the Note 2 in website readability with the advanced software in mobile Safari.

The Galaxy Note 2 is great for browsing if your benchmark is other Android phones. If you have a choice though, I recommend the iPhone.

Software, not the hardware, is what makes the difference.

Is a larger screen on smartphones beneficial for viewing PC websites?

In a previous post, I discussed design considerations to make “pinch to zoom” work well. This is very important when you want to show your PC website to smartphone users. I concluded that it is vitally important to keep the length of each row short, and that 50 letters per row is optimal.

In this post, I would like to investigate whether or not a larger screen like that on recent Android devices would help. Specifically, I would like to discuss whether the Galaxy Nexus with a 4.7 inch screen (W 2.28 x H 4.05 inches) provides a better viewing experience compared to the iPhone 5 with a 4.0 inch screen (W 1.96 x H 3.49 inches).

As described in more detail below, my conclusion is that due to software optimizations in mobile Safari, iPhone 5 (and to a lesser extent iPhone 4/4s) provide a better experience than the Galaxy Nexus. This is despite the Galaxy Nexus having a significantly larger display.

A similar conclusion was reached by Ben Bajarin of Tech.pinions in his blog post.

Safari auto-resizes text to make important stuff legible

In a “pinch to zoom” interface, it is vitally important that the user can recognize what part of the screen they should zoom into. This means that important headers and links should be large enough to be legible, even without zooming-in. We want to see if this is the case

In the following image, I have compared the nikkei.com front page on the iPhone 5 and Galaxy Nexus. The images are drawn to the same scale so that you can directly compare sizes.

As you can see, both smartphones display the headers of each article quite well (red arrows). These headers are both equally legible. The text is smaller on the iPhone and larger on the Galaxy Nexus, representative of the difference in screen width.

However when we look at the smaller headers/links which I highlighted with yellow arrows, the situation is reversed. On the iPhone 5, mobile Safari automatically enlarged the text to make them legible. However, Chrome on the Galaxy Nexus rendered them in propotion to the rest of the page and they are barely readable.

When you look at the text body, you realize that the lines are shorter on the iPhone 5. This is because mobile Safari again is automatically enlarging the font-size so that it would be legible. As a result, the body text is larger on mobile Safari compared to the Galaxy Nexus.

iPhone 5 does not increase text size universally. For articles that are not accompanied by large header text, iPhone 5 tends to treat them as unimportant and does not increase text size.

The end result is that despite the iPhone 5 having a significantly narrower screen, the text is actually larger and easier to read than on the Galaxy Nexus.

Nikkei com 2013 01 25 10 49

We can also see this in action on www.asahi.com. The iPhone 5 is significantly easier to read.

Www asahi com 2013 01 25 10 50

Font size in pinch-to-zoom view is larger on Safari

As a side-effect of font-resizing, the text is much larger and easier to read after the user has “pinch-to-zoom”ed. The following screen shots are on www.asahi.com after zooming in to the top news section. As a side note, zooming was easier on the iPhone 5 because mobile Safari has better auto-zoom level detection. Hence a double-tap takes you to the zoom level on the screenshot, whereas a double-tap on Chrome does not. With Chrome we had to do an actual “pinch-to-zoom” gesture, which is more cumbersome, to get to the zoom level on the screenshot.

As you can see, font sizes are significantly larger on the iPhone 5. This is due to the rows having less characters per line as a side-effect of the auto-text resizing I described in the previous section. The font-size on Chrome, although legible, is not ideal. Any website that has been optimized for mobile would use a much larger font.

Asahi com pinch to zoom 2013 01 25 10 50

This situation is very serious for text-heavy pages. As you can see in the following screenshots, the iPhone 5 screen is much much easier to read.

Asahi com 2013 01 25 11 33

On mobile optimized websites neither has an advantage

Mobile optimized websites are designed for narrow screens and assume that the user will scroll down to read more. Font sizes will be more-or-less the same regardless of screen size, hence the difference is only in how much a user has to scroll. Given the easiness of scrolling on smartphones, this is generally not much of an issue.

In the next screenshot from IT Media mobile, you can see that the Galaxy Nexus shows a bit more information at the bottom of the screen. Still, not enough is visible so even Nexus users will scroll down.

The font sizes are almost identical and easily legible.

ITMedia mobile 2013 01 25 10 50

Firefox

Although Firefox is not the default browser on Android and we won’t use it to compare with the iPhone, Firefox has very interesting text-autoresizing and is worth mentioning here.

Simply put, Firefox is extremely aggressive with text-autoresizing. The resized text is very large and easily readable. I expect many people to find this very nice. 

The Mozilla organization is preparing FireFox OS for low-end smartphones. FireFox OS will probably use the same aggressive text-autoresizing. This is ideal for low-end smartphones which are likely to have smaller screens than high-end Android phones. Text will be easily legible despite small screens, and is likely to be much better than text on high-end Androids with large screens running Chrome.

The algorithm for resizing text on FireFox is described here.

Chrome Firefox headlines 2013 01 25 17 14

Chrome Firefox text 2013 01 25 17 15

Conclusion

Despite the Galaxy Nexus having a significantly larger screen than the iPhone 5 (4.6 inches vs 4.0 inches), viewing PC websites is actually much more comfortable on the iPhone. This is due to important software optimizations in mobile Safari.

If you are designing a PC website and you want it to also be usable on iPhones, you can be more relaxed about the recommendations that I gave on my previous post. You don’t have to be too picky about the maximum characters per line, because mobile Safari will do the work for you. However, if you want to make it usable on Android, then the burden is on you. The designer has to make sure that the line length is short enough to be easily legible on Android smartphones, and large screen sizes don’t help much.

On the other hand, if you are creating a mobile website, as long as you are adhering to the general guidelines for a mobile site, usability will be basically the same on both iPhones and large-screen Android phones. Large screens do not provide an advantage. Likewise, Android’s lack of optimization is no longer a disadvantage.

How this effects screen size trends

A recent trend in smartphones is the rise of the “phablet” category, namely the popularity of the Galaxy Note which is a smartphone with a 5.5 inch display. This screen provides 18% more width than the Galaxy Nexus.

As discussed above, screen size alone is not important. When we compare the Galaxy Note (simulated screenshot below) to the iPhone 5 for the body text, we actually see that the iPhone 5 still has larger text and better readability. In fact, in order to surpass the iPhone 5 in font size when reading PC websites, Android devices need to get up to 7-inches.

I suspect that the rise of “phablets” is a result of the lack of software optimization in Android browsers. The iPhone and mobile Safari can provide readability that surpasses “phablets” on much smaller screens.

Simulated galaxy note 2013 01 25 12 21

The larger view

Incremental feature improvements provide actual benefits only when the previous technology was insufficient. Large screens provide benefits to smartphone applications if and only if the current screen size is restricting usability, and the improvements are significant enough to overcome the limitation.

What this means is that applications that have been optimized for small smartphone screens will not receive significant benefits from an incrementally larger screen. This is the situation that we saw with mobile-optimized websites. A larger screen allows you to see a few more lines. However, since scrolling is so easy on smartphones, the benefits to usability are limited.

On the other hand, viewing PC websites that have not been optimized for mobile are a great opportunity to show off the benefits of a larger screen. Viewing PC websites is by far the most irritating activity on smartphones because the text is often too small to be legible, and scrolling horizontally to read as single line of text is truly annoying. It is these times when we wish we had a larger screen or a tablet.

Therefore, the benefits of a larger screen on smartphones should mainly be measured by how easy it is to browse PC websites. However, due to lack of text-resizing, large-screen Android smartphones actually provide a worse browsing experience compared to the iPhone. Without text-resizing, a screen size approaching 7-inches is required to display websites with the same font-size as the iPhone.

The situation is different with tablets. Because tablets like the iPad have fundamentally larger screens compared to smartphones, it is possible to provide a different user interface. Optimized applications have multi-paneled navigation systems, for example. Therefore with tablets, the issue is whether the screen size is large enough to house the different user interface or not.

In the eyes of most web designers, tablets at or below 7-inches do not have sufficient screen real-estate to accommodate multi-paneled navigation, whereas the iPad mini does. Many web designers give 7-inch tablets the smartphone version in their responsive designs. On the other hand, the iPad mini will get the same multi-paneled navigation as the iPad. In a nutshell, anything below 7-inches is a smartphone, and anything above 7.9-inches is a full tablet.

In conclusion;

  1. For optimized websites and applications, anything below 7-inches is basically the same. You get the smartphone experience. You only get a significantly better experience if you go to or above 7.9-inches (the iPad mini).
  2. For non-optimized websites, incremental increases in screen size can potentially benefit the user experience. However, the lack of automated resizing in Android browsers results in a worse experience than mobile Safari, despite a significant advantage in screen size.

Can pinch-zoom substitute for smartphone-optimized/tablet-optimized web sites?

NYTimes 4All smartphone and tablet browsers allow users to use the pinch-zoom gesture to zoom in on web pages. This allows web pages designed for PCs to be fully usable on small-screen devices since this gesture is extremely intuitive and fluid. Due to the ubiquity and simplicity of this gesture, it is almost as second-nature as scrolling.

However, websites differ in their usability with pinch-zoom. News sites which list articles in blocks (i.e. The New York Times) are very suited to pinch-zoom. You can zoom in to magnify the area that I put in a red box. When zoomed in the number of letters per row is about 30, which means that the letters will be quite big and easily legible, even on a smartphone screen.

 

MacsurferOn the other hand, web sites that simply use a list for headlines are not suited to pinch-zoom. (i.e. MacSurfer’s Headline News). Zooming in on the headlines would result in the red box. However even with zooming, the number of letters per row is more than 80. The fonts are too small to read easily on a smartphone, although tablets will be OK.

 

For pinch-zoom to work well on smartphones, less than 50 letters per line is optimal.

Iphone emailIn Apple’s mail app on the iPhone, a font size that give 40 letters per line is used for simple text messages. In Mobile Safari, the default font size is set to 16px which allows for about 50 letters per line when the viewport tag is set to device-width. The minimum font-size that one can read comfortably differs between individuals, we can safely assume that a size that gives 40-50 letters per line on an iPhone will be comfortably legible for most users.

Therefore for pinch-zoom to work well on smartphones, the number of letters per line in the zoomed box should be less than 50. If we cannot satisfy this, then pinch-zoom will not provide a good enough experience.

Ponzu

The MBSJ2012 website did not use a multicolumn layout, nor did it use a newspaper-like layout. Hence, there were very few pages where pinch-zoom would make sense.

However, it might be interesting to investigate designs with multiple columns or a newspaper-like layout. This could be especially helpful when we want to highlight exhibition activities. These might need pinch-zoom.