Category Archives: Platform-support

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

Don’t let technology divide people

Our concept for the IT-plan was to connect scientists through Information Technology. However, as the often used word “digital divide” signifies, IT can also separate people.

There are limits to what technology can do to prevent a “digital divide”. Still, we thought that it was our duty to do what we can to support people on the other side of the “divide” so that they would be encouraged to come to the IT-rich side.

What we did

  1. We supported as many devices as possible.
  2. We used IT to provide a better reading experience even for the PDFs.

Our recommendations

  1. Do as much as possible to support the late majority.
  2. Even if you can’t support them fully, try to make life better for even the laggards.

Optimizing total development effort with Ponzu

In Ponzu, our idea is to support all the digital communication devices that a significant number of participants are likely to own. This means that we will support 1) PCs, 2) smartphones, 3) feature phones, 4) tablets, 5) PDFs. That’s 5 different formats.

If we were to support smartphones and tablets through native applications rather than through the web, that would mean that we would have to add at least two more platforms, making the total number of formats into 7! Clearly, that is too much.

Furthermore, unlike normal IT development which is notorious for frequently missing deadlines, IT development for conferences must be on time. The time window is also very narrow since a large portion of the development cannot happen until the abstracts have been submitted by the users and the organizers have sifted through them.

Hence reducing total development effort is a very important part of Ponzu.

In the following, we will briefly describe what multi-device development is like in Ponzu, and how we manage to keep total development effort at manageable levels.

MVC architecture with Ruby-on-Rails

The MVC architecture for building web applications separates the Model (business logic) from the View (presentation). The effect is that you can use the exact same code for the Model, regardless of which device you are targeting. You will have to write View code for each device though.

This is a huge advantage for multi-device support. When we add another device, we don’t have to touch the Models. We simply modify the Controller and write a new View.

The most advanced MVC framework for web development is Ruby-on-Rails. We many of Ruby/Rails features to make multi-device support easier.

Writing new Views

Even though the overall page design is different between devices, a lot of the parts are very similar.

For example, code to generate the lists of authors and institutes in HTML is basically the same. We extract these into view helpers and use them in both for the PC website, the smartphone website and the feature phone website.

Code sharing can be done at a higher level as well. If you compare iPhone apps and iPad apps, you often notice that the iPad app is actually adding navigational elements around an iPhone app. In these cases, the iPad apps includes the iPhone app view as a fragment. Rails lets us do this easily with view partials.

Although still a work in progress, our goal is to share as much code between the views of our supported devices, while still providing a non-compromised, optimized design. Ruby-on-Rails helps us a lot here.

Modifying the Controllers

During the mid-phases of developing the MBSJ2012 system, we separated the controllers for all our devices. We had a controller for the PC website, smartphones and for feature phones.

Our concern was that the pages we wanted to provide might differ significantly between devices and we wanted to maintain flexibility. For example, PC websites typically pack a lot of information into a single page; the main content, navigational elements, related links, etc. These would be unnecessary for smartphone websites because there wouldn’t be enough space to display these.

However, rewriting both the Controller and the View for each supported device ended up being very frustrating. This is because while there are differences between devices in how we want to display the information, there was actually a significant amount of stuff that was the same. Because we had separate Controllers and therefore a different folder to contain the Views, comparing the code between devices was very time consuming and it was difficult to analyze to what extend we could DRY up the code. We often did copy & paste, simply because it was too much work to figure out the difference. We desperately needed a way to accommodate multiple devices into a single controller.

Our solution was to generate supplementary and superficial information in the View and not in the Controller. A common idea in MVC is to not let the View directly interact with the Model. That is the idea behind templating languages like Smarty (PHP). Our solution was to ignore this. In Ponzu, the View itself frequently has code that accesses the Model. This enables us to keep the Controller as device-independent as possible. As a side effect, it also makes fragment-caching much easier.

With this solution, we were able to unify the controllers for all our devices. The controllers manage interaction with the main Model for that page, authentication, selection of the appropriate View template for each device, expiration management of local cache, etc. They aren’t responsible for interacting with all the models required to draw a page because that depends on the device.

When we need to add support for another device, we simply add some code to specify which view template it will use. (i.e. Where the PC website uses the “index.html.erb” template, smartphones will typically access “index.s.html.erb” and feature phones will access “index.g.html.erb”. Sometimes though, smartphones will share “index.html.erb” with the PC site.) Other stuff is usually kept the same.

Sharing Kamishibai

Kamishibai is the Javascript framework for providing smooth Ajax-based page transitions and managing the local cache of pages. We wrote Kamishibai in raw Javascript so that we could keep the total Javascript size very small, and therefore usable on mobile devices. As a result, Ponzu shares most of the Javascript between the PC website and smartphone version.

Only when we need to use advanced editing techniques will we call in libraries like jQuery and jQuery UI.

Thoughts about Javascript MVC

Javascript MVC, although gaining in popularity, is not a good fit for Ponzu. It requires that we move Model and Controller logic to the client, meaning that we will have device dependent Models and Controllers. It will make multi-device support significantly harder. We have other reasons why we don’t use Javascript MVC, but this is the largest.

Conclusion

Ponzu is architected from very fundamental levels to optimize total development effort for multiple devices. The pillars for this are;

  1. Web-based with a central server holding all information. Clients are merely display terminals (with caching abilities).
  2. Exploit Ruby-on-Rails for it’s DRY capabilities.
  3. Don’t use overweight Javascript libraries (jQuery).

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.