Monthly Archives: January 2013

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.

Using multi-columns for text (CSS columns)

“Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal. For multiple column work, a better average is 40 to 50 characters.”

from The Elements of Typographic Style Applied to the Web

In MBSJ2012, we used the CSS columns feature to display presentation abstracts in multiple columns. When the browser window width was 768px as on an iPad, the average number of 16px Arial font characters per line fit the multiple column recommendation perfectly.

On smartphones, we used single columns. The size again matched the recommendation on the low-end for the iPhone, and on the middle end for larger Android smartphones.

Even on 7-inch tablets like the Nexus 7, the number of characters barely missed the high end of the recommendation and was pretty close to being satisfactory.

Smartphone websites on 7-inch tablets aren’t too bad

As I wrote in my previous article [Supporting Android Tablets](https://code.castle104.com/?p=171), we have decided to direct all Android tablet users to the smartphone website. The reasons are both technical and design-based.

The problems with using a smartphone device on a 7-inch tablet were described by Apple’s Phil Schiller on the iPad mini introduction event (video below). Phil shows how bad native applications on the Nexus 7 are, mainly because they simply stretch the smartphone application. The result is that the screens are filled with empty white space with very little meaningful content.

However, when you test the MBSJ2012 website on a 7-inch tablet with the smartphone version being shown, there doesn’t seem to be any problem. The design looks natural, and works well.

We think that this is because conference programs are very text heavy. You don’t have many lists that have only a brief heading. On the contrary, we have lists of presentations which have the title, authors and affiliations; that’s a lot of text. It’s even enough text to comfortably fill up a 7-inch tablet screen. Actually, 7-inch tablets don’t really have too much space. 7-inch tablet browsers default to only 37 “m” characters per line, meaning that if you have more than that, you’re going to reach the end of the line. Conference programs won’t leave much white space for these devices.

Another factor is that the Android tablet native applications seem to have set the font size too small. Whereas Android browsers default to a sensible text size (which is very similar to the default text size on the iPhone and iPad mini), native applications seem to have an issue setting the font size correctly.

In conclusion, at least for 7-inch Android tablets, directing them to the smartphone website seems to be a good decision.

Supporting Android Tablets

In MBSJ2012, we directed all Android devices to the smartphone website, regardless of actual screen size. The rationale was as follows;

  1. The number of 10-inch Android tablets would probably be very low.
  2. 7-inch Android tablets would probably have a hard time displaying the PC website.

In this article, I would like to explore the possibility of doing something more optimal for Android tablets and come to a conclusion.

What do the device manufacturers recommend

Google issued a document on the Android developers’ website regarding the User-Agent string on Chrome for Android. Their recommendation is;

If you are parsing user agent strings using regular expressions, the following can be used to check against Chrome for Android phones and Android tablets:

  • Phone pattern: ‘Android’ + ‘Chrome/[.0-9]* Mobile’
  • Tablet pattern: ‘Android’ + ‘Chrome/[.0-9]* (?!Mobile)’

So basically, if we use the word Mobile, then it’s a smartphone; if we don’t use the word Mobile, then it’s a tablet.

Now let’s see how the device manufacturers set the user agent strings for their default browsers (it may or may not be Chrome, but we’ll see how far the Mobile detection scheme works.

ZYTRAX.COM: Handset Detection.com

Galaxy SII LTE: Mozilla/5.0 (Linux; U; Android 4.0.4; en-ca; SGH-I757M Build/IMM76D) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

Galaxy Note Android 2.3: Mozilla/5.0 (Linux; U; Android 2.3.5; en-gb; GT-I9220 Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

Galaxy Tab 10.1: Mozilla/5.0 (Linux; U; Android 3.0.1; de-de; GT-P7100 Build/HRI83) AppleWebKit/534.13 (KHTML, like Gecko) Version/4.0 MobileSafari/534.13

Galaxy Nexus: Mozilla/5.0 (Linux; U; Android 4.0.2; en-us; Galaxy Nexus Build/ICL53F) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

Google Nexus 7 Android browser: Mozilla/5.0 (Linux; U; Android 4.2; en-us; Nexus 7 Build/JOP40C) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

Google Nexus 7 Android browser: Mozilla/5.0 (Linux; U; Android 4.2; en-us; Nexus 7 Build/JOP40C) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Safari/534.30

Amazon Kindle Fire: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-us; Silk/1.1.0-84) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16 Silk-Accelerated=true

Amazon Kindle Fire: Mozilla/5.0 (Linux; U; Android 4.0.3; fr-fr; Amazon Kindle Fire Build/MR1) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

Android browsers can switch their user agent strings from Mobile to desktop (tablet) type, which complicates things.

What we can see here is;

  1. Detecting Mobile is generally sufficient to detect smartphones.
  2. Detecting Mobile in tablets allows users to switch between smartphone and desktop layouts, although most users probably wouldn’t notice that setting.
  3. The Kindle Fire Silk browser mostly uses Mobile whereas the Nexus 7 does not.
  4. The 7-inch tablet category is confusing, and manufacturers seem to feel the same.
  5. The user-agent string treats both 7-inch and 10-inch tablets the same. You cannot distinguish between them.

viewport device-width issues

In Ponzu, we currently use viewport device-width. viewport device-width is a meta tag that Apple introduced with the iPhone that allows fluid websites to adjust best to the screen of the current device.

Without viewport device-width, when an iOS device encountered a fluid website (non-fixed width), it would set the width of the current screen to 980px (body{width:100%} would be the same as body{width:980px}). The display would be zoomed out because neither an iPhone nor an iPad has 980px width. With viewport device-width, the it would be body{width:320px} on the iPhone and body{width:768px} on the iPad, which ensures that the default 16px text size would be legible without zooming.

Therefore, to use the Ponzu same desktop web design on both iPad and PCs, we need to design our fluid layout so that it works with width: 768px. This is possible because 768px, although pretty narrow compared to current day standards, is still wide enough. In 2007, it was still considered a good idea to design web sites for 800px width. Although screens have gotten wider since, 800px is still very workable. 768px isn’t significantly different from 800px.

However, with Nexus 7 and Kindle Fire tablets, viewport device-width is set to 600px. Although this ensures that text is easy to read, it makes it much more difficult to share your website with a desktop design. If we were to use a fluid layout that works well at width:600px, then when people view that same website on a PC with a 1000px width browser window, there will be too much whitespace as it is streched. A single design for width:600px and width:1000px simply isn’t realistic.

Is responsive web a solution?

Responsive design is mainly about using CSS to flexibly adjust to screen sizes. I generally think that responsive design is a bad idea and many of my feelings are shown in this blog article, and this.

In Ponzu, our stance is that creating separate websites is actually easier than complex responsive design techniques. The end result is, of course, better. However, we can’t create too many separate sites, and creating a separate site for 7-inch tablets is out of the question. We have to either fit 7-inch tablets into the smartphone site or the PC site.

Responsive design at or below 600px width

Just to see if responsive design for a Nexus 7 or Kindle Fire is worth it, we looked at responsive design websites at or around 600px. (from 25 Beautiful Responsive Web Design Examples for Inspiration, 11 gorgeous examples of responsive design, Media Queries )

Maryland Craft Beer Festival

Below 700px width, it becomes a single 300px column design.

Daniel Vane

Changes to iPad-optimized at 768px. Images simply shrink until 500px. Single column at 460px.

Formfett

Change to 7-inch tablet version at 670px, which goes down to smartphones.

Humaan

Changes to iPad-optimized at 780px. Single column at 760px down to smartphones.

Andersson-Wise Architects

Changes to iPad-optimized at 780px. Single column at 600px.

Boston Globe

PC is 3-column, iPad is 2-column, 1-column below 640px.

In almost all of the sites that we examined, responsive designs targeted for 7-inch tablets were identical to the smartphone versions (except in image sizes). No layout changes were made specifically for 7-inch tablets and they all adopted the smartphone layout, not the PC layout. On the other hand, iPad layouts were consistently different from smartphone ones. We can safely conclude that even designers versed in responsive techniques simply use the same smartphone layout for 7-inch tablets. To answer the question at the beginning of this section, they don’t think that responsive design for 7-inch tablets is worth it.

As an outlier, FoodSense provides optimized designs for 7-inches.

Our solution

We think that the rational solution is to direct Android 7-inch tablets to the smartphone website. This might not be an ideal user experience for these users, but we think that this is a compromise that has to be made. Redesigning the PC site to accommodate 600px width screens would result in a degradation of user interface for PC users, which constitute 100% of our users. Responsive web techniques are unlikely to provide an effective solution. Since 7-inch tablet users are less than 10% of our users (excluding iPad-mini), and it is absurd to prioritize them above our PC users.

However, Android 7-inch tablets have a user-agent string that is indistinguishable from 10-inch tablets. If we simply use user-agent string detection, then 10-inch tablets will also be directed to the smartphone site. We recognize that this is hardly optimal and that we can technically overcome this using Javascript, cookies, etc. However, the extremely small market share of 10-inch Android tablets means that the technical effort might not be worth it.

Conclusion

Our conclusion is that we should direct all Android devices to the smartphone website, regardless of device screen size. This is the same as our original decision for MBSJ2012. We should also be careful about the Kindle Fire because it does not always report that it is in fact Android.

The essence of our decision is that the Nexus 7 and Kindle Fire tablets cannot accommodate our PC website due to width limitations. Also, redesigning our PC website to fit inside the 600px width for these 7-inch tablets is not worth the effort, and may not be realistic anyway.

As for the iPad mini, it fits 768px width websites, but the font size will be 19% smaller. Since there is no way to distinguish an iPad mini from a regular iPad, the solution is to make sure that regular text is large enough, larger than 16px (the default iPad browser text size). If you are going to have significantly smaller text, make sure that it’s zoomable (which is often not the case when you use mobile javascript frameworks).

Twitter-like feed for the exhibition

In the MBSJ2012, we used #mbsj2012expo as the official Twitter hashtag for exhibition related information. We linked to this hashtag from Ponzu, the online program system. The JBS2012 had a similar system, which used the iOS, Android application to display a feed of recent updates from exhibitors.

Neither of these turned out to be an attractive news resource for the participants. As seen in the screenshots below, the news on both of these feeds was dominated by a small number of exhibitors. The vast majority of them did not participate although the #mbsj2012expo Twitter hashtag fared much better than the JBS2012 system, which had only two exhibitors posting stuff.

This means that we need to do something more, or something different.

One large obstacle is that the number of exhibitors that regularly reach out via social networks is still very small, and even smaller in Japan (Many suppliers in the USA use social networks for marketing. However, success has been sporadic. Not many suppliers in Japan use social networks). Therefore, most likely, exhibitors haven’t decided who should be responsible for posting updates, and what content they should be posting. We could try to support them by educating with various materials, but still, it would be difficult to provide a good incentive to do it, especially since the JBS2012 system failed so badly.

We feel that at least for the next couple of years, it will be difficult to encourage exhibitors to take an active role in posting feeds. Social media based advertising is still too new. Instead, we should pursue more passive ideas which do not require any new action from the exhibitors’ part.

A brief list of some of the ideas;

  1. Integrate the exhibitor booth descriptions into the program search results. For example, anybody searching for presentations on “next generation sequencing” will also be shown a list of exhibitors with products.
  2. Add booths to the “like” system and actively notify the exhibitors who “liked” their booth.
  3. Have somebody in the organizing staff go around each booth, posting photos and updates to the website.

Basically, we shouldn’t rely on the exhibitors to do something special. IT alone will not solve the problem. We have take the first action on the ground.

#mbsj2012

スクリーンショット 2013 01 17 16 29

JBS2012 iOS application exhibitor feed

IMG 2049

Possibilities of the poster map system

In MBSJ2012, we introduced a “poster map” function for the very first time in the world. This poster map function highlights which posters you “liked” or which posters you added to “my schedule”. This enables participants to easily find which posters they need to visit.

The poster map is drawn using a simple combination of HTML & CSS. All of the poster rows are simply positioned absolutely and placed on top of a background image of the poster hall. The only difficult part is calculating the location of each poster.

In the future, we could easily extend the poster map concept to the exhibition. Participants could “like” booths, and efficiently visit the ones that they are interested in.