Category Archives: Design

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

A design that respects the authors work

The previous designs for conference programs showed no respect for the hard work of the authors. Abstracts were treated simply as entries in a database. We strongly object to this and propose that conference programs should be designed with the same care as printed academic journals.

Example of bad design

  • Abstracts are treated as database fields.
  • All the font sizes and styles are the same. Important information (titles, number) should have a larger font size, while affiliations should be smaller (as is typical in a printed journal).
  • As discussed in “Multi-lingual support”, displaying both English and Japanese next to each other makes it harder for readers to quickly read the content and should be avoided.

2011 presentation

Ponzu design

Below is the design for MBSJ2012.

  • The design is based on top printed journals.
  • Font sizes, styles and colors are used to make each element easily identifiable.
  • Important information (title, number) is in larger font sizes.
  • A two column layout is used so that readers do not have to move their eyeballs long distances.

MBSJ2012 design 2

Conclusion

Historically very little effort was put in the design of conference programs. It is time for this to change.

The sorry state of PDFs and how we aim to change that

Up till MBSJ2011, the abstracts were also provided as a PDF file. However, the implementation was terrible. The figure below illustrates what was wrong with the PDF.

MBSJ2011 pdf

The reasons for the issues in the MBSJ2011 PDF are probably not simple and I have no reason to doubt that the programmers put a lot of effort into the system that automatically churned out these files. There is however no doubt that one should try to do better.

4 presentations per page is difficult. 2 presentations per page should be OK.

The MBSJ2011 PDF had 4 presentations per page, probably as a remnant of the days when all abstracts were actually printed onto paper. I have heard that there was even a time that 6 presentations were squashed onto a single page. However, 4 presentations per page is very close to or even exceeds the limits. In the publishing industry, 7 points is the smallest font size that is acceptable. The MBSj2011 format uses 6 points (and sometimes 4).

Considering that most people would only want a few tens of presentations at most, we thought that it is not necessary anymore to squeeze 4 presentations into a page; 2 presentations per page should be sufficient. This enabled us to use 10 points for the main font.

Make it easy to print out the presentations that the user wants

Users will only want to print out a small number of presentations. We have to make it easy for them to do this. At MBSJ2012, we provided a separate PDF file for each session so that participants could print out abstracts for the ones that they were attending.

MBSJ2011 did not have this feature, but enabled users to print only those that they had entered into “My Schedule”. This is a feature that MBSJ2012 did not have, and we are thinking about implementing it in the future.