Tag Archives: Tablet

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).

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.