Considerations for Mobile Design (Part 2): Dimensions

In part two of this series, David helps readers adapt their design regimes to the (typically) small screens of mobile devices. Using responsive design, our experiences adapt to a variety of conditions.

This article is a part of a series:

  1. Part 1: Speed
  2. Part 2: Dimensions
  3. Part 3: Behavior
Considerations for Mobile Design: Dimensions

How are our layouts affected by the (usually) small screen sizes of mobile devices? How do we serve mobile layouts to specific devices?

One of the first choices a designer makes when creating a website is determining its appropriate dimensions. At a time when desktop resolutions range anywhere from 1024x768px to 2560x1600px, designers are well accustomed to designing for the lowest common denominator. It’s not exactly good practice to create a layout at 1200px wide when 20% of your users are browsing on a 1024×768 resolution.

In the desktop world, the rate at which this minimum acceptable resolution changes is relatively slow. In one way, this is quite useful for web designers. If users are slow to upgrade their equipment, then our designs don’t have to struggle to keep up with them. Based on statistics from w3schools.com, beginning in the year 2000, it took 9 years for less than 10% of their viewers to be browsing at 800x600px. Similar statistics from w3counter.com show that between May of 2007 and January of 2011, the number of users browsing at 1024x768px has only dropped from 50.97% to 20.59%. Despite a 30% drop, it is still the most popular resolution based on their statistics.

Average dispaly width on w3schools.com over 10 year span.

While neither of these two polls are conclusive (they don’t measure an actual average of all internet users), they do effectively demonstrate how slow users are to adopt higher screen resolutions. This slow change has allowed for entire frameworks to be built for creating layouts based on a common low resolution.

Of course, fluid layouts have allowed designers to serve fine-tuned browsing experiences at different resolutions. When designing at percentages instead of pixels, it’s possible to make more use of physical screen space depending on resolution. A site with a max width of 90% will make use of 21.6 inches of a 24 inch monitor, while a fixed layout at 960px might only make use of 10 inches of the monitor. Fluid layouts can have drawbacks though (Does anyone else have trouble reading Wikipedia on a 1920×1200 display?). Even in using fluid layouts, there are limitations we have to consider such as the ideal number of words per line.

But what about mobile design?

Saying that resolutions and display dimensions change rapidly in the mobile device market would be an understatement. The lifespan of mobile devices tends to be much shorter than that of a desktop (for instance, the average life of a cell phone tends to be around 18 months according to the United States Environment Protection Agency). Shorter device life spans in addition to constant new releases of mobile devices equate to an always changing landscape of popular resolution choices.

While this list won’t likely be relevant for very long, here is a list of popular resolutions on mobile devices as of February 2011:

Resolution Devices
320×240
  • Blackberry Devices: Curve 8530, Pearl Flip
  • Android Devices: Motorola Charm, Sony Ericsson Xperia X10 Mini, others
  • Symbian OS Devices: Nokia E63, others
320×480
  • Apple OS Devices: iPhone, iPod
  • Android devices: HTC Dream, HTC Hero, Droid Pro, i7500 Galaxy, Samsung Moment, others…
480×360 Blackberry Devices: Torch, Storm, Bold
360×640 Symbian OS Devices: Nokia N8, Nokia C6-01, others
480×800
  • Android Devices: Liquid A1, HTC Desire, Nexus One, i9000 Galaxy S, others
  • Maemo (Linux) Devices: Nokia 900, others
  • Windows Mobile 6 Devices: Sharp S01SH
  • Windows 7 Phone Devices Venue Pro, Samsung Omnia 7, HTC 7 Pro, others
768×1024 iPad
640×960 iPhone 4
1280×800
  • Android Devices: Motorola Xoom, Samsung Galaxy Tab 10.1
  • Windows OS Devices: Asus Eee Pad EP121
  • Apple OS Devices: Axiotron Modbook

Please note that this is a very limited list, and is by no means complete. What is important to take from this data is that a wide range of screen resolutions are out there, and new devices are introduced constantly.

This wide variety in display size makes it difficult to decide how to choose an appropriate layout size for mobile devices. Should we target the lowest common resolution in handheld devices like we do on desktops? How does that scale onto newer tablets that offer 2-3x the resolution of a 320x240px smartphone display?

One possible solution is to create fluid layouts for mobile devices. Unlike desktop displays where building layouts that are too wide is a concern, handheld devices read much like a book or magazine. Full width layouts have worked for centuries for magazines and books—it seems likely that they should also work on a new generation of mobile devices.

Another possible solution is to create layouts for specific devices, and collections of devices. What does this mean? Instead of creating a one-size-fits-all layout, create a layout that changes depending on the current resolution and orientation of a device.

In the past, this was easier said than done. The only effective way to deliver a resolution-specific experience to a mobile device was either with javascript, or by detecting the user agent.

There was one other way to target handheld devices, but its implementation was a bit spotty across devices. You see, cascading stylesheets have the ability to target specific media types like screen, print, and even handheld. However, mobile browsers have implemented this feature is a variety of ways. Some mobile browsers will only load stylesheets targetting handheld media. Other mobile browsers will ignore handheld targeted stylesheets, and only read screen media stylesheets.

A big reason for the different implementation of this feature in mobile browsers is the “One Web” approach to web design:

One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. The context of mobile use, device capability variations, bandwidth issues, and mobile network capabilities all affect the representation. Furthermore, some services and information are more suitable for and targeted at particular user contexts…

Devices like the iPhone (and others) have largely ignored handheld media rules, because the creators felt that their device was capable of sufficiently displaying websites built for desktops. This essentially made the handheld media type useless for building specific layouts for many mobile devices.

CSS3 Media queries

With the introduction of CSS3 Media queries, it is possible to target devices through many other variables including device width, device orientation, and aspect ratio. Using Media queries, it’s possible to load specific styles on specific devices (or collections of devices). This is what Ethan Marcotte refers to as responsive web design.

Using CSS Media queries is simple enough. A standard implementation might look something like this:

      <!-- All common styles -->
      <link rel="stylesheet" href="common.css" type="text/css" 
      	media="screen" />
      
      <!-- Devices between 480-1024px -->
      <link rel="stylesheet" href="styles_max_1024.css" type="text/css" 
      	media="only screen and (min-width:481px) and (max-width:1024px)" />
      
      <!-- Devices below 480px -->
      <link rel="stylesheet" href="styles_max_480.css" type="text/css" 
      	media="only screen and (max-width:480px)" />
      

The above code would load 3 stylesheets: styles for all devices, styles for devices in the 481-1024px range, and styles for resolutions 480px and below.

A drawback to this implementation is that 3 stylesheets means 3 separate http requests. To improve the speed at which our sites load, we want as few http requests as possible. This is especially important on mobile devices where download speeds and latency are usually worse than on desktops (see Considerations for Mobile Design (Part 1): Speed).

A different way to implement this same set of Media queries would be to use them directly in a single stylesheet. This could look something like this:

      /* Common CSS Goes Here */
      
      /* Devices between 480-1024px */
      @media screen and (min-width:481px) and (max-width:1024px) {
      	/* styles go here */
      }
      
      /* Devices 480px & below */
      @media screen and (max-width:480px) {
      	/* styles go here */
      }
      

Device-specific styles

If it’s important to deliver a very specific design to a very specific device (ie: a web application built specifically for the iPad), you can use Media queries to deliver styles to exact resolutions:

      <!-- iPad specific styles -->
      <link rel="stylesheet" href="iPad.css" type="text/css" media="only screen and (max-device-width:1024px) and (min-device-width:768px)" />
      

Orientation-specific styles

If the experience would benefit from different styles depending on a device’s current orientation, there is a way to handle that as well:

      <!-- Orientation styles for devices w/ max width of 1024px  -->
      <link rel="stylesheet" href="portrait.css" type="text/css" 
      	media="only screen and (max-device-width:1024px) and (orientation:portrait)" />
        
      <link rel="stylesheet" href="landscape.css" type="text/css" 
      	media="only screen and (max-device-width:1024px) and (orientation:landscape)" />
      

Unless it’s absolutely essential to the experience, the contents of a page shouldn’t change depending on a device’s current orientation. The actual dimensions of objects may change to better suit the reader, but removing objects from a page or inserting new objects will only confuse a user.

Browser-specific styles

Like desktop browsers, mobile browsers don’t all render code the same way. Making browser-specific adjustments to mobile websites can be a bit difficult. Gecko, Opera, and Webkit browsers can all be targeted specifically with some pretty ugly hacks. Luckily, up-to-date versions of these browsers typically do a good job of rendering standards-compliant code.

Internet Explorer Mobile has made huge strides in rendering code, but if you run into problems, there is a way to target IE Mobile in Windows Phone 7:

      <!--[if IEMobile]> 
      	<link rel="stylesheet" href="ie_mobile.css" type="text/css" media="screen" />
      <![endif]—> 
      

While some developers loathe conditional comments, they have one beneficial attribute in a mobile environment: since this stylesheet is only loaded if a condition is met, a mobile device not running IE won’t make an additional request to load it. It’s also possible to use conditional comments so that on Windows Phone 7, only IE Mobile stylesheets are loaded (fewer requests, faster load-time).

Viewports

On a desktop, the dimensions of a web browser can be defined by the user on-the-fly. The dimensions of browser window and monitor are independent from each other.

Desktop browser window and monitor display resolution are two independent attributes.

Desktop browser window and monitor display resolution are two independent attributes.

The mobile browser is limited to the width of the device. To compensate for small device dimensions, the viewport on a mobile device functions as an implied window. By default, many recent mobile browsers setup a viewport that accommodates the width of content on a page, and can be panned and zoomed.

The screen size shows the currently visible area of a webpage. The viewport extends out beyond the currently visible area, and can be panned and zoomed.

The screen size shows the currently visible area of a webpage. The viewport extends out beyond the currently visible area, and can be panned and zoomed.

Alt Desc

Top: In the top image, the viewport is automatically set by the mobile device, and the pixel ratio is low, making text difficult to read without zooming in. Bottom: In the bottom image, the viewport is set to the device width (pixel ratio of 1:1) and zooming has been disabled. Text in the bottom example is readable on page load.

Depending on the site, it might not make sense to force a user to browse in this fashion of panning and zooming. Many popular web applications have created polished mobile interfaces where panning and zooming would only slow down a user. For instances like this, we can actually control the viewport size on many mobile devices.

It should be noted that you don’t want to restrict panning and zooming on mobile devices for all websites. This is only a measure that should be taken if an experience is being designed specifically for mobile users.

Limiting mobile users to a 1:1 pixel scale of a site can lead to lots of panning back and forth to read text. Preventing a user from zooming in on a site not optimized for mobile viewing may lead to super tiny font sizes that can’t be read.

As users become more accustomed to browsing mobile versions of sites, they may grow tired of panning and zooming in favor of websites that have planned an experience specifically for them. Is it preferable to browse a news website where you’re required to zoom into the content area to be able to read it, or would it make more sense if the zoom level were automatically set so the content could be read as soon as a page loads?

Consider the mobile Facebook website. The mobile version of Facebook’s website restricts users from changing the scale of pixels on their site, and creates a fixed viewport the actual width of the device browsing the site. As a result, the mobile Facebook site functions much like a user might expect when running an application on their phone. The mobile Facebook website is incredibly easy to use on a mobile device because everything can be understood without zooming to specific navigation controls or content areas.

Facebooks Mobile site functions like an application built for mobile devices. It does not feel like a website that can be viewed on a mobile device; it feels like a website built for mobile device interaction.

Facebook’s Mobile site functions like an application built for mobile devices. It doesn’t just feel like a website that can be viewed on a mobile device; it feels like a website built for mobile device interaction.

Setting up the viewport for mobile devices can be done using the <meta name=”viewport”> tag. A typical setup may like like this:

      <meta name="viewport" 
      	content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0">
      

This code sets the width of the viewport to the actual device width, sets the scale of pixels to 1px per actual pixel (1:1), and disables the users ability to scale the pixels. The viewport meta tag was introduced by Mobile Safari, and they have done an excellent job documenting these controls.

Mobile shouldn’t be too different

The Microsoft Kin was a smartphone platform unveiled April 12th, 2010. After two years of development, about $1 billion in development costs, and 48 days on the market, the Kin was discontinued. What was the problem?

There are probably a number of reasons why the Kin didn’t do well. I’d venture to guess that one reason is that the Kin smartphone wasn’t actually a smartphone. Smartphones have apps. The Kin did not.

The point is, users are creatures of expectation. Alright, that’s a bit shallow of a statement, but we’re also being shallow as designers if we expect to retain users after drastically changing an experience between devices. If a website is about cookie recipes on a desktop, it should also be a website about cookie recipes on a mobile device.

It’s very rare that you should omit content from a mobile device that would be displayed on a desktop. The most reasonable case for omitting objects from a mobile site is when the object wasn’t essential to the desktop site in the first place.

Mobile design isn’t about crafting an entirely new experience, but delivering the same experience, fine-tuned for handheld devices.

Mobile design isn not about crafting an entirely new experience, but delivering the same experience fine-tuned for handheld devices.

There are exceptions of course, or perhaps better stated as environment specific tasks. One obvious example of this would be an application that makes use of geolocation. While geographic location isn’t always useful data for a web app when using a desktop, location data can be very useful for mobile users. Consider applications like Foursquare and Gowalla that have built really clever experiences around user location data.

In instances where a task can only be completed on a specific device, it’s acceptable to not display that task/content. For the most part, these scenarios are few and far between.

Next up: Mobile behaviors and interactions

In the next part of this series, we’ll be talking about interactions that are unique to mobile devices, and how we can use new frameworks to build interactions like swiping directly into our web applications. We’ll discuss when it’s appropriate to use these types of interactions, and how some desktop conventions don’t translate well to mobile devices.

Until then, thank you for the feedback on this series so far! I know that mobile design is an area of much debate. If you have thoughts on how we should be delivering mobile experiences, I hope you’ll share them in the comments below.

Continue to Part 3: Behavior →

About the Author

David Leggett

David Leggett is a designer, developer, and builder of things. He currently resides as Director of Marketing and Design at Python Safety.

Related Articles

28 Comments

  • Greg Givan Reply

    You might want to update the iPhone 4 resolution. Its a wee bit bigger…

    but another great, timely article.

    • David Leggett Reply

      Ack! Added!

      Actually, it was something I wanted to return to. I believe (though I have not tested yet), that the iPhone 4’s retina display will actually scale pixels in websites to 2-4x their size effectively making the resolution 320x480px. I could be wrong about this, but it seems logical since small type for 72dpi will look incredibly small on a 300dpi device.

      Does anyone know how the iPhone 4 (and other high dpi devices) scale pixels?

  • Bobby Burdette Reply

    excellent timing on this article, we’re having these same discussions every day in the lab! keep up the good work and keep writing about mobile…

    Curious why iPHone 4 resolution was left off the list?

  • Kevin Zurawel Reply

    As far as “multiple stylesheets = multiple downloads”, this is why you should always design for mobile first. Make the mobile stylesheet your base, and use media queries to build the “desktop” site from that base. For phones, whether they understand media queries or not, you get the mobile site automatically and without the overhead of downloading all the desktop styles. On the desktop, bandwidth is cheap and fast, so the extra load time for a stylesheet or two isn’t going to make much of a difference.

    • ganar Reply

      It depends: the new lessframework 4 makes the IE 922px wide option the base, taking into account Internet Explorer. This makes sense since, at least in my market, Venezuela, the vast majority still browse the web using IE.

      If it’s a mobile app or website it makes sense.

  • Greg Givan Reply

    Funny thing, David my partner Bobby Burdette and I are struggling with this very thing right now… a site I expected to see at 640 on iOS4 is scaling down to 320 and throwing the layout off.

    I’m currently experimenting with intial-scale values with the viewport meta tag.

    • David Leggett Reply

      Yeah, it’s been confusing me as well. I’m looking around for Apple documentation to see if they have insight into how it works. I wish I had one so I could test myself, it really seems like something that should be in this post.

      Here is my understanding (posted here with the knowledge that I could be very wrong):

      On the iPhone 4, there are 960x640px to work with, but in a design, you’re really still working with 480×320 “units” (for lack of a more precise term). Each of those units might be composed of something like 2-4 pixels though, so a 80×30 “unit” button might actually be a 160×60 “pixels”. This same button on an iPhone 3 would still be 80×30 “units”, only 1 unit on an iPhone 3 is equal to 1 pixel.

      Hopefully someone knows a bit more about this and can shed some light on the issue for the rest of us! I’ll update you if I learn anything.

    • Peter Larkin Reply

      You’ve basically got it. It’s the whole ‘Points vs. Pixels’ concept. On an iPhone 4, two pixels are equal to one point, whereas on a 3GS, one pixel is equal to one point. You can read more about it in the iOS human interface guidelines here: http://goo.gl/wSQRJ

  • David Reply

    I work with many mobile devices everyday and I personally own an iPhone 4.

    Every dimension in a css stylesheet is 1 pixel for 1 pixel. Which means that if you declare a button 100px of width, it is going to show the exact same size on an iPhone 4 or an iPhone 3(GS). Styles are not affected… though images are. You can see that images at 72 dpi are pixelated on iPhone 4.

    In other words, the best way to have good looking websites is to export images 2x their original size but to resize them with width and height property.

    1024×768 image would be declared: <img width=”512″ height=”384″ src=”src…” />

    • Peter Larkin Reply

      But if you want that button to appear the same size in absolute terms on both screens, the iPhone 4 version would have to be 200px – as it has twice as many pixels.

      The easiest way to overcome this is define the element in points. 100pts would appear as 100px on the 3GS and 200px on the iPhone 4 and thus both appear the same size to the users.

      This is mainly relevant when you’re designing something like a web app and you want it to appear the same across all devices.

  • RaphaelDDL Reply

    You just forgot one thing: CSS3 media queries are not supported by mid-old browsers – mostly the not iOS,Android,Bada and Maemo.

    So this solution is only for newer browsers/devices though

  • RaphaelDDL Reply

    By the way, iPhone4 screen is 640×960 but is actually 320×640 with a bigger dpi

    So, to target iP4, you need the following media query: webkit-min-device-pixel-ratio:2

    This way you can aim for only iPhone4.

    Using a 640px image but Then you use background-size etc to adjust the 320px layout does the trick

  • Erken Reply

    Well, I don’t know if it is of any help but I recently finished an iPhone app project where I had the same problem with the iPhone 4 resolution concerning the UI.

    I had to add two types of graphical elements (pictures, icons etc..) : the normal ones, and the “special retina” ones, twice the size.
    (so for example a 20x30px “normal icon” would have to be 40x60px for the iPhone 4)

    What the iPhone does then is this : if it is an iPhone4, it goes on to fetch the 2x bigger picture automatically, and then scales it down to 320×480. If it is an iPhone 3G/3GS it just fetches the normal picture and doesn’t bother with the super-sized version.

    Now I don’t know about the way a website would be displayed in Safari. If I have some free time I’ll try to find out for you guys and report my findings.

  • Etienne Reply

    Great tips this CSS3 snippet! interesting piece of writing… stresses the importance of thinking thoroughly & prototyping your app for all kinds of devices!

    @just_in_mind

  • Maximilian Reply

    This is a really great review. Thanks for giving us so much information and help. Very helpful statistics too!

  • Frank Reply

    Thank you for sharing.
    It is always a delight to feel what I believe – that
    information is inspiration

  • Ben Reply

    Thanks for the article, but the comments really helped me a lot!

    This iPhone 4 image resizing issue was very confusing, but I have a good solution now.

    This is a great resource!

  • mamjed Reply

    wow, superb article, I added some small typography changes to my site!

  • Tyus Reply

    Viewport ratio is the unsung hero of mobile web design. I recently had to make a SharePoint site usable on an iPhone and viewport really saved by behind.

  • bob marteal Reply

    Great job putting this article together. The list of devices, even if not complete, is a huge convenience. Also, thanks to everyone for the discussion on iPhone4 issues in the comments.

  • Luis Serrano Reply

    Excellent article! :-D Handy, useful and detailed. Good job, and thank you for sharing

  • Drupal webdesigner Reply

    Very clean article, and good job with providing the code. I had some of it but not all. Very usefull.

  • stefffff Reply

    i had no idea that mobile designs for iphone 4 uses such a big resolution of 640×960! quite interesting for the tablets also, according to your chart they need 1280×800 resolution… i think i am going to start looking for some tutorials on the mobile platforms, more people seems to enjoy reading their mail, surfing and buying things with the use of their smartphones! thanks David

  • Jovanky De Los Santos Reply

    This is SUCH a great resource, I just learned how to control the aspects of Mobile design and it is ALL here. Great great post thank you for sharing.

Leave a Comment on This Article