Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

November 17 2011

14:00

A Look Inside Mobile Design Patterns

Mobile Design Pattern Gallery

Patterns for mobile application design

Design patterns for mobile are emerging as the platform matures. Theresa Neil’s new book Mobile Design Pattern Gallery provides solutions to common design challenges. Read a sample chapter on Invitations and learn how to immediately engage your customers with your application.

We recently had a new mobile project starting and all of our experienced mobile designers were booked. Since we primarily design enterprise apps and productivity tools, not everyone in our group was well versed in mobile application design. So I made a quick tutorial with lots and lots of screenshots. Gradually a set of patterns, at a higher level than OS specific design guidelines, emerged.

These 70 patterns, illustrated with hundreds of examples from iOS, BlackBerry, Android, Symbian, Windows and webOS applications, will be released this month from O’Reilly Media as the “Mobile Design Pattern Gallery”. Here is one of my favorite chapters, Invitations. Constructive feedback and additional mobile app examples are most welcome.

*Although these patterns are based on best practices in mobile application design, they may also be inspiring for mobile web design.

Invitations

Do you remember the first time you used Photoshop? I remember opening the application and seeing a blank canvas and a vast array of powerful tools.

Alt Desc

Phototshop 5.5

Well, I assumed the tools were powerful, but didn’t know for sure. In fact, I didn’t know how to get started at all. But I had quite a bit of money invested in the software and needed to learn it for work. So I bought a “Teach Yourself Photoshop in 24 Hours” book and started learning.

Fast forward a decade or so. There are hundreds of thousands of mobile applications, readily available in the marketplace. In any one category there are dozens of apps for the same purpose. Many of them are free, making it just as practical to download and try another app as it is to struggle for 5 minutes with an unintuitive interface.

Consider the initial experience with Layar Reality Browser, augmented reality software.

Layar Reality Browser

Layar Reality Browser (early version)

What would help me get from this gray screen to augmented reality? An invitation. Invitations are helpful tips that are displayed the first time a user opens an application or arrives at a new place. They suggest actions and guide the user to the intended functionality. A simple invitation can turn an otherwise discouraging first time experience into a satisfying one.

Mobile invitation patterns include:

Dialog
Dialog Tip
Tip Tour
Tour Video Demo
Demo Transparency
Transparency Embedded
Embedded Persistent
Persistent Discoverable
Discoverable

Dialog

A simple dialog with instructions is the most common type of invitation in mobile apps, probably because it is the easiest to program. It is also most likely to be dismissed and ignored.

Keep dialog content short, and make sure there is an alternate way to access instructions from within the application.

Dialogs

Dialogs on TargetWeight and ActionMethod

Tip

A tip can be implemented anywhere in the application, making it more contextually relevant than a dialog. And tips can be used on any screen, not just the home screen. In the eBay app, a tip is used to draw attention to the “save a search” feature, which could otherwise be overlooked since it is where the page title is normally displayed. The Android OS displays a tip reminiscent of Window’s Clippy, the helpful paperclip, to explain how to customize the home screen.

Tips

Tips on eBay and Andoid OS

ShoppingList progressively reveals more tips throughout the application.

Place tips in proximity to the feature they refer to, keep the content short, and remove the tip once interaction begins (ie. when the screen is touched).

Tips

Tips on Shopping List

Tour

A tour provides the ultimate invitation by offering a screen-by-screen, feature-by-feature exploration of the application. The Nike GPS tour is an excellent example of this pattern. The tour is optimized for mobile with concise copy, vivid graphics, simple navigation and a clearly marked exit. The Tour is offered on the home screen, and once launched you can tap through each of the seven tips. Nike and WeightBot use “page indicators” and a count (2 of 7) to clearly mark the current step in the tour.

A tour should highlight key features of the application, preferably from a (user) goal perspective. Keep it short and visually engaging.

Tours

Nike’s Tour Invitation

Tours

WeightBot’s Tour Invitation

Video Demo

A video demo may be the best form of invitation for applications that rely on specific actions/interactions since it demonstrates the application in action. Roambi uses a custom demo to showcase its wide selection of data visualizations and the use of certain gestures for optimal navigation and exploration. Google Goggles has a demo in their tour that can be opened and viewed in YouTube.

Demos should showcase key features or show how to use the application from a standard workflow perspective. Common video features (stop, pause, volume controls…) should be provided.

Demos

Roambi’s Demo

Demos

Google Goggles’ Demo

Transparency

While the rest of these patterns exist on the web, the transparency is unique to touchscreen devices (so far). Typically seen on home screens, a transparency is a see-through layer with a usage diagram positioned over the actual screen content. Pulse and Phoster both use this invitation pattern to quickly and visually explain how to navigate content in the apps.


Transparencies should be used judiciously, and are not meant to compensate for poor screen designs. Remove the transparency once interaction begins (ie. when the screen is touched).

Transparency

Transparencies on Pulse and Phoster

Embedded

Unlike the other invitations, embedded invitations don’t precede the screen they refer to. Embedded invitations are built into the screen design. They remain in the interface until they are overwritten with content. Many note taking apps, like Mini Diary and PageOnce, use embedded invitations to immediately engage the user to add content.

Multiple embedded invitations can exist in a single screen. Clearly differentiate the invitation from other content with images or other visual cues (ie. don’t use the same color and size text for the invitation as is used for regular content).

Embedded

Embedded Invitations in Android’s Mini Diary and PageOnce

Persistent

Persistent invitations are built into the screen and remain visible. This example from Jamie Oliver Recipes suggest switching to landscape mode to uncover an additional feature. Wether this is your first time on this screen, or 10th time, the prompt is still displayed. Spring Pad uses an embedded, persistent invitation to show that more notes can be added by tapping on the ‘+’.

Keep it short. Clearly differentiate the invitation from other content with images or other visual cues (ie. don’t use the same color and size text for the invitation as is used for regular content).

Persistent

Persistent prompts in Jamie Oliver’s Recipes and Springpad

Discoverable

A discoverable invitation may seem like an oxymoron, but it is an effective way to encourage specific interactions without cluttering the screen. These invitations are meant to be discovered when performing a common gesture, like flicking or swiping.

Use discoverable invitations sparingly. The most common instance of this pattern is used for prompting refresh and loading more results.

Discoverable

Discoverable Invitations in eBay and TweetBot

Mobile Design Pattern Gallery Book and Site

Invitations are just one of the types of patterns in the Mobile Design Pattern Gallery. Get the upcoming O’Reilly book, “Mobile Design Pattern Gallery”, to learn more about mobile patterns for:

  • Navigation
  • Forms
  • Tables
  • Search, Sort & Filter
  • Tools
  • Charts
  • Feedback & Affordance
  • Help

and a bonus chapter on Anti-Patterns.

Also check out the Mobile Design Pattern Gallery:

More Pattern Resources

Patterns for Android:
AndroidPatterns

Patterns for iOS:
Mobile Patterns,
Pttrns

General Mobile UI Patterns:
4ourth


Advertise here with BSA

November 16 2011

10:00

A Basic Guide To Choosing Colors For The Mobile Web

The rules for mobile design and mobile SEO aren’t completely different from the rules applicable to desktop sites but it is all the minor differences that make a designer’s life hard. These differences are present in all aspects of mobile design and the process of choosing the colors for your mobile site isn’t an exception.

Reuse Your Desktop Color Palette

When I say that the process of choosing the colors for your mobile site is different, don’t take it that it has nothing to do with the standard process you know from desktop sites. In fact, you seldom have to start from scratch but instead reuse your desktop color palette. This might seem like a lazy approach but in fact it is much superior in almost every aspect to choosing your colors from scratch.

For instance, if you want to ensure consistency between your mobile site and its desktop counterpart, the best you can do is use a stripped down version of the color palette of your desktop site. All you have to do is remove the colors for the site components you won’t be using on your mobile site, make sure that they display well on your target mobile devices (you might need to replace some of the colors, if they are too fancy to use on a mobile or if the contrast is unsafely low), and you are ready to go.

However, it is also totally acceptable to start your mobile site from scratch rather than make it a stripped down version of your main site. The most common case for this is when your mobile site has a very different functionality from your desktop site. Of course, even in this case you can use a modified version of the color palette from your main site but if due to various reasons this is not possible, you need to create your separate mobile color scheme.

In any case, when you choose the colors for your mobile website, the technical limitations of mobile devices are a very important consideration to keep in mind.

Keep in Mind the Technical Limitations of Mobile Devices

Mobile devices get more and more powerful day by day but still in terms of technical abilities, they are far behind contemporary PC displays. For instance, mobiles with monochrome displays are almost history, though you can occasionally find people who use them. You might laugh at the idea to design with these devices in mind but the USE_OF_COLOR Human Test (“Browse the page in a monochrome environment.”) by the W3C recommends them as the ultimate test of how readable your colors are. This is not an exaggeration because some of the technical limitations of mobiles (and the environment you use them in) basically take away from you many of the advanced color options desktop displays award you with.

Image from Wikipedia

Color Depth Dictates Fewer Colors

One of the main characteristics of mobiles to take into account is their color depth. Technology is improving rapidly but still even the best models today have relatively low color depth. Low color depth, such as 8 or 16 bits means that a device is capable of displaying 256 and 65,536 shades of red, green, and blue, respectively, which is far from enough.

It is true that mobile displays are constantly increasing their color depth but there is still a lot of room for improvement. For instance, this article (though a bit old) gives an idea of what color depths some of the major brands on the market today offer. For a more detailed look at color depth, check this white paper.

Therefore, if you want to make the colors of your mobile site user-friendly, use as few colors as possible. It is better to stick to main colors and avoid the use of fancy ones because the risk of them not being displayed properly is higher. Additionally, because of the small mobile screens, you simply don’t have much space for lots of tiny squares all in different colors, which further forces you to use a palette with fewer colors.

Brightness and Contrast Settings Demand High Contrast Schemes

In addition to color depth limitations, you also need to consider brightness and contrast settings. The levels you see on specifications might sound decent but they can be misleading because they don’t take (and can’t take) into account the actual viewing environment. For instance, a very common use of a mobile is in the brightness of daylight, when the perceived brightness and contrast are much lower than the ones stated by the manufacturer. You can’t make your visitors browse your site only in the dark of the night to see it in its full glory, right?

What is more, many users keep the brightness and contrast settings low on purpose to conserve energy. All these mean that your site will be viewed with less brightness and contrast. To counterbalance, you need to use really high contrast color schemes. You can use a contrast analyzer to check how you fare.

Be Careful with Gradients and Background Images

If you use a lot of gradients in your designs (as I do), you need to be even more careful. Gradients are cool, but really only on a desktop. On a mobile, a user can see gradients even when they are not present – he or she just needs to bend the device a little, and voila, here is a gradient that you didn’t include in your design. Of course, this doesn’t mean you must kick gradients completely out of your mobile repertoire but if you minimize their use, this won’t be a mistake.

Backgrounds pose a similar problem. The same background might be perfectly legible on a desktop but on a mobile it might be impossible to read the text. It is your task to make sure this doesn’t happen.

Don’t Rely on Colors to Convey Meaning

Even with desktop design, it is not good to rely on colors to convey information – every usability expert will tell you this. However, this is true for mobile designs and even W3C has included it in its Mobile Web Best Practices.

Time to Get the Color Scheme Ready

Image by Wikipedia

When you get to the very task of choosing the color scheme for your mobile site, you need to take into account the meaning of colors and the right color combinations to use. Even if you plan to reuse your desktop color palette, it won’t hurt to see if a better alternative is available and try using a color scheme generator. These also help when you are stuck and have no idea which colors to use, or if you simply want to speed the process. You might not like every scheme the generator offers you but often the suggestions are at least decent and with some minor modifications (i.e. replace the colors in the scheme you don’t like with other colors you find more suitable), you are done.

Examples of Mobile Sites – Great, Good, Bad, and So-So

1. Weather Underground - a great site with clean design visible on any screen

2. Craigslist- boring to look at but really useful, very minimal, as the site itself, doesn’t waste my bandwidth with useless imagery.

3. Gmail – clean and easy to use.

4. Flickr – if they didn’t use the colors from the main site, the contrast could have been better but still it is OK.

5. Walmart – clean interface, though the text color is a bit light.

6. McDonald’s – the logo is rather pale, occupies a lot of space on the screen, but when you scroll down, things get better.

7. Digg – rather pale, difficult to read.

8. Bloomberg – again, could have had more contrast but not bad as a whole.

9. US magazine – the colors don’t have enough contrast, blurred and hard to read.

10. AztekWeb – gradient + low contrast + scrolling + light text on a dark background, though it probably could have been worse.

If you are familiar with color theory and if you have experience in designing desktop sites, you won’t find it difficult to come up with good color schemes for your mobile site. In fact, thanks to the specifics of mobile sites and the fact that all equal you need fewer colors, you might find it easier to design mobile color schemes than desktop ones.

Sponsored post
soup-sponsored
05:36
Reposted bySchrammelhammelMrCoffeinmybetterworldkonikonikonikonikoniambassadorofdumbgroeschtlNaitliszpikkumyygittimmoejeschgeKameeel

October 25 2011

13:00

How to Design a Mobile Responsive Website

To build a mobile site or not to build a mobile site; this is a question at the forefront of many a discussion. There is, however, another option: responsive web design. When, why, and how should you go about designing a responsive website?

With mobile internet users set to surpass desktop internet users in the US by 2015, with tablets becoming more popular, and even with TV internet usage increasing, it’s important for companies to provide a great user experience for all their visitors no matter what device they’re on. How does responsive design help us do this? Well, by allowing us to create one website solution that is flexible for different screen widths. It uses flexible grids and clever styles to present the same content to a user, but displays that content in a format that suits the width of the device. Check out this beginner’s guide to responsive web design for a more detailed introduction.

Why should you design a responsive site?

There are many options to consider when a client asks for a mobile solution for their website, and the suitability of these options depend on the business requirements and budget; it’s also important to consider any existing solutions or sites they already have. Creating a responsive website isn’t a complete mobile strategy, and won’t answer every brief, but, especially if you are starting a website from scratch, you should consider it as a very serious option.

So why would you decide to create a website this way?

You’re starting from scratch

Developing a whole new website or web application is a challenging process. You won’t know if the site will be successful until it’s live and in the world, so creating a separate mobile site or a mobile app in tandem with a website project could be a big waste time and money. It’s more efficient to get your new site performing well before you create an additional mobile site or application.

You want to keep costs low

Solid responsive solutions require additional design and front-end development time, but doesn’t too heavily impact application development. It could take around 20-30 per cent longer to develop a responsive site, but it’s still faster than creating an additional mobile site or app. Developing a site this way also means that you only need to develop, manage, and maintain the one site, so it can reduce these costs too.

You want it to work even when new devices are released

A mobile site needs to be able to recognize the user’s device; when new devices are released, the site needs to be updated. As the responsive solution only recognizes the browser’s width, no new updates would need to be made. This means it’s much more future-proof and scalable.

The process

Let’s talk through the process of creating a responsive website using a hotel website example. This last September, Equator released the new Macdonald Hotels website. Macdonald Hotels are a UK hotel chain with 47 hotels and resorts across the UK and Spain. We created the new site for them that included a new site structure, extensive hotel content, and a new booking engine. Here are the steps we went through and also some considerations you should think about when designing a responsive website.

These are the key steps:

  • Research/scoping: Understanding the additional requirements for a responsive site
  • Wireframing: Grid structures and layouts for the site considering different screen widths
  • Look and feel: Style considerations
  • Building the site: HTML & CSS issues

Research and scoping

Research is always a very important stage in the design process so it’s worth putting a little extra consideration into the people who will be using different devices. Understanding how these different users may want to use the website on a variety of devices will help you to decide what the priorities are on the project.

  • What different goals will a user have on different devices?

    Questions like this are starting to become more redundant. In the past we’ve assumed that mobile users have been task-driven, e.g. I want to get the hotel’s address; I want to book something quickly. But now people on any device are just as likely to leisurely browse the Internet as they are to need to complete a task quickly. It is worth considering though, as thinking about users’ goals in this way could help you prioritize content for the site, irrelevant of what device the visitor is using.

  • What technical considerations do we need to make for functionality and content?

    Think about how any complicated functionality may work on different devices. Although a responsive site will only change the CSS depending on the width if there are complicated elements that rely heavily on JavaScript, they may not translate well on a smaller device and it could be worth hiding these.

Wireframing

The logic behind how the styles should change can be a bit hard to define and the magic of it will really come out in the build of the site, but we need a way to start defining the different width stages of the layout. We choose to look at 3 screen widths, a desktop, iPad and iPhone. We felt these covered what our requirements were, but for your project you should consider what widths are important for you to think about—you may even need to look at bigger screen widths for TV internet usage.

At this point of the project you should already the key templates that you’ll need to wireframe, but you shouldn’t need wireframes for all these templates in the different widths. The main goal here is to help define the logic behind how the CSS will change the look of the page, so focus on pages that have very different layouts. For us we looked at the home page, all the booking process pages, the hotel pages, offer pages as well as some generic layouts. Each of these covered our different column layouts, content types and key functionality.

  • Getting started

    First, define the grid structure for each key width. We created 3 pages for the screen widths 1024px (Desktop), 768px (iPad portrait), 320px (iPhone portrait), then we needed to define a grid structure for each of these widths.

    A very simple grid structure with equal column widths on each layout made it easier for us to plan for components wrapping as the width changed.

  • Creating the master template

    As you create each wireframe you’ll need to think about the columns and how the components within these will adapt as the page width shrinks&mdashe.g. what happens When you have less space? If you have four columns of content? When you change to a three-column width? There should always be ongoing communication between the designer and the front end developer to answer any issues about what you can do with components visually and in the CSS.

  • Starting on the home page

    You may feel like there is another page that has a higher importance than the home page, but this was where we started. Here is our finished original wireframe. You can see the mobile page length is quite a bit larger due to the content wrapping over one column.

  • Main navigation

    We created a simple horizontal top navigation that would have a fluid width to change with the screen size. As the screen reduced the menu items would get closer together, then wrap on to the next line when necessary. This works for desktop, laptop and tablet widths, but going further down we wanted to create a menu that would suit the devices better. This gave us the menu spilt over two columns for the mobile device.

    Other header components are aligned right and would just shift along as the page width reduced.

    Remember when you are styling the navigation to think how it will work as the screen sizes changes. Certain styles, such as using tabs, may be difficult to get to work and look good as the screen width reduces.

  • Footer

    Our footer is pretty simple, just think about what content you want and how it will change as the width changes and the columns reduce—this could be as simple as components wrapping underneath each other.

  • Other components

    Our simple grid structure made it easier to plan out our components. On the home page we used a horizontal scroller that had four components that would scroll across on a click. Our tablet layout let us keep this component but just amend it to only show three items, then on our phone width we removed the scrolling functionality completely and instead displayed each item vertically. Each component you design may require different behaviours, so think about how the visitor will want to use the component on different screen sizes. Phone users are more comfortable scrolling down a page than using small buttons to interact with the page.

  • Test it straight away

    As soon as you have created your first wireframe test it on the relevant device straight away. It’s easy to get the image on a simple web page and take a look at how it looks and feels to scroll down. This will let you know early on if your wireframe is working. Testing in this way gave us clues really early on what was and wasn’t working. If you look at this wireframe you should quickly see our first issue.

    As the user navigated through the site they would only see these first two page elements&mdashthe navigation and the search panel. This means that the user may be unsure if the page has changed, as well as where they actually are on the site. This was solved simply by putting these items in show/hide panels—letting the user get into the content much faster.

    Adding the tablet and mobile versions to your user testing process will give you a lot of useful feedback too. Now that your wireframes are created, tested, amended and approved it’s time to make them look good for all your screen widths.

Look and feel visuals

It isn’t necessary to create visuals for every wireframe. The main objective is to cover all the styles that will be required to create the HTML and CSS. There will be a little bit of a crossover for wireframes and visuals, some styles that will be required for the mobile where there wasn’t a need for an initial wireframe.

  • Styling the page: Think about keeping your styles simpler for your mobile version—what’s great about CSS3 is that you don’t need lots of images to get great styled effects, but these still take a bit of time to load.

  • Thinking about font: Make sure your font sizes are going to be readable on each device. They’ll have to be much larger on the mobile device to ensure readability.

Also, be prepared for your visuals to change when it gets translated into the build of the site. There always should still be balance between what looks good on a flat visual and what will work when the site is being developed. The final site isn’t too far away from our look and feel visuals, take a look here and you can compare with the live site.

Building the site

Building the HTML and CSS is a challenge all of its own, so I won’t discuss this is much detail, but here are a few things to think about.

  • The impact of image sizes: The site will need to load in the full size images even if the CSS scales them down, so try to keep image sizes as low as possible. There can be some nifty JavaScript tricks though to make the site run smoother. On this site we initially loaded in the smallest image size, and then used JavaScript to decide if a larger image was then needed.

  • Use advanced CSS:
    It’s important to get the client behind the idea of using advanced CSS styles, allowing the site styles to degrade as the browser capability does. This lets you keep site loading times low.

  • Constant communication is required: The project will always go smoother if the team speak to each other, so from both designer and developer it’s good to discuss problems and solutions as soon as they turn up.

It’s worth taking a look at our front end developer Jamie Boyd’s take on the front end development of the Macdonald Hotels website for responsive design.

So what does all this mean?

If you are thinking about convincing your client to have their new site designed and developed in a responsive way, firstly you should consider if it really is the right solution for them, then you’ll need to be able to persuade them of the benefits and communicate that it will add more time to the project. But, I do believe that this is how more sites will be developed in the future.

We’ve all learned so much on this project about developing a responsive website. We were lucky to have a client who was as keen as us to create something new and innovative and from that we’ve created a site we’re all proud of.

Image on UX Booth homepage from needoptic on Flickr.


Advertise here with BSA

June 07 2011

12:30

iPad App Dos and Don’ts

Alt Desc

The Nielsen Norman Group took another look at iPad app usability.

If you’ve spent any time with an iPad, chances are you’ve experienced some level of frustration when getting to know a new application (app). The excitement of a new download might peel away if you see a splash screen—perhaps with an animation or unexpected aural outburst;when it seems your fingers are too fat to properly navigate; or when the app lacks key features found on its parent site.

The Nielsen Norman Group (or NNG to make it easier for both of us) knew that the nascent soil of iPad app development was bound to be riddled with usability trouble. And why shouldn’t it? Developers are exploring new terrain, so a learning curve is to be expected. But as the iPad gains users and more businesses feel the need to expand into iPad app territory, new usability research can really help to ease users into a brave new world.

Getting their apps handed to them

A little over a year ago, the Nielsen Norman group released the results of a user-centered iPad app usability study. People listened; NNG is the usability consulting lovechild of gurus Jakob Nielsen and Don Norman. The hydra they uncovered revealed several particularly annoying commonalities between various app types (but, for the most part, excluding games): The Elusive Back Button, The Nonexistent Search Field, and Labyrinthine Navigation, to name a few.

Alt Desc

NNG was a little surprised when they uncovered this during their study. Credit: Luis García

Now, NNG has released a follow-up study to check in and see how usability has improved in 2010-2011 iPad apps. Sure enough, many of the apps they criticized in their initial had integrated the features they lacked. The New Yorker, Wired, Vanity Fair, and Time had all taken NNG’s indirect advice and implemented back buttons, search fields, and other absent-and-missed features. The report singled out USA Today for horrible section navigation, which the newspaper fixed only a few days later.

Clearly, app developers had gotten some useful information out of the research. But checking in on these spotlighted apps wasn’t the goal of the report; instead, it offers some valuable insights into developing and designing for the iPad. In this second round, 16 iPad users spent 90 minutes with a researcher and the device; each user was tasked with simple instructions (“buy movie tickets for tonight,” or “find yourself a birthday present.”), among many others. 26 apps were tested, alongside 6 parent websites. The users, it should be noted, were “mainstream use,” with about two-months’ experience with their devices.

And yes, even NNG acknowledges the small sample size: “Because [it’s] so small, our data needs to be taken with a grain of salt,” one researcher explains in the report. It’s useful to keep this in mind, but it also shouldn’t speak to the quality of data presented.

In other words, proceed with caution. Don’t cite this stuff as pure and bold science. Like any research-related pursuit, nothing is proven here. Instead, take the following account and advice as stemming from an observation of trends.

The iPad: Raw and uncovered

Alt Desc

The iPad, exposing its secrets. Credit: Pedro Eugenio Antunes

Here are a few of the resulting insights into what the iPad is (and what it isn’t), and how that can affect a designer or developer.

It’s not a phone

iPad development is often shaded under the “mobile” umbrella, but that’s not how they should be viewed because that’s not how people use them. iPads aren’t used like smart phones, and their owners typically see the devices more laptop-like than phone-like. The authors explicate with anecdote: how often do you see someone walking through a store, quickly checking a price for something on her iPad? How about driving while checking directions on an iPad?

Mobile apps are minimalistic, as they should be. They are pared and optimized so busy users can flick in and out while getting everything they need. iPad apps, however, needn’t be so hyper-optimized for quick-and-dirty use. That’s not how people are using their iPads.

In fact, users appear much less accepting of an iPad app that lacks parent-website features than they are of mobile phone apps. In the NNG report, Sears.com and the Sears iPad app stand before the firing squad, as user after user are highlighted failing to properly find and scrutinize a dryer. In these cases (as well as with Amazon’s Windowshopper app) users were more likely to just give up and launch Safari.

The community iPad

Users aren’t as attached to their iPads as they are their phones. The iPad is less personal, and as a result, the device is often shared by at least two users. In several cases during the NNG study, users would explain to researchers that, no, those aren’t my apps. They’re my husband’s/wife’s/child’s/roommate’s/soon-to-be-ex-mother-in-law’s. iPads tend to get around.

And what are these people using iPads for, primarily? Games. Lots and lots of games. Reading is a popular activity, as is checking (but not responding to) email and social network sites. For the most part, users aren’t doing too much word processing, photo editing, or spreadsheet generation on their iPads; they save that for their home computers/laptops, while the iPads function something like the computer’s peripheral inner child—a consumptive, playful child.

It’s this community aspect of the device that leads users away from potentially sensitive form-entry, such as shopping or divulging certain logins and passwords. They want the option to stay logged in to apps and sites, but don’t want it force-fed to them. If someone else will be using the iPad an hour after you, it’s nice to know they can’t access your stuff.

These observations are great, you might say, but what does any of it matter for me? Which leads me to the fun part of the study…

How not to botch your iPad app

No app is perfect, of course. But there are some particularly trying offenders out there. Without focusing on the offenders themselves, here are a few of the most aggravating issues users had while running trials with their iPads.

It’s alive! Splash screens back from the dead

Oh excuse me—launch pages is what they’re going by now. A rose by any other name still annoys the wits out of users. The researchers on the NNG study noted a few examples (the Washington Post app, Al Gore’s Our Choice app, and the Toys’R’us app). Users reacted negatively, especially when launch screens continue to plague the app after the first launch. Even the prettiest launch screen gets old after the fourth or fifth viewing.

Alt Desc

This is what you see, and hear, when you launch the Our Choice app. Credit: NNG

And launch screens with sound? Not acceptable. Not ever.*

(*Exceptions may apply if it’s a game or other sound-centric app—this study focused on more practical applications.)

Packing heat

iPad apps should have added value for the user, something that makes the app preferable in some cases to a parent website, if applicable. The NNG report praises Epicurious’s app for anticipating that some cooks might pull up a recipe and prop it before them in the kitchen. Because of this, the designers made sure the recipe could be viewed hands-free.

If there’s no need to have an app, think about simply making an iPad-friendly site, one with large buttons (to avoid the “fat finger” problem), targets with appropriate distance between them, and minimal required typing.

Design for liberal swipers

NNG found that users grew frustrated with the apps they were using if swiping was enabled but didn’t work all over the place. This was especially applicable in the magazine apps—users in the study liked to swipe to turn the page. But if that swiping mechanism only functioned properly in one portion of the screen, and a user missed that spot, he or she would become annoyed.

If your users are on a page that encourages the page-turning swipe, make sure to give the swipers some leeway.

Be popover-conservative

Popovers—the dropdown-type menus that Apple introduced across the iPad system (for instance, when you open the iPad mail client, the list of email address that pops down is a popover)—are easily and often abused. Some app developers like to shove and cram text into popover items, making a huge design mess for everyone involved—it invokes the “fat finger” problem, looks cluttered, and fails to communicate and properly organize content.

Alt Desc

NASA’s idea of an intuitive popover. With little scroll-ability and huge, unnecessary photos, NNG disagrees. Credit: NNG

Take a step back if you plan on integrating popovers. Is it wholly necessary? Is the content intuitively organized as items? Does the text look too small? These may seem like obvious questions, but enough apps were guilty of this crime to bear mentioning.

Pad those targets. Pad them real good.

This is the pinnacle of the fat-finger problem. Often times, targets are far too remote for users to reasonably touch with any precision or accuracy. This can lead to frustration and, in a worst case scenario, abandonment of an app or mobile website.

Both Microsoft (PDF) and Apple development libraries suggest that the ideal target size for touch screens is somewhere around 44 pixels squared, which works out to be about 1cm by 1cm. That way, users won’t have to focus too closely on an otherwise mundane, straightforward task.

Don’t boldly go where others have gone before

While the sample size of the NNG trial was admittedly small, there are still rather nice pieces of insight that emerged from the study. As the featured/criticized apps get wind of the study, draw in their products and fix them, then release them back into the app store, may the rest of us learn from their mistakes.

I’d love to hear how this kind of research affects your app development, if at all. Are there any particular issues you’ve come across while developing for tablets? Post your comments down below!


Advertise here with BSA

May 02 2011

20:31

A User-Centered Approach To Web Design For Mobile Devices

Advertisement in A User-Centered Approach To Web Design For Mobile Devices
 in A User-Centered Approach To Web Design For Mobile Devices  in A User-Centered Approach To Web Design For Mobile Devices  in A User-Centered Approach To Web Design For Mobile Devices

For the past few years, we’ve heard pundits declaring each year as “year of the mobile Web”; each year trying to sound more convincing than the previous. Whether 2011 will be the real “year of the mobile” remains to be seen, but what is indisputable is the fact that the mobile usage of the Web is growing and evolving. As it evolves, so does the mobile user experience, driven by advances in mobile device technology — from better browsers on basic mobile phones (or feature phones — remember the Motorola RAZR?) to the increased adoption of smartphones and tablets.

The term “Mobile Web” (although often criticized) is commonly used to describe accessing the internet using a mobile device. This definition is broad enough to cover everything from using a browser on a feature phone, to using highly customized apps on smartphones or tablets. “There’s an app for that” has made device-specific applications the rage of the day, with some companies starting off backwards with “we need an iPhone app” instead of first understanding what their users actually need when they are mobile, the devices that they use, and then deciding the best approach for going mobile, which may not be an app, but could be a mobile website instead. Mobile websites are universally accessible, less expensive to develop and maintain, and can be searched and accessed by most mobile phones.

(The term “Mobile Web” is criticized because it implies that there are “different” Webs which just isn’t true — there is no Desktop Web, for example. It makes more sense to speak of the websites optimized for users accessing those websites through mobile devices. We will be using this perspective in this article. — Smashing Editorial Team)

This article focuses on designing the user experience for mobile websites accessed from mobile phones with small screens, though the process can be applied to building apps as well. As a Web designer, the good news is that the process is similar to designing desktop websites — with some additional mobile-only considerations that go hand-in-hand with small screens, device features and constraints, and connectivity issues. The user-centered mobile design life cycle can be thought of as an ongoing process as shown below:

User-centered-mobile-design-lifecycle in A User-Centered Approach To Web Design For Mobile Devices
The ongoing user-centered mobile design life cycle

Let’s discuss each phase of this life cycle in more detail.

1. Assess Current Situation: Do You Really Need A Mobile Website Now?

Silly as this may sound in an article about creating mobile website user experiences, it is important to first figure out whether you actually need a mobile website. True, there will be 91.4 million mobile internet users in the US by the end of this year, but how many of them are in your target audience? Mobile commerce sales in the US in 2010 were $3.4 billion, but if you are not selling anything online, does that matter to you? The more relevant statistic is how many of your users are accessing your website using mobile devices. A quick way to find out is of course by looking at your existing desktop website analytics to identify the percentage of mobile visitors, along with the types of devices and operating systems they use to access your full desktop site.Dig deeper to understand why these users visit your site using a mobile device — what they are trying to do, and the content and functionality they are using.

Now, think about what else would be relevant to these mobile users, and for some competitive insight (and possibly inspiration), take a look at what similar sites are doing with their mobile presence. Your desktop site was created to support some business goals — it may have been a simple goal of creating awareness or a more complex goal of generating revenue through online sales. How will a mobile website complement that existing website? Identify the content and functionality that will be useful for your mobile users while supporting your business goals, including any new goals for mobile. Save these “business requirements” — we’ll need them when deciding what goes on the mobile website.

If, at the end of this exercise, you realize that you have very few mobile users, and they occasionally use just a couple of features (like finding your phone number, or hours of operation), you may be better off for now just optimizing your desktop site to make that information easily accessible by mobile users instead of building and maintaining a separate mobile site. If your website happens to be running on WordPress, there are plugins that can easily mobile-enable that website with little effort.

Not all websites need to go mobile now. Companies that need to extend their core services to their users (like those in travel and banking) certainly do, but a manufacturer of commercial jetliners and military aircraft or a provider of specialized industrial gases would probably not need a separate mobile website now, though that may change in a few years. But if you realize that you need a mobile website, let’s focus on the reason you need it: your users!

2. User-Centered Mobile Design Starts With The User

User-centered design relies on user involvement throughout the design process, leading to a solution that users will find useful and want to use. To achieve that, you first need to have a clear understanding of your users, grouped into a prioritized set of user groups whose needs can be thought of individually. For a pharmaceutical company, those groups could be patients, healthcare professionals and caregivers, with the first two groups being the primary user groups, and caregivers being a secondary user group with very similar needs to patients. Identifying your key user groups and creating personas will help you design better for your main users, the way BBC did when building their future mobile strategy.

Bbc-user-groups in A User-Centered Approach To Web Design For Mobile Devices
BBC’s mobile user groups (taken from their future mobile strategy)

To develop a mobile user experience that aligns to the needs and expectations of your targeted users, you must involve representative users and their feedback throughout the process. Direct input from your users through primary research methods like observing users, contextual interviews and focus groups will give you insights about their mobile behavior, including what they want to do on the mobile Web, and when and how they will use it. Primary research will give you answers to questions like:

  • Why do they use your site on a mobile device?
  • What features are they using?
  • What features are crucial for them when mobile?
  • What are some sources of frustration?
  • What devices do they use to access the mobile Web?

As you build a detailed picture of your users and their usage patterns, supplement it with secondary research about industry and mobile market trends from Forrester, eMarketer, Nielsen and comScore, comScore Data Mine, DeviceAtlas and Opera’s State of the Mobile Web. Apart from an understanding of your user and their needs, you will also get a better understanding of the types of mobile devices you have to consider while designing.

3. Prioritize What Your Mobile Website Should Offer

While evaluating the need for a mobile website, you had a list of features you would like to offer on your mobile website. Ideally, these business requirements would align closely with the user requirements identified during user research. If they do not align, look at the requirements asking yourself “what value will this add to the users?” to ensure that your business requirements meet user needs and goals — this is user-centered design after all.

As is often the case, if you end up with more features than you can handle at launch, prioritize what you can initially offer, taking into consideration time, effort, and resources available. Hard as it may be, resist the temptation of trying to build in all the features right from the start. As 37signals so eloquently put it: “Build half a product, not a half-ass product.”

4. Mobile Design Considerations

Now that the groundwork has been completed, it’s time to get to the fun part: actual design! The basic design steps and principles of desktop website design apply to mobile design, with the addition of a few important mobile design considerations. Mobile devices are personal devices with small screens, always turned on, have intermittent slow connections and are mostly used when the user is — you guessed it — mobile.

This brings us to the big “C” of mobile: Context. Mobile users are not captive like computer users are. A user using your desktop website is sitting comfortably, and in a worst case scenario, may be simultaneously listening to music and intermittently tweeting. They are however, not doing all that with one hand, while walking around. Picture a mobile user trying to find directions using a tiny phone with intermittent connectivity, while strap hanging and swaying in a subway train with sub-optimal lighting conditions, deafened by the screeching of wheels on tracks — that gives you some context of use. Simply put, context is about the environment and conditions of usage, including distractions, multitasking, motion, lighting conditions and poor connectivity as you can see in the video below:


Designing for Mobiles: Users & Context from Niek Dekker on Vimeo.

In Tapworthy – Designing Great iPhone Apps, author Josh Clark boils down the mobile user’s mindset to one of three possibilities:

  • Microtasking: Using the phone for short bursts of activity.
  • Local : Finding out what’s around the user.
  • Bored : Using the phone for distraction/entertainment.

Keeping all these factors in mind, here are some specific mobile design considerations to pay attention to while designing for the mobile Web:

Design for Smaller Screen Sizes

Designer-user-desktop-laptop-phones in A User-Centered Approach To Web Design For Mobile Devices
From a designer’s big screen to smaller laptop and mobile screens

The most visible difference between a mobile device and a desktop is the screen size. For years, we have been increasing the minimum screen resolution we design for (remember the days of “optimized for 640 x 480″?). Mobile phone screen sizes have also been increasing, but even the gorgeous screen of the iPhone 4 is still small in comparison to a standard 1024×768 desktop design (designed by someone using a 2560×1440 display). This gets more complicated when you factor in the range of screen sizes used by your mobile users. And let’s not forget that some smartphones can change orientation and their users’ expect the website to resize accordingly. Even though many smartphone browsers today can miniaturize desktop websites, they inadvertently break the user experience by making users zoom in and out, which brings us to the traditional approach of creating a separate website for mobile devices.

Bryan Rieger addresses the issue of designing for multiple screen sizes with a 4-step process:

  • Define device groups by grouping screens with similar widths together resulting in a manageable number of groups,
  • Create a default reference design that will adapt to smaller and larger screens,
  • Define rules for content and design adaptation for it to display well and
  • Opt for Web standards and a flexible layout.

While you should ideally be designing for mobile devices used by your users, for a more generic list of browsers to support, follow Peter-Paul Koch’s recommendations of supporting Safari iPhone, Opera Mini, Android WebKit, BlackBerry (WebKit & older for US), Nokia WebKit (Europe).

The other approach advocates a single website that caters to all devices, mobile or not, based on Luke W’s Mobile First principle (see presentation). Mobile First starts with a design for mobile, which can then be progressively enhanced for desktop websites. To see it in action, take a look at Yiibu’s
proof of concept site
based on Mobile First.

Selecting your design approach is not a black and white option. Think about which will work better for your situation. Irrespective of the approach you select, there still are other considerations that go into building a mobile Web.

Simplify Navigation

Without a mouse to point and click, mobile users have to rely on tiny keypads, trackballs and touch to navigate mobile websites. Add in the small screen with the need to complete tasks quickly and efficiently, and clear and intuitive navigation becomes crucial:

  • A common approach that works for the start pages of most sites is a list of links to main features and content, prioritized based on user needs. These often end up being presented vertically instead of the horizontal model used on desktop websites.
  • Reduce the number of categories and levels of navigation, and rearrange based on priority, presenting the most important categories first.
  • Use clear, concise and consistent labels for navigation across the site.
  • Provide access key shortcuts for feature phones, so users can enter a keypad number (0-9) to quickly access a link (AA and CNN examples below).
  • When designing for touch, make sure the tap size (width or height) for the navigation item is at least 30 pixels.
  • Make links obvious, and provide clear and immediate visual feedback to show the selected link.
  • When displaying the main navigation links on internal pages, put them at the bottom instead of the top, to avoid users having to tab through all of them to get to the main content on the screen (CNN example below). If not displaying all the links, Southwest’s approach of listing key links (Home, Air Reservations and Flight Check In) on secondary screens works well.
  • At the bottom of the mobile homepage, offer a link to the full site so users can switch over to the desktop site, and vice versa.
  • Breadcrumbs are not usually not used on mobile sites since navigation is not usually so deep that users need a trail back.

Simplify-navigation-examples in A User-Centered Approach To Web Design For Mobile Devices
American Airlines, CNN, and Southwest simplify mobile navigation

Prioritize Content

Be succinct. Smaller screen sizes require even more careful attention to the content displayed to the user. Put on your editor’s hat and cut unnecessary content, then cut some more. When you’re done, prioritize the content and display the most important content first.

Amazon1 in A User-Centered Approach To Web Design For Mobile Devices
Amazon’s mobile site prioritizes what it offers users on the homepage

Minimize User Input

Casio-tiny-input in A User-Centered Approach To Web Design For Mobile Devices
Having used tiny numeric keypads and touchscreens on these Casio DataBank watches for over 20 years (yes, I admit it), I know the pain involved with entering data on miniscule screens. Feature phones have tedious numeric keypads for input, while smartphones have tiny keyboards, either real or virtual, which are subject to fat-finger errors.

  • Keep your URL as short as possible, keeping in mind, feature phone users have to repeatedly press a key for most alphabets (key presses for “com” are 222-666-6). Follow URL naming conventions that users are used to, like m.site.com or mobile.site.com.
  • Use alternate input mechanisms where possible. While apps can use device capabilities for input including motion, camera, gyroscope, and voice, mobile websites are slowly starting to use some of these features, like geolocation.
  • Limit input to essential fields. For instance, if registration is required, limit it to the minimum required fields, and use shorter alternatives like a zip code instead of city and state. Volkswagon mobile captures geolocation, but does not use it when trying to schedule a test drive. Not only that, the mobile form is longer and more tedious than the desktop one.
  • Select the best mobile input option (e.g. allowing users to select from a list of options is often faster than typing).
  • Use smart default values. NJ Transit’s mobile website remembers your last selections and defaults the date to today’s date.
  • When users need to log in, offer the option to stay signed in, especially since mobile devices are personal and not usually shared.

Minimize-input in A User-Centered Approach To Web Design For Mobile Devices
NJ Transit uses geolocation, remembers selections and defaults to today’s date

Vw-small in A User-Centered Approach To Web Design For Mobile Devices
VW asks for location, but fails to use it (the mobile form is also longer than the desktop version). See larger image

Design for Intermittent Connectivity

Even with mobile service providers rolling out faster G-speeds, mobile connectivity remains intermittent and does not even approach broadband speeds we are so used to on our wired and wireless connections (not even Justin Bieber’s 6G phone!). Users pay for internet access on their phones, and not everyone has unlimited data plans, so as mobile designers, we should think small when designing for mobile:

  • Keep page sizes small so they can load quickly and are within the memory limitations of most phones.
  • Remove unnecessary code, comments and optional tags.
  • Reduce images to sizes and resolutions appropriate for mobile devices.
  • Minimize the number of embedded images to reduce the number of HTTP requests and to speed up page load time.

Offer Cross-Channel Consistency & Integration

When you create a mobile website, you cross over into multi-channel territory, and with it, the need to maintain a consistent and integrated user experience across channels.

  • Balance form and function. Continental Airlines takes a minimalistic, no-frills approach, using just their logo for visual branding, while Southwest makes their mobile website a little more visual with color and icons.
  • Maintain continuity. By signing in on the Amazon mobile website, users can view and manage their shopping cart, wishlists and view and track orders, just as they would on the full site. Another good example in the making is Kindle for the web which, when launched, would allow you to continue reading a Kindle ebook where you left off, irrespective of the device you last used. It would also synchronize your library, bookmarks, notes, and highlights.
  • Extend the user experience. Sephora mobile users can look up user reviews and ratings of products (by UPC or name) when trying to decide between two or more products in-store.
  • Build a consistent user experience. Citibank users going from the full site, to the smartphone website or an iPhone app have the same user experience across all these channels (though some feature phone users cannot use the site at all).

Cross-channel-balance-extension in A User-Centered Approach To Web Design For Mobile Devices
Balancing form and function; Sephora extends the experience for the mobile context

Other Considerations

  • Detect if your users are using a mobile browser and direct them to the mobile website (with a link on that screen to switch to the full site).
  • Do not rely on technology that is not universally supported by your audience devices like Java, JavaScript, cookies, Flash, frames, pop-ups and auto refreshes.
  • If you must make the user scroll, make them scroll in only one direction (most sites scroll vertically).
  • Use short, descriptive titles for your pages for easy bookmarking and recall.
  • While there are advocates for creating separate mobile sites for feature phones, smartphones and iphones (yes, their own website), others have gone down this road and are opting for a single mobile site. Facebook, one of the most visited mobile properties, recently decided to unify its mobile websites into one interface.

5. Prototype Review & Refine

Prototype-review-refine in A User-Centered Approach To Web Design For Mobile Devices
The rapid prototyping process (from Design Better And Faster With Rapid Prototyping)

Prototyping is important in an iterative user-centered design process, allowing designers to quickly visualize parts of the website, review with users and refine the design. Prototype early and often through the design process, starting with low fidelity paper sketches, refining them into medium fidelity wireframes and subsequently into high fidelity designs, continually testing with users and iterating based on their feedback.

Double check your code for compliance by validating your mobile site using the W3C mobileOK Checker or mobiReady to uncover and fix potential issues your users may face. Mobile emulators and simulators are useful during development, but nothing beats testing your site on actual devices that your users are using.

Ongoing Improvements

Your job is not done when you launch your mobile site — you’ve just come full circle. It’s time to monitor site usage and user feedback to identify changes and requests for new features, in addition to any features that did not make it in the first release. Periodically evaluate your mobile site against competitors using a scorecard (sample from Yankee Group [pdf]) to identify potential areas for improvement.

In Conclusion

The mobile Web is different, and may be daunting, but the design process is similar enough for Web designers to ease into mobile design. Designing the perfect mobile website is an impossible task even for experts, but using an iterative user-centered design process can help create the best experience for our users with their help.

Related Articles

Resources

Tools

Books

  • Designing the Mobile User Experience by Barbara Ballard
  • Mobile Web Design by Cameron Moll
  • Strategic Mobile Design: Creating Engaging Experiences by Joseph Cartman and Richard Ting
  • Mobile Design and Development: Practical Concepts and Techniques for Creating Mobile Sites and Web Apps by Brian Fling

(ilj)


© Lyndon Cerejo for Smashing Magazine, 2011. | Permalink | Post a comment | Smashing Shop | Smashing Network | About Us
Post tags: mobile, mobile design, Prototype Review, User-Centered

March 22 2011

13:26

Considerations for Mobile Design (Part 3): Behavior

This is a continuation of our series, Considerations for Mobile Design. You may also like to read Part 1: Speed, and Part 2: Dimensions.

Considerations for Mobile Design: Behavior

How do users behave different on touch-based interfaces, and how can you start implementing new gestural actions into your mobile web products.

As we conclude our series, Considerations for Mobile Design, we wish to spend a little time looking at how users behave differently on handheld devices compared to desktops and laptops. In this final part of our introduction to mobile design, we explore how touch interfaces are different from more traditional means of user input, and how designers can start implementing new gestures into their own products.

Click vs. Touch

On desktops, we click. We pilot a tiny cursor, control it as it flies across the screen, and precisely hit the targets we’re aiming for. There might be an occasional misclick, but even then, reversing our actions in a web browser is typically easy to do.

On handheld devices, we tap. Our hands become the main input of the device, and our hands aren’t as nimble and precise as a mouse cursor. We touch areas of the screen rather than an exact pixel. We readjust the grip on our smartphone as we attempt to hit a button with the same hand. When there is a mistap, the consequences are more time consuming; slower page load times, and slower device speeds make the wait less forgivable.

We readjust the grip on our smartphone as we attempt to hit a button with the same hand. When there is a mistap, the consequences are more time consuming; slower page load times, and slower device speeds make the wait less forgivable.

In an effort to aid users in navigating mobile interfaces, some groups have determined the average tap size. Using these averages, we should be able to build interfaces that are easier to use, and result in fewer mistaps.

Apple suggests that a minimum of 44×44px pts (thanks Vicente!) should be used for tapping. According to Apple, this is the average area of a finger tap on their mobile devices.

The UI Design and Interaction Guide for Windows Phone 7 (.pdf) suggests using at least 9mmx9mm for tapping (which on Windows Phone 7 devices translates to about 34x34px). At least 2mm of space (or 8px) should be given between controls. With the introduction of more devices with high resolution displays (like the iPhone 4), measurements that describe physical space may be more useful than pixels since pixels per inch varies by device..

These are great benchmarks to base our own interactive elements on. We can say things like, all touchable items on the page should be at least around 40x40pts, and should be at least around 10pts away from other touchable items. Simple enough.

What’s really important to take away from this is that your controls need to facilitate touch interaction. This might mean giving links in content body extra padding so they’re easier to tap. This might also mean you need to add extra space between items in an ordered list of links.

The importance of implying touch

It probably goes without saying, but in the same way that links should look like links on desktop browsers, touchable items should look like touchable items on handheld devices. In fact, it’s probably even more important. Aside from mistakes typically taking longer to correct on mobile devices, there is no such thing as a mouse hover. In other words, a user can’t check to see if something is tapable by hovering over an item on a page and checking to see if a cursor changes to a pointer.

Andrew Maier has written in the past about creating usable links and buttons.

Form interactions

While there isn’t widespread support across mobile devices yet, declaring input types will certainly be important in form design moving forward. Some devices (such as iOS 4 and Android 2.2 devices) already have some support for the latest input types outlined in the HTML5 spec.

A big reason to be using these new input types is to provide contextual interfaces for entering data. In other words, if I click an input with “type=number”, show me a number pad instead of a full QWERTY keyboard. If I’m using a “type=url”, get rid of the spacebar, and make symbols like “.” and “/” more prominent.

In addition to speeding up data entry, these additional field types limit possible errors. It’s hard to accidentally type a letter in an input if only numbers are allowed.

Details on the newly introduced types can of course be found on w3.org, but a few common useful types are shown below:


<input type="text" />   <!-- Default text entry -->
<input type="email" />   <!-- Email addresses -->
<input type="url" />     <!-- URLs -->
<input type="tel" />     <!-- Telephone numbers -->
Different keyboard types on the iPhone.

Several different keyboard types from the iPhone OS. (From iOS Developer Library)

Pete Freitag has put together a pretty handy demonstration of support for these contextual controls on iOS 4 and Android 2.2 devices.

These controls are super easy to implement, and will definitely expedite data entry for the on-the-go mobile user.

New user behaviors

If you use a touch-enabled handheld device already, chances are that you’re accustomed to actions like pinching, flicking, and sliding. In fact, these gestures might seem very natural in some applications (ie: zooming in on a photo by stretching it out with two fingers).

There are a few frameworks out there that have made integrating these actions into your own applications pretty simple. jQuery Mobile is one such framework, and one that many already have experience with. Quite a few events are offered in the framework by default, and using the existing code additional events can be added in pretty easily (like Swipe Up and Down).

In addition to these sorts of events, jQuery Mobile makes page transitions, layout development, dialogs and more far easier to create for mobile devices.

jQuery mobile also offers a layout system with progressive-enhancement driven form controls

jQuery mobile also offers a layout system with progressive-enhancement driven form controls.

When should you use new input methods?

imgur allows users to upload files by dragging a photo directly from the desktop into the web browser.

imgur allows users to upload files by dragging a photo directly from the desktop into the web browser.

A relatively new convention on desktop browsers is the ability to drag and drop files from your desktop directly into a web page. Gmail allows this (but doesn’t it make it obvious to users that don’t already know about it), as well as several image sharing sites like Imgur.com.

Because this isn’t a very common interaction, it requires explaning. You wouldn’t simply start dragging and dropping files from your desktop to a browser to upload a file (usually). You either already know that this site accepts that type of input, or the site has done a good job explaining that this is a possible interaction.

It’s not a mature convention yet. There isn’t a commonly accepted way of visually communicating this input type… though a few are surfacing.

On the other hand, there already exist a lot of very practical conventions in web design. Obviously, underlined text (usually a separate color from surrounding text) constitutes a link. Modals can usually be closed by clicking outside of the modal area (or by hitting a close button). The list goes on…

Windows Phone 7 devices often let content overflow the right edge of the screen to communicate that the viewport can be panned with a swiping motion.
Photo Credit: Cedric Chee

Returning to mobile design, the same holds true: while many clever new interaction types like “swiping” can potentially offer great solutions to UI design problems, they’re still very new gestures. People aren’t used to “swiping” in a browser. Does swiping on one site do the same thing on another site? Does swiping affect an entire page, or is it used inside of a containing element?

These new interactions in the immediate future need to be taught to the user. Also, you most likely should not be going out of your way to cram every possible type of gesture into your trendy new app. Only use these newer types of input when you truly believe they make sense. There’s no sense in reinventing the wheel if no one knows how to use it.

Moving forward

This wraps up our series on Considerations for Mobile Design, but this is merely a stepping stone for people who are just beginning to wrap their heads around the mobile web. If you’re like me, you may have have been dismissing the mobile web for the past few years. For some of us, it just didn’t feel quite ready to handle complex applications with rich user experiences.

If we’re not at a point where the mobile web is ready today, we’re certainly very close. Between device availability, high speed connections, and new web technology, the groundwork is in place (or at least falling into place) to develop new generations of web-based applications that assist us, travel with us, and connect us with others at all times.

Between device availability, high speed connections, and new web technology, the groundwork is in place (or at least falling into place) to develop new generations of web-based applications that assist us, travel with us, and connect us with others at all times.

There are a few resources that I’ve found useful in discovering more about mobile design that you might also find interesting:

There are also quite a few books out there on the subject of mobile web design, many widely applauded. However, the mobile web landscape has changed (and continues to change) so quickly that much of the information written about the mobile web even a year ago is no longer relevant. I would strongly encourage focusing on recent articles and publications to avoid misinformation.

And of course, the UX Booth will continue to discuss the mobile web as it continues to gain momentum. We’re hoping that this series is just the beginning of a topic we consider to be extremely interesting, and we’re actively seeking contributors to help us explore the mobile web as it continues to blossom. If you’re interested in becoming a guest author on the UX Booth, please be sure to visit our Contribute page.

March 15 2011

13:00

Mobile Form Design Strategies

A Web form which works well on desktops won’t necessarily work on mobile devices. With the nature of desktop computers, Web forms are not designed to be efficient. Due to the constraints of a mobile device and its context of use, efficiency is extremely important when filling in a mobile form. This article offers strategies that you can apply to design a more efficient and less error prone mobile form as compared to your Web form.

Web access from mobile devices is constrained by various factors: (1) the use environment where the user could be in a busy and crowded place. Sun or light reflection might be an issue or users may be multitasking and under time pressure; (2) the network (slow or an unstable connection); and (3) and the device itself (small screen).

According to the ISO 9241-11 standard model, usability consists of three elements – satisfaction, effectiveness and efficiency. However, Web forms are not designed to be efficient. When filling in forms on desktops, users normally have a stable, free(ish) network and they are unlikely to be under time pressure. On the other hand, mobile use faces a more challenging environment and it is more prone to failure. Efficiency becomes an important aspect. The longer it takes for users to fill in a mobile form, there is a higher possibility that failures or errors could happen, for instance, drop of connection. In addition, there might be costs involved for mobile data. How fast a user can accomplish their tasks is crucial on mobiles.

Forms for mobile versus desktop

Desktop and mobile versions of Hertz reservation form and Burger King store locator form

Hertz reservation form and Burger King store locator form (desktop versus mobile versions)

Your mobile form can be a simplified version of the desktop Web form without distractions, adverts, promotions or images (e.g. Hertz reservation page). Alternatively, it can be a completely different version with a simpler and cleaner interface (e.g. Burger King find a store page). It can also be the same form fields as your Web version but with slight changes to the layout such as label alignment (e.g. M&S registration page).

The design strategies discussed in this article could be considered and used when redesigning your form for mobile use. Although iPhone (iOS) is used in the examples, these strategies can be applied across various mobile platforms and operating systems.

Mobile form design strategies

Vertical align labels

Right aligned label form (Trainline) Versus Top aligned label form (Burger King)

Right aligned labels (Trainline) Versus Top aligned labels (Burger King)

Long label can't be fully displayed

Long label can’t be fully displayed when left-aligned label is used

Each label alignment has pros and cons. When designing a Web form, it’s more important to choose one which suits to your form purpose, design constraints and so on. However, for mobile forms, horizontal labels (left- and right- aligned) should be avoided. When users click on an input field, the page is often automatically zoomed in to focus on the field. If horizontal labels are used, it is almost impossible to view both label and input field in one screen. In addition, due to small screens, it could be tricky to show long labels if horizontal labeling is used on mobile devices (e.g. Virgin Blue mobile version of manage booking form).

These problems can be avoided by using top aligned labels.

Remove

Due to the constraints of mobile devices and the context of use, mobile forms need to be as simple and straightforward as possible. Getting rid of unnecessary elements and features help users to focus on their tasks without unnecessary distractions and minimise possible errors.

One obvious technique is to omit optional and ‘not so important’ fields. Show only fields which are absolutely required to complete the process and task. You can also get rid of elements which do not have primary uses. This includes tips, descriptions and links such as ‘Learn more’ or ‘What is this’. It helps to reduce visual clutter and simplify users’ experience. Hertz understand their mobile users’ needs and have done well when designing their mobile reservation form. The form looks clean and easy to use without secondary content.

Hertz simplifies its booking form by removing secondary elements such as tips and helps

Hertz simplifies its booking form by removing secondary elements such as tips and helps

When you are trying to figure out what should be kept and what needs to be removed, consider this: if the input of a field is not going to affect the search result, for example it is only useful to define how the result should be displayed (e.g. display options, filtering or sort by features), don’t be afraid to kill it.

Combine

Another way to simplify your mobile form is to combine various similar input fields into a single field.

Mapquest simplifies their form by combining three search features into one input field

Mapquest simplifies their form by combining three search features into one input field

To get a driving direction using Mapquest desktop version, you have three options to specify your start and end points: ‘Find a business (where you can specify a company name), address or intersection (full address) or saved and recent locations. The flexibility offered by the form is great for desktop users, but not so much for mobile users. First, it is challenging to display all three options on a small screen without looking cluttered. Second, giving users too many options when they are on the move or under time pressure will only confuse them and become a burden to them.

Mapquest mobile form to get directions

Mapquest mobile form to get directions

What Mapquest does is to combine these three input options into one field on their mobile search form. Users can freely type in either a specific address or a business name in the field. When the field is on focus, the option to use users’ current location appears. None of the input options are being removed and the form is much cleaner and easier to use.

However, be wary when applying this technique. Make sure it is clear what users can do with the field and what they could enter.

Improvise

Europcar has a long drop down listing 139 pick up countries

Europcar has a long drop down listing 139 pick up countries

Europcar uses location detection to shorten the drop down for pick up country

Europcar uses location detection to shorten the drop down for pick up country

There are many built-in features that are available on mobile devices, such as location detection via GPS (Global Positioning System) satellites or compass features. Make good use of these features to simplify your mobile form input.

Europcar has a rather long list of pick up countries (139 in total) on their car rental form. Knowing that such a long drop down menu would not work well for mobile devices, they striped down the country list into 40 primary or most popular countries to make the selection easier and quicker.

They didn’t just stop there. They took advantage of mobile devices’ built in location based feature to give users an option to allow the device to locate their current location and to find the nearest pick up station.

It not only simplifies the form input, but also matches mobile users’ need in terms of how and when they would use the booking form (find the closest station and make a booking there and then).

Break into small steps

Due to possible slow internet connections when using mobile devices, it is often recommended to have the minimal number of page loads as possible. There are exceptions where this rule can be broken to improve input selections.

AirAsia categorises their ‘fly from’ cities into related countries in their drop down

AirAsia categorises their ‘fly from’ cities into related countries in their drop down

On their desktop version, AirAsia.com divides their 80 cities ‘fly from’ destinations into twenty five countries. This works well because it enables users to quickly scan cities which the airline flies from for each country, and makes the selection easier. However, such a mega drop down menu will not work well in a mobile form.

To apply the same concept (dividing fly out destinations into countries) on their mobile forms, AirAsia breaks the list into a few screens. The default first screen is set to be Malaysia (as AirAsia is a Malaysian low-cost airline) with a list of cities that they fly from. Below the list is the countries list. If users select one of the countries, a new screen will be shown with a list of cities for that country.

AirAsia splits its long drop downs into a few smaller steps to simplify the destination selections

AirAsia splits its long drop downs into a few smaller steps to simplify the destination selections

Despite the fact that this approach would require a few additional page loads, it allows users to focus one step at a time without overwhelming them with a long, complicated form.

Splitting a long form into a few smaller steps could be a good approach to make mobile forms easier to use. But, don’t over do it. You don’t want your users to feel like it’s a never-ending task. Additionally, if you use this technique, try reducing unnecessary elements on each page to avoid slow page downloads so the whole process feels smooth and uninterrupted to the users.

Use appropriate input elements & menu controls

Another strategy that can be used when redesigning your form for mobile devices is to replace one type of control with another which could simplify the form and its interaction.

Expedia hotel booking form: Replacing drop downs to links

Expedia hotel booking form: Replacing drop downs to links

To search for a hotel on the Expedia site, users are able to search for hotels by entering a city name, an airport name, an attraction or a U.S address. These options are presented in a drop down. Depending on which option is selected, the labels and fields shown are varied. Instead of using the same drop down menu in their mobile version, Expedia has chosen to show these options via three separate links. This design enables users to quickly scan through the available options and minimises the number of clicks required to select an option.

However, it has to be designed carefully as showing a long list of links on top of the page could potentially push the form itself down the screen. You would probably want to be able to at least show the first two or three fields on the screen.

Shangri-La hotel booking form: Replacing a list of radio buttons with a short drop down

Shangri-La hotel booking form: Replacing a list of radio buttons with a short drop down

When booking hotel rooms via Shangri-La websites, users are given an option to select the type of offers they might have to get a special room rate. The desktop version shows the options in a series of radio buttons. To simplify the form for the mobile version, Shangri-La uses a drop down for the selections. It fits nicely in this case because:

  • Presenting a list of radio buttons on a mobile device (even though there are only four of them) can make the form looks longer and more cluttered
  • This is an optional field and it’s only applicable to a certain group of users. Therefore it’s fine to make it visually less apparent

Mobile users often need to complete a form there and then (which means it has to be quick). Hence, prioritise mandatory content and fields, and avoid over emphasizing optional fields or those which are only useful for a very small group of users. Even better, be ruthless – remove the latter completely from the mobile version (see the second point above on ‘Remove’).

KLM flight tracker: Replacing a long drop down menu with a free text predictive search

KLM flight tracker: Replacing a long drop down menu with a free text predictive search

On the KLM site, instead of checking flight status by entering a flight number, users are also able to search by arrival and departure airports. Their desktop version offers a drop down for airport selection and it consists of 151 airports. Knowing that a long drop down list will not work well on mobile devices, KLM has replaced it with a predictive text input field. This free text input approach works well in this case as users always know what they are looking for and the airport name they need to enter. Users are not overwhelmed with the long list and this simplifies the interaction. See the next section on choosing the appropriate type of list selection.

Choose appropriate list selections

There are two main ways to present a list selection: locked drop down (in alphabetical or non alphabetical order) and open predictive search. Both of them have pros and cons. They are suitable for certain situations depending on the field (e.g. functions) and selections (e.g. number of selections available, the text length of each selection, how the list can be ordered).

Example where a locked drop down is suitable and not suitable to be used

Example where a locked drop down is suitable and not suitable to be used

Locked drop down: Suitable

  • Locked drop down menus are only suitable to be used when users know exactly what they are looking for.
  • It also works well for lists which make sense in alphabetical or chronological order, such as countries, numbers or dates. Users know roughly how much they need to ‘scroll’ down to get to the selection they want

Locked drop down: Not suitable

  • Avoid using locked drop down menus when the list is in a random order and users are unlikely to know what they are looking for or what the available options are.

    Tripadvisor’s attraction look up form is an example where locked drop down is not suitable. There are 30 attraction types which users can choose from. The problem is that, unlike country lists, users do not know what the available options are and do not know what they are looking for. Users would have to go through the whole list from top to bottom and might have to go back to the top of the list again to choose the one which matches their choice the best.

  • The locked drop down is also not suitable if you have lengthy description of items.

    Due to restricted screen area and one row display for each item, long descriptions would be shortened and broken automatically using ‘…..’. Users would not be able to see the complete description and would have to guess what each option is.

Example where a free text predictive search is suitable and not suitable to be used

Example where a free text predictive search is suitable and not suitable to be used

Open predictive search: Suitable

  • Free text predictive search is more appropriate to be used when you have long option descriptions.
    Unlike locked drop down, individual items can be displayed in more than a row. It’s up to you (designers or developers) to make the list easy to scan.
  • If you have a long list where a long drop down might not be appropriate or when the list is not possible (or does not make sense) to be arranged in a specific order, the open predictive search approach would be a better option.
  • Users roughly know what they are looking for to be able to type at least a few characters in the free text field.

Locked drop down: Not suitable

  • When using the open predictive search, it’s worth bearing in mind that your predictive search list should not be too long. Users scroll down to go through the list and if they can’t find what they are looking for, they would have to scroll back up to the text field to retype their keywords. A long predictive search list will make it into a time consuming and laborious task.

Set sensible defaults

Mobile devices are often used when users are on the go or under time pressure. They want to be able to get the task done or view their search results quickly and accurately. If possible, provide some default selections where appropriate based on the context in which your forms are used.

Each form has a different use case. For example, when using a mobile train times look up form, it’s likely that users want to find out the timetable information for trains which depart on the same day and anytime after their search time. Therefore, it makes sense to set the departure date as ‘today’ and the next train time (or ‘evening’ if users are using it at 6pm) as the default departing time.Partick Rhone pointed out the advantages of setting sensible defaults:

Sensible defaults can reduce friction and provide simplicity anywhere one can think to apply them. They are the bedrock of minimalist practice and a quiet mind.

In conclusion

The bottom line on designing for mobile forms is this – First, understand when and why your users use your form on mobile devices. Second, identify the primary content or fields for the tasks. Whilst you are doing this, you might need to be ruthless to omit elements which do not carry important functions. Then use the strategies above to work out the best ways to present each of the fields for an ideal interaction. At this point, you would need to consider the constraints of the mobile environment.

Remember, the ultimate objective of your mobile users is to complete their task (whatever they are) efficiently and effortlessly.

March 01 2011

14:00

Considerations for Mobile Design (Part 2): Dimensions

This post is a continuation of our series, “Considerations for Mobile Design“. You can read Part 1: Speed, here.

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

February 22 2011

13:30

Considerations for Mobile Design (Part 1): Speed

Considerations for Mobile Design: Speed

How do traditional screen web designs translate on handheld devices? This series aims to identify constraints in mobile web design so we can better serve our users.

I remember when I first dabbled in Mobile Web Design. The year was 2006, and hype for the recently announced “.mobi” top level domain (TLD) was strong. Armed with my new BlackBerry Pearl 8100, I was ready to try my hand at building a mobile experience on its whopping 240x260px display.

That part of my life was short-lived. Between the sudden emergence of media-rich sites such as YouTube and Facebook, and the ensuing browser wars (that year marked the launch of both Firefox 2 and IE 7), my excitement for Mobile Web quickly diminished. To me, mobile wasn’t web on the go; it was the web of last resort.

Fast-forward five years and mobile had begun to gain traction. Competition in the mobile broadband market resulted in pretty decent download speeds. Furthermore, top-of-the-line devices boasted higher resolutions (and even came with color spaces that rivaled desktop monitors). The icing on the cake? Support for web standards across these devices matured greatly, which meant that design wasn’t as much a shot-in-the-dark as it used to be. Cameron Moll even wrote a book on the subject.

As it turns out, the Mobile Web is no longer the web of last resort. It’s the web of accommodation. Adapting to our busy lifestyles, it’s ready at the touch of a button.

Let’s get considerate

This series—Considerations for Mobile Design—aims to help experience designers understand how the transition to mobile affects their audience and, in turn, their designs. In the beginning, we’ll take a look at the rules governing today’s mobile sites. In part two, we’ll discuss how expectations might change as the underlying technology continues to improve. Along the way, we’ll cover mobile-specific interaction design, mobile device constraints, and building websites that are responsive, working well on both handheld devices and traditional screen displays. Ready? Let’s get started.

Speed. It’s important.

Let’s begin with an exposition.

Two trains leave from the same points of origin, traveling towards the same destination. They are identical in every way except one: the first train travels twice as fast as the second. Except for the occasional passenger who’s out to see the scenery, it’s obvious that the first train is the better choice when it comes to reaching your destination.

This illustration is more or less straightforward (especially in our case when users are watching a progress bar instead of some beautiful scenery), but it’s still an important concept. Our users use the web to get things done. As a consequence, time is of the essence. The choice of which specific tool (sites) they use is heavily influenced by just how quickly that tool accomplishes their goals. Therefore, optimize your websites to load as quickly as possible.

The choice of what specific site a user chooses to use is heavily influenced by how quicly a site allows them to accomplish a goal.

In the past, we’ve gone over some important ways to minimize load times for faster user experiences. We’ve also shown you how you can optimize your images for the web. I won’t spend too much time here explaining basic concepts for improving a web page’s load time. If you’d like to explore this concept further, be sure to check out Steve Souder’s book, High Performance Web Sites.

Because mobile devices transmit data at slower rates of speed, the weight of a website is even more critical. While many mobile devices are now offering packages with even faster transfer rates, it’s not uncommon for users to have sub-256Kbps connections, which means we need to make every bit count.

Since we’re talking about some pretty nuanced stuff here, let’s take a second to address some of the basics.

Kbps vs. KBps vs. Mbps

The following are some common units of measurement with regards to data transfer online.

  • Kb: Kilobit (128 bytes)
  • KB: Kilobyte (8 Kilobits)
  • Mb: Megabit (128KB or 1024Kb)
  • MB: Megabyte (8Mb or 1024KB or 8192Kb)

People often get confused when working with Kilobytes vs. Kilobits, and misunderstand how fast download speeds are as a result. If your download rate is 256Kbps (Kilobits per second), you will not download a 256KB (Kilobyte) file in 1 second. Since there are 8 Kilobits in 1 Kilobyte (there are 8 bits in a byte), a 256Kbps download rate take about 8 seconds to download a 256KB file.

To convert Kbps to speeds you may be more comfortable working with, you could do the following:

  • Kbps to KBps: Kbps / 8 = KBps
  • Kbps to Mbps: (Kbps / 8) / 128 = Mbps

Speeds change but expectation is constant

Ten years ago, 256Kbps would have suited most people perfectly. In a world where 150Kbps-1Mbps download rate was considered “normal” for high speed—and a typical webpage weighed in at under 100Kb—256Kbps meant that websites loaded almost instantaneously.

According to researchers from the University of Twente, nearly all web traffic in 2000 was caused by plain ol’ images and text. That number changed dramatically by 2007, though, when most online traffic became dominated by photos, videos, and other binary downloads. As a consequence, the mean response size (size of files transmitted over the web) increased by over 500% in that period of seven years.

Between  2005 & 2009, the number of mobile devices with connection speeds over 200kbps increased by nearly 4000x.

So much has changed in how people use the web over the past decade. Today we stream video; present graphically rich interfaces; and use relatively heavy client-side scripts (relative to ten years ago) to tie it all together. But despite all this, the relative speed of the user’s experience has remained constant, or even improved. How could this be?

In 2010, the United States FCC defined “Basic Broadband” as a data transmission speed of at least 4 Mbps downstream. Coupled with the fact that the the average page size that year was 320KB, a typical load time for a web page in 2010 was under 1 second. In other words, we’re still loading modern, richly textured web applications instantly, or at least fast enough that it doesn’t bother anyone.

Whether you’re designing a web application in 2011, or an entirely new experience in 2020, users have come to expect a quick and responsive experience. If a user has a choice between two tools that accomplish the same task, and one does so faster than the other, that’s the one they are more likely to choose.

Translating the experience to mobile devices

If we serve the same heavy weight user experiences to mobile devices that we do on our high-bandwidth devices, we run the risk of causing long load times and unresponsive websites. To demonstrate how detrimental this could be to the potential experience, observe the weight of the following sites, and their approximate load times given a 256Kbps download speed:

Website Load Times

Website Page Size 256Kbps (32KBps) Download Rate 4Mbps (512KBps) Download Rate CNN.com 1.07MB 34.2 seconds 2.1 seconds Reuters.com 264.37KB 8.2 seconds .5 seconds BBC.co.uk 193.49KB 6 seconds .4 seconds YouTube.com 400.42KB 12.5 seconds .8 seconds Facebook.com 360.6KB 11.3 seconds .7 seconds

These figures reveal how our expectations of websites have changed. Some of the most visited websites in the world today would have taken 10+ seconds to download on broadband standards of the early 2000′s. These standards are going to continue to change, and we’ll continue to demand more from our web apps as technology improves. It’s important that we scale our experience given the technology available to our users.

If we assume that a user is more accustomed to browsing the web from a desktop, we can use that experience as an “okay” benchmark for how long a user is willing to wait on a mobile device.

So, how long does the same website take to load on a standard mobile broadband speed compared to a basic broadband speed (4Mbps)? The table below details how the same five sites previously examined load their mobile counterparts.

Mobile Website Load Times

Website Page Size 256Kbps (32KBps) Download Rate 987Kbps (123KBps) Download Rate m.CNN.com 77.95KB 2.6 seconds .6 seconds mobile.Reuters.com 36KB 1.2 seconds .3 seconds BBC.co.uk/mobile 31.14KB 1 second .3 seconds m.YouTube.com 21.76KB .7 seconds .2 seconds m.Facebook.com 17.4KB .6 seconds .1 second

According to a study by PCWorld and Novarum Inc in 2009-2010, the avg. download speed between the AT&T, Sprint, T-Mobile, and Verizon 3G networks was 987Kbps. Some providers may throttle users that exceed a monthly data limit to significantly lower data rates (ie: T-Mobile reduces download speeds after customers reach a 5GB limit).

The mobile versions of these sites strive to minimize load time on mobile devices by drastically reducing their total weight. When you compare the results to the default site on a basic broadband connection, you’ll find that there is little difference.

Consider what would happen if Facebook didn’t have a mobile version of their site. How long would the load time be? How much of that load time would be wasted if the device used had a poor resolution? or if it lacked multi-touch ? While devices such as the the iPhone have done an outstanding job of building systems for zooming and panning traditional websites, other devices are still catching up. If users wait a long time for a website they ultimately can’t use, their experience is ruined.

The bottom line is that most Facebook users expect very quick load times on their desktops. Asking those same users to wait 11 seconds for a page to load is simply unacceptable.

Closing thoughts

And on that note, we’re going to close this part of our series. When we resume this series, we’ll discuss more specific design constraints, how to design for specific mobile devices, and emergine conventions and frameworks that will help us build more powerful mobile experiences. Before I leave you, though, there are a few resources worth mentioning:

  • While not strictly mobile-related, the FCC released a report in 2010 on the Status of Internet Access Services. The document contains lots of very insightful statistics in regards to how speed and access has changed over the past decade for residential users.
  • I wasn’t able to find a dedicated calculate for finding page load times given certain connection speeds (if you have one, please leave it in the comments!). However, you can find out the total size of all files loaded on a website pretty easily with Firebug. Plug the total page size into one of the formulas above, and you can get a good idea of how long it should take to download all items on a page. Please note that this system does not take latency into account, so it should not be thought of as an accurate way to find the total time a page will take to load.

January 12 2011

15:39

Responsive Web Design: What It Is and How To Use It

Advertisement in Responsive Web Design: What It Is and How To Use It
 in Responsive Web Design: What It Is and How To Use It  in Responsive Web Design: What It Is and How To Use It  in Responsive Web Design: What It Is and How To Use It

Almost every new client these days wants a mobile version of their website. It’s practically essential after all: one design for the BlackBerry, another for the iPhone, the iPad, netbook, Kindle — and all screen resolutions must be compatible, too. In the next five years, we’ll likely need to design for a number of additional inventions. When will the madness stop? It won’t, of course.

In the field of Web design and development, we’re quickly getting to the point of being unable to keep up with the endless new resolutions and devices. For many websites, creating a website version for each resolution and new device would be impossible, or at least impractical. Should we just suffer the consequences of losing visitors from one device, for the benefit of gaining visitors from another? Or is there another option?

Responsive Web design is the approach that suggests that design and development should respond to the user’s behavior and environment based on screen size, platform and orientation. The practice consists of a mix of flexible grids and layouts, images and an intelligent use of CSS media queries. As the user switches from their laptop to iPad, the website should automatically switch to accommodate for resolution, image size and scripting abilities. In other words, the website should have the technology to automatically respond to the user’s preferences. This would eliminate the need for a different design and development phase for each new gadget on the market.

The Concept Of Responsive Web Design

Ethan Marcotte wrote an introductory article about the approach, “Responsive Web Design,” for A List Apart. It stems from the notion of responsive architectural design, whereby a room or space automatically adjusts to the number and flow of people within it:

“Recently, an emergent discipline called “responsive architecture” has begun asking how physical spaces can respond to the presence of people passing through them. Through a combination of embedded robotics and tensile materials, architects are experimenting with art installations and wall structures that bend, flex, and expand as crowds approach them. Motion sensors can be paired with climate control systems to adjust a room’s temperature and ambient lighting as it fills with people. Companies have already produced “smart glass technology” that can automatically become opaque when a room’s occupants reach a certain density threshold, giving them an additional layer of privacy.”

Transplant this discipline onto Web design, and we have a similar yet whole new idea. Why should we create a custom Web design for each group of users; after all, architects don’t design a building for each group size and type that passes through it? Like responsive architecture, Web design should automatically adjust. It shouldn’t require countless custom-made solutions for each new category of users.

Obviously, we can’t use motion sensors and robotics to accomplish this the way a building would. Responsive Web design requires a more abstract way of thinking. However, some ideas are already being practiced: fluid layouts, media queries and scripts that can reformat Web pages and mark-up effortlessly (or automatically).

But responsive Web design is not only about adjustable screen resolutions and automatically resizable images, but rather about a whole new way of thinking about design. Let’s talk about all of these features, plus additional ideas in the making.

Adjusting Screen Resolution

With more devices come varying screen resolutions, definitions and orientations. New devices with new screen sizes are being developed every day, and each of these devices may be able to handle variations in size, functionality and even color. Some are in landscape, others in portrait, still others even completely square. As we know from the rising popularity of the iPhone, iPad and advanced smartphones, many new devices are able to switch from portrait to landscape at the user’s whim. How is one to design for these situations?

Portrait-landscape in Responsive Web Design: What It Is and How To Use It

In addition to designing for both landscape and portrait (and enabling those orientations to possibly switch in an instant upon page load), we must consider the hundreds of different screen sizes. Yes, it is possible to group them into major categories, design for each of them, and make each design as flexible as necessary. But that can be overwhelming, and who knows what the usage figures will be in five years? Besides, many users do not maximize their browsers, which itself leaves far too much room for variety among screen sizes.

Morten Hjerde and a few of his colleagues identified statistics on about 400 devices sold between 2005 and 2008. Below are some of the most common:

Sizes in Responsive Web Design: What It Is and How To Use It

Since then even more devices have come out. It’s obvious that we can’t keep creating custom solutions for each one. So, how do we deal with the situation?

Part of the Solution: Flexible Everything

A few years ago, when flexible layouts were almost a “luxury” for websites, the only things that were flexible in a design were the layout columns (structural elements) and the text. Images could easily break layouts, and even flexible structural elements broke a layout’s form when pushed enough. Flexible designs weren’t really that flexible; they could give or take a few hundred pixels, but they often couldn’t adjust from a large computer screen to a netbook.

Now we can make things more flexible. Images can be automatically adjusted, and we have workarounds so that layouts never break (although they may become squished and illegible in the process). While it’s not a complete fix, the solution gives us far more options. It’s perfect for devices that switch from portrait orientation to landscape in an instant or for when users switch from a large computer screen to an iPad.

In Ethan Marcotte’s article, he created a sample Web design that features this better flexible layout:

Moreflexible in Responsive Web Design: What It Is and How To Use It

The entire design is a lovely mix of fluid grids, fluid images and smart mark-up where needed. Creating fluid grids is fairly common practice, and there are a number of techniques for creating fluid images:

For more information on creating fluid websites, be sure to look at the book “Flexible Web Design: Creating Liquid and Elastic Layouts with CSS” by Zoe Mickley Gillenwater, and download the sample chapter “Creating Flexible Images.” In addition, Zoe provides the following extensive list of tutorials, resources, inspiration and best practices on creating flexible grids and layouts: “Essential Resources for Creating Liquid and Elastic Layouts.”

While from a technical perspective this is all easily possible, it’s not just about plugging these features in and being done. Look at the logo in this design, for example:

Croppinglogo in Responsive Web Design: What It Is and How To Use It

If resized too small, the image would appear to be of low quality, but keeping the name of the website visible and not cropping it off was important. So, the image is divided into two: one (of the illustration) set as a background, to be cropped and to maintain its size, and the other (of the name) resized proportionally.

<h1 id="logo"><a href="#"><img src="site/logo.png" alt="The Baker Street Inquirer" /></a></h1>

Above, the h1 element holds the illustration as a background, and the image is aligned according to the container’s background (the heading).

This is just one example of the kind of thinking that makes responsive Web design truly effective. But even with smart fixes like this, a layout can become too narrow or short to look right. In the logo example above (although it works), the ideal situation would be to not crop half of the illustration or to keep the logo from being so small that it becomes illegible and “floats” up.

Flexible Images

One major problem that needs to be solved with responsive Web design is working with images. There are a number of techniques to resize images proportionately, and many are easily done. The most popular option, noted in Ethan Marcotte’s article on fluid images but first experimented with by Richard Rutter, is to use CSS’s max-width for an easy fix.

img { max-width: 100%; }

As long as no other width-based image styles override this rule, every image will load in its original size, unless the viewing area becomes narrower than the image’s original width. The maximum width of the image is set to 100% of the screen or browser width, so when that 100% becomes narrower, so does the image. Essentially, as Jason Grigsby noted, “The idea behind fluid images is that you deliver images at the maximum size they will be used at. You don’t declare the height and width in your code, but instead let the browser resize the images as needed while using CSS to guide their relative size”. It’s a great and simple technique to resize images beautifully.

Note that max-width is not supported in IE, but a good use of width: 100% would solve the problem neatly in an IE-specific style sheet. One more issue is that when an image is resized too small in some older browsers in Windows, the rendering isn’t as clear as it ought to be. There is a JavaScript to fix this issue, though, found in Ethan Marcotte’s article.

While the above is a great quick fix and good start to responsive images, image resolution and download times should be the primary considerations. While resizing an image for mobile devices can be very simple, if the original image size is meant for large devices, it could significantly slow download times and take up space unnecessarily.

Filament Group’s Responsive Images

This technique, presented by the Filament Group, takes this issue into consideration and not only resizes images proportionately, but shrinks image resolution on smaller devices, so very large images don’t waste space unnecessarily on small screens. Check out the demo page here.

Filamentgroup in Responsive Web Design: What It Is and How To Use It

This technique requires a few files, all of which are available on Github. First, a JavaScript file (rwd-images.js), the .htaccess file and an image file (rwd.gif). Then, we can use just a bit of HTML to reference both the larger and smaller resolution images: first, the small image, with an .r prefix to clarify that it should be responsive, and then a reference to the bigger image using data-fullsrc.

<img src="smallRes.jpg" data-fullsrc="largeRes.jpg">

The data-fullsrc is a custom HTML5 attribute, defined in the files linked to above. For any screen that is wider than 480 pixels, the larger-resolution image (largeRes.jpg) will load; smaller screens wouldn’t need to load the bigger image, and so the smaller image (smallRes.jpg) will load.

The JavaScript file inserts a base element that allows the page to separate responsive images from others and redirects them as necessary. When the page loads, all files are rewritten to their original forms, and only the large or small images are loaded as necessary. With other techniques, all higher-resolution images would have had to be downloaded, even if the larger versions would never be used. Particularly for websites with a lot of images, this technique can be a great saver of bandwidth and loading time.

This technique is fully supported in modern browsers, such as IE8+, Safari, Chrome and Opera, as well as mobile devices that use these same browsers (iPad, iPhone, etc.). Older browsers and Firefox degrade nicely and still resize as one would expect of a responsive image, except that both resolutions are downloaded together, so the end benefit of saving space with this technique is void.

Stop iPhone Simulator Image Resizing

One nice thing about the iPhone and iPod Touch is that Web designs automatically rescale to fit the tiny screen. A full-sized design, unless specified otherwise, would just shrink proportionally for the tiny browser, with no need for scrolling or a mobile version. Then, the user could easily zoom in and out as necessary.

There was, however, one issue this simulator created. When responsive Web design took off, many noticed that images were still changing proportionally with the page even if they were specifically made for (or could otherwise fit) the tiny screen. This in turn scaled down text and other elements.

Iphonescale in Responsive Web Design: What It Is and How To Use It
(Image: Think Vitamin | Website referenced: 8 Faces)

Because this works only with Apple’s simulator, we can use an Apple-specific meta tag to fix the problem, placing it below the website’s <head> section. Thanks to Think Vitamin’s article on image resizing, we have the meta tag below:

<meta name="viewport" content="width=device-width; initial-scale=1.0">

Setting the initial-scale to 1 overrides the default to resize images proportionally, while leaving them as is if their width is the same as the device’s width (in either portrait or lanscape mode). Apple’s documentation has a lot more information on the viewport meta tag.

Custom Layout Structure

For extreme size changes, we may want to change the layout altogether, either through a separate style sheet or, more efficiently, through a CSS media query. This does not have to be troublesome; most of the styles can remain the same, while specific style sheets can inherit these styles and move elements around with floats, widths, heights and so on.

For example, we could have one main style sheet (which would also be the default) that would define all of the main structural elements, such as #wrapper, #content, #sidebar, #nav, along with colors, backgrounds and typography. Default flexible widths and floats could also be defined.

If a style sheet made the layout too narrow, short, wide or tall, we could then detect that and switch to a new style sheet. This new child style sheet would adopt everything from the default style sheet and then just redefine the layout’s structure.

Here is the style.css (default) content:

/* Default styles that will carry to the child style sheet */

html,body{
   background...
   font...
   color...
}

h1,h2,h3{}
p, blockquote, pre, code, ol, ul{}

/* Structural elements */
#wrapper{
	width: 80%;
	margin: 0 auto;

	background: #fff;
	padding: 20px;
}

#content{
	width: 54%;
	float: left;
	margin-right: 3%;
}

#sidebar-left{
	width: 20%;
	float: left;
	margin-right: 3%;
}

#sidebar-right{
	width: 20%;
	float: left;
}

Here is the mobile.css (child) content:

#wrapper{
	width: 90%;
}

#content{
	width: 100%;
}

#sidebar-left{
	width: 100%;
	clear: both;

	/* Additional styling for our new layout */
	border-top: 1px solid #ccc;
	margin-top: 20px;
}

#sidebar-right{
	width: 100%;
	clear: both;

	/* Additional styling for our new layout */
	border-top: 1px solid #ccc;
	margin-top: 20px;
}

Movingcontent in Responsive Web Design: What It Is and How To Use It

Media Queries

CSS3 supports all of the same media types as CSS 2.1, such as screen, print and handheld, but has added dozens of new media features, including max-width, device-width, orientation and color. New devices made after the release of CSS3 (such as the iPad and Android devices) will definitely support media features. So, calling a media query using CSS3 features to target these devices would work just fine, and it will be ignored if accessed by an older computer browser that does not support CSS3.

In Ethan Marcotte’s article, we see an example of a media query in action:

<link rel="stylesheet" type="text/css"
	media="screen and (max-device-width: 480px)"
	href="shetland.css" />

This media query is fairly self-explanatory: if the browser displays this page on a screen (rather than print, etc.), and if the width of the screen (not necessarily the viewport) is 480 pixels or less, then load shetland.css.

New CSS3 features also include orientation (portrait vs. landscape), device-width, min-device-width and more. Look at “The Orientation Media Query” for more information on setting and restricting widths based on these media query features.

One can create multiple style sheets, as well as basic layout alterations defined to fit ranges of widths — even for landscape vs. portrait orientations. Be sure to look at the section of Ethan Marcotte’s article entitled “Meet the media query” for more examples and a more thorough explanation.

Multiple media queries can also be dropped right into a single style sheet, which is the most efficient option when used:

/* Smartphones (portrait and landscape) ----------- */
@media only screen
and (min-device-width : 320px)
and (max-device-width : 480px) {
/* Styles */
}

/* Smartphones (landscape) ----------- */
@media only screen
and (min-width : 321px) {
/* Styles */
}

/* Smartphones (portrait) ----------- */
@media only screen
and (max-width : 320px) {
/* Styles */
}

The code above is from a free template for multiple media queries between popular devices by Andy Clark. See the differences between this approach and including different style sheet files in the mark-up as shown in the post “Hardboiled CSS3 Media Queries.”

CSS3 Media Queries

Above are a few examples of how media queries, both from CSS 2.1 and CSS3 could work. Let’s now look at some specific how-to’s for using CSS3 media queries to create responsive Web designs. Many of these uses are relevant today, and all will definitely be usable in the near future.

The min-width and max-width properties do exactly what they suggest. The min-width property sets a minimum browser or screen width that a certain set of styles (or separate style sheet) would apply to. If anything is below this limit, the style sheet link or styles will be ignored. The max-width property does just the opposite. Anything above the maximum browser or screen width specified would not apply to the respective media query.

Note in the examples below that we’re using the syntax for media queries that could be used all in one style sheet. As mentioned above, the most efficient way to use media queries is to place them all in one CSS style sheet, with the rest of the styles for the website. This way, multiple requests don’t have to be made for multiple style sheets.

@media screen and (min-width: 600px) {
     .hereIsMyClass {
          width: 30%;
          float: right;
     }
}

The class specified in the media query above (hereIsMyClass) will work only if the browser or screen width is above 600 pixels. In other words, this media query will run only if the minimum width is 600 pixels (therefore, 600 pixels or wider).

@media screen and (max-width: 600px) {
     .aClassforSmallScreens {
          clear: both;
		  font-size: 1.3em;
     }
}

Now, with the use of max-width, this media query will apply only to browser or screen widths with a maximum width of 600 pixels or narrower.

While the above min-width and max-width can apply to either screen size or browser width, sometimes we’d like a media query that is relevant to device width specifically. This means that even if a browser or other viewing area is minimized to something smaller, the media query would still apply to the size of the actual device. The min-device-width and max-device-width media query properties are great for targeting certain devices with set dimensions, without applying the same styles to other screen sizes in a browser that mimics the device’s size.

@media screen and (max-device-width: 480px) {
     .classForiPhoneDisplay {
          font-size: 1.2em;
     }
}
@media screen and (min-device-width: 768px) {
     .minimumiPadWidth {
          clear: both;
		  margin-bottom: 2px solid #ccc;
     }
}

There are also other tricks with media queries to target specific devices. Thomas Maier has written two short snippets and explanations for targeting the iPhone and iPad only:

For the iPad specifically, there is also a media query property called orientation. The value can be either landscape (horizontal orientation) or portrait (vertical orientation).

@media screen and (orientation: landscape) {
     .iPadLandscape {
          width: 30%;
		  float: right;
     }
}
@media screen and (orientation: portrait) {
     .iPadPortrait {
          clear: both;
     }
}

Unfortunately, this property works only on the iPad. When determining the orientation for the iPhone and other devices, the use of max-device-width and min-device-width should do the trick.

There are also many media queries that make sense when combined. For example, the min-width and max-width media queries are combined all the time to set a style specific to a certain range.

@media screen and (min-width: 800px) and (max-width: 1200px) {
     .classForaMediumScreen {
          background: #cc0000;
          width: 30%;
          float: right;
     }
}

The above code in this media query applies only to screen and browser widths between 800 and 1200 pixels. A good use of this technique is to show certain content or entire sidebars in a layout depending on how much horizontal space is available.

Some designers would also prefer to link to a separate style sheet for certain media queries, which is perfectly fine if the organizational benefits outweigh the efficiency lost. For devices that do not switch orientation or for screens whose browser width cannot be changed manually, using a separate style sheet should be fine.

You might want, for example, to place media queries all in one style sheet (as above) for devices like the iPad. Because such a device can switch from portrait to landscape in an instant, if these two media queries were placed in separate style sheets, the website would have to call each style sheet file every time the user switched orientations. Placing a media query for both the horizontal and vertical orientations of the iPad in the same style sheet file would be far more efficient.

Another example is a flexible design meant for a standard computer screen with a resizable browser. If the browser can be manually resized, placing all variable media queries in one style sheet would be best.

Nevertheless, organization can be key, and a designer may wish to define media queries in a standard HTML link tag:

<link rel="stylesheet" media="screen and (max-width: 600px)" href="small.css" />
<link rel="stylesheet" media="screen and (min-width: 600px)" href="large.css" />
<link rel="stylesheet" media="print" href="print.css" />

JavaScript

Another method that can be used is JavaScript, especially as a back-up to devices that don’t support all of the CSS3 media query options. Fortunately, there is already a pre-made JavaScript library that makes older browsers (IE 5+, Firefox 1+, Safari 2) support CSS3 media queries. If you’re already using these queries, just grab a copy of the library, and include it in the mark-up: css3-mediaqueries.js.

In addition, below is a sample jQuery snippet that detects browser width and changes the style sheet accordingly — if one prefers a more hands-on approach:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script>

<script type="text/javascript">
	$(document).ready(function(){
		$(window).bind("resize", resizeWindow);
		function resizeWindow(e){
			var newWindowWidth = $(window).width();

			// If width width is below 600px, switch to the mobile stylesheet
			if(newWindowWidth < 600){ 				$("link[rel=stylesheet]").attr({href : "mobile.css"});	 			} 			// Else if width is above 600px, switch to the large stylesheet 			else if(newWindowWidth > 600){
				$("link[rel=stylesheet]").attr({href : "style.css"});
			}
		}
	});
</script>

There are many solutions for pairing up JavaScript with CSS media queries. Remember that media queries are not an absolute answer, but rather are fantastic options for responsive Web design when it comes to pure CSS-based solutions. With the addition of JavaScript, we can accomodate far more variations. For detailed information on using JavaScript to mimic or work with media queries, look at “Combining Media Queries and JavaScript.”

Showing or Hiding Content

It is possible to shrink things proportionally and rearrange elements as necessary to make everything fit (reasonably well) as a screen gets smaller. It’s great that that’s possible, but making every piece of content from a large screen available on a smaller screen or mobile device isn’t always the best answer. We have best practices for mobile environments: simpler navigation, more focused content, lists or rows instead of multiple columns.

Diggmobile in Responsive Web Design: What It Is and How To Use It

Responsive Web design shouldn’t be just about how to create a flexible layout on a wide range of platforms and screen sizes. It should also be about the user being able to pick and choose content. Fortunately, CSS has been allowing us to show and hide content with ease for years!

display: none;

Either declare display: none for the HTML block element that needs to be hidden in a specific style sheet or detect the browser width and do it through JavaScript. In addition to hiding content on smaller screens, we can also hide content in our default style sheet (for bigger screens) that should be available only in mobile versions or on smaller devices. For example, as we hide major pieces of content, we could replace them with navigation to that content, or with a different navigation structure altogether.

Note that we haven’t used visibility: hidden here; this just hides the content (although it is still there), whereas the display property gets rid of it altogether. For smaller devices, there is no need to keep the mark-up on the page — it just takes up resources and might even cause unnecessary scrolling or break the layout.

Showinghidingcontent in Responsive Web Design: What It Is and How To Use It

Here is our mark-up:

<p class="sidebar-nav"><a href="#">Left Sidebar Content</a> | <a href="#">Right Sidebar Content</a></p>

<div id="content">
	<h2>Main Content</h2>
</div>

<div id="sidebar-left">
	<h2>A Left Sidebar</h2>

</div>

<div id="sidebar-right">
	<h2>A Right Sidebar</h2>
</div>

In our default style sheet below, we have hidden the links to the sidebar content. Because our screen is large enough, we can display this content on page load.

Here is the style.css (default) content:

#content{
	width: 54%;
	float: left;
	margin-right: 3%;
}

#sidebar-left{
	width: 20%;
	float: left;
	margin-right: 3%;
}

#sidebar-right{
	width: 20%;
	float: left;
}
.sidebar-nav{display: none;}

Now, we hide the two sidebars (below) and show the links to these pieces of content. As an alternative, the links could call to JavaScript to just cancel out the display: none when clicked, and the sidebars could be realigned in the CSS to float below the content (or in another reasonable way).

Here is the mobile.css (simpler) content:

#content{
	width: 100%;
}

#sidebar-left{
	display: none;
}

#sidebar-right{
	display: none;
}
.sidebar-nav{display: inline;}

With the ability to easily show and hide content, rearrange layout elements and automatically resize images, form elements and more, a design can be transformed to fit a huge variety of screen sizes and device types. As the screen gets smaller, rearrange elements to fit mobile guidelines; for example, use a script or alternate style sheet to increase white space or to replace image navigation sources on mobile devices for better usability (icons would be more beneficial on smaller screens).

Below are a couple of relevant resources:

Touchscreens vs. Cursors

Touchscreens are becoming increasingly popular. Assuming that smaller devices are more likely to be given touchscreen functionality is easy, but don’t be so quick. Right now touchscreens are mainly on smaller devices, but many laptops and desktops on the market also have touchscreen capability. For example, the HP Touchsmart tm2t is a basic touchscreen laptop with traditional keyboard and mouse that can transform into a tablet.

Touchscreen in Responsive Web Design: What It Is and How To Use It

Touchscreens obviously come with different design guidelines than purely cursor-based interaction, and the two have different capabilities as well. Fortunately, making a design work for both doesn’t take a lot of effort. Touchscreens have no capability to display CSS hovers because there is no cursor; once the user touches the screen, they click. So, don’t rely on CSS hovers for link definition; they should be considered an additional feature only for cursor-based devices.

Look at the article “Designing for Touchscreen” for more ideas. Many of the design suggestions in it are best for touchscreens, but they would not necessarily impair cursor-based usability either. For example, sub-navigation on the right side of the page would be more user-friendly for touchscreen users, because most people are right-handed; they would therefore not bump or brush the navigation accidentally when holding the device in their left hand. This would make no difference to cursor users, so we might as well follow the touchscreen design guideline in this instance. Many more guidelines of this kind can be drawn from touchscreen-based usability.

A Showcase Of Responsive Web Design

Below we have a few examples of responsive Web design in practice today. For many of these websites, there is more variation in structure and style than is shown in the pairs of screenshots provided. Many have several solutions for a variety of browsers, and some even adjust elements dynamically in size without the need for specific browser dimensions. Visit each of these, and adjust your browser size or change devices to see them in action.

Art Equals Work
Art Equals Work is a simple yet great example of responsive Web design. The first screenshot below is the view from a standard computer screen dimension. The website is flexible with browser widths by traditional standars, but once the browser gets too narrow or is otherwise switched to a device with a smaller screen, then the layout switches to a more readable and user-friendly format. The sidebar disappears, navigation goes to the top, and text is enlarged for easy and simple vertical reading.

Artequalswork1 in Responsive Web Design: What It Is and How To Use It

Artequalswork2 in Responsive Web Design: What It Is and How To Use It

Think Vitamin
With Think Vitamin, we see a similar approach. When on a smaller screen or browser, the sidebar and top bar are removed, the navigation simplifies and moves directly above the content, as does the logo. The logo keeps its general look yet is modified for a more vertical orientation, with the tagline below the main icon. The white space around the content on larger screens is also more spacious and interesting, whereas it is simplified for practical purposes on smaller screens.

Thinkvitamin1 in Responsive Web Design: What It Is and How To Use It

Thinkvitamin2 in Responsive Web Design: What It Is and How To Use It

8 Faces
8 Faces’ website design is flexible, right down to a standard netbook or tablet device, and expands in content quantity and layout width when viewed on wider screens or expanded browsers. When viewed on narrower screens, the featured issue on the right is cut out, and the content below is shortened and rearranged in layout, leaving only the essential information.

8faces1 in Responsive Web Design: What It Is and How To Use It

8faces2 in Responsive Web Design: What It Is and How To Use It

Hicksdesign
The Hicksdesign website has three columns when viewed on a conventional computer screen with a maximized browser. When minimized in width, the design takes on a new layout: the third column to the right is rearranged above the second, and the logo moves next to the introductory text. Thus, no content needs to be removed for the smaller size. For even narrower screens and browser widths, the side content is removed completely and a simplified version is moved up top. Finally, the font size changes with the screen and browser width; as the browser gets narrower, the font size throughout gets smaller and remains proportional.

Hicksdesign1 in Responsive Web Design: What It Is and How To Use It

Hicksdesign2 in Responsive Web Design: What It Is and How To Use It

Information Architects
Here is a great example of a flexible image. The image in this design automatically resizes after certain “break” points, but in between those width changes, only the side margins and excess white space are altered. On smaller screens and minimized browsers, the navigation simplifies and the columns of navigation at the top fall off. At the design’s smallest version, the navigation simplifies to just a drop-down menu, perfect for saving space without sacrificing critical navigation links.

Informationarchitects1 in Responsive Web Design: What It Is and How To Use It

Informationarchitects2 in Responsive Web Design: What It Is and How To Use It

Garret Keizer
The website for Garret Keizer is fully flexible in wider browsers and on larger screens: the photo, logo and other images resize proportionally, as do the headings and block areas for text. At a few points, some pieces of text change in font size and get smaller as the screen or browser gets narrower. After a certain break point, the layout transforms into what we see in the second screenshot below, with a simple logo, introductory text and a simple vertical structure for the remaining content.

Garretkeizer1 in Responsive Web Design: What It Is and How To Use It

Garretkeizer2 in Responsive Web Design: What It Is and How To Use It

Simon Collison
With four relatively content-heavy columns, it’s easy to see how the content here could easily be squished when viewed on smaller devices. Because of the easy organized columns, though, we can also collapse them quite simply when needed, and we can stack them vertically when the space doesn’t allow for a reasonable horizontal span. When the browser is minimized or the user is on a smaller device, the columns first collapse into two and then into one. Likewise, the horizontal lines for break points also change in width, without changing the size or style of each line’s title text.

Colly1 in Responsive Web Design: What It Is and How To Use It

Colly2 in Responsive Web Design: What It Is and How To Use It

CSS Tricks
On the CSS Tricks website, like many other collapsible Web designs, the sidebars with excess content are the first to fall off when the screen or browser gets too narrow. On this particular website, the middle column or first sidebar to the left was the first to disappear; and the sidebar with the ads and website extras did the same when the browser got even narrower. Eventually, the design leaves the posts, uses less white space around the navigation and logo and moves the search bar to below the navigation. The remaining layout and design is as flexible as can be because of its simplicity.

Csstricks1 in Responsive Web Design: What It Is and How To Use It

Csstricks2 in Responsive Web Design: What It Is and How To Use It

Tee Gallery
As one can see, the main navigation here is the simple layout of t-shirt designs, spanning both vertically and horizontally across the screen. As the browser or screen gets smaller, the columns collapse and move below. This happens at each break point when the layout is stressed, but in between the break points, the images just change proportionally in size. This maintains balance in the design, while ensuring that any images (which are essential to the website) don’t get so small that they become unusable.

Teegallery1 in Responsive Web Design: What It Is and How To Use It

Teegallery2 in Responsive Web Design: What It Is and How To Use It

City Crawlers: Berlin
When varied between larger screen sizes and browser widths, this design remains flexible. It also remains flexible after a few layout pieces collapse into a more vertical orientation for small screens and narrow browsers. At first, the introductory image, logo and navigation image links resize proportionally to accommodate variations in screen and browser widths, as do the blocks of content below. The bottom columns of content eventually collapse and rearrange above or below other pieces, until (at the narrowest point) they are all stacked vertically. In the layout for the smallest screen and narrowest browser, the slideshow is left out altogether, the navigation is moved below the logo and other images are also removed.

Berlin1 in Responsive Web Design: What It Is and How To Use It

Berlin2 in Responsive Web Design: What It Is and How To Use It

Ten by Twenty
Ten by Twenty is another design that does not resort to changing layout structure at all after certain break points, but rather simplifies responsive Web design by making everything fully flexible and automatically resizing, no matter what the screen or browser width. After a while, the design does stress a bit and could benefit from some rearrangement of content. But overall, the image resizing and flexible content spaces allow for a fairly simple solution that accommodates a wide range of screen sizes.

Tenbytwenty1 in Responsive Web Design: What It Is and How To Use It

Tenbytwenty2 in Responsive Web Design: What It Is and How To Use It

Hardboiled Web Design
On wide screens and browsers, all of the content on this simply designed website is well organized into columns, sidebar and simple navigation up top. It’s a fairly standard and efficient layout. On smaller screens, the sidebar is the first to drop off, and its content is moved below the book previews and essential information. Being limited in space, this design preserves its important hierarchy. Whereas on a wider screen we’d look left to right, on a narrower screen we’d tend to look from top to bottom. Content on the right is moved below content that would appear on the left on a wider screen. Eventually, when the horizontal space is fully limited, the navigation is simplified and stacked vertically, and some repeated or inessential elements are removed.

Hardboiled1 in Responsive Web Design: What It Is and How To Use It

Hardboiled2 in Responsive Web Design: What It Is and How To Use It

Teixido
This design features a complex layout that looks inspired by a print style. When viewed on a standard wide computer screen, more portfolio pieces are featured and spanned horizontally across the page. As one moves down the page, more graphics and imagery span the space. On a smaller screen, the portfolio piece is cut down to one, and then eventually left out altogether for very small screens and narrow browsers. The visualizations below collapse into fewer columns and more rows, and again, some drop off entirely for very small screens. This design shows a creative and intelligent way to make a not-so-common layout work responsively.

Teixido1 in Responsive Web Design: What It Is and How To Use It

Teixido2 in Responsive Web Design: What It Is and How To Use It

Stephen Caver
This design has three main stages at which the design and layout collapse into a more user-friendly form, depending on how wide the screen or browser is. The main image (featuring type) is scaled proportionally via a flexible image method. Each “layout structure” is fully flexible until it reaches a breaking point, at which point the layout switches to something more usable with less horizontal space. The bottom four columns eventually collapse into two, the logo moves above the navigation, and the columns of navigation below are moved on top or below each other. At the design’s narrowest stage, the navigation is super-simplified, and some inessential content is cut out altogether.

Stephancaver1 in Responsive Web Design: What It Is and How To Use It

Stephancaver2 in Responsive Web Design: What It Is and How To Use It

Unstoppable Robot Ninja
This layout does not change at all; no content is dropped or rearranged; and the text size does not change either. Instead, this design keeps its original form, no matter what the change in horizontal and vertical space. Instead, it automatically resizes the header image and the images for the navigation. The white space, margins and padding are also flexible, giving more room as the design expands and shrinks.

Unstoppablerobotninja1 in Responsive Web Design: What It Is and How To Use It

Unstoppablerobotninja2 in Responsive Web Design: What It Is and How To Use It

Bureau
This is perhaps the simplest example of a responsive Web design in this showcase, but also one of the most versatile. The only piece in the layout that changes with the browser width is the blog post’s date, which moves above the post’s title or to the side, depending on how much horizontal space is available. Beyond this, the only thing that changes is the width of the content area and the margin space on the left and right. Everything is centered, so a sense of balance is maintained whatever the screen or browser width. Because of this design’s simplicity, switching between browser and screen widths is quick and easy.

Bureu1 in Responsive Web Design: What It Is and How To Use It

Bureu2 in Responsive Web Design: What It Is and How To Use It

CSS Wizardry
Harry Roberts shows that responsive design can also have quite humble uses. If the user has a large viewport, the website displays three columns with a navigation menu floating on the left. For users with a viewport between 481px and 800px, a narrow version is displayed: the navigation jumps to the top of the site leaving the area for the content column and the sidebar. Finally, the iPhone view displays the sidebar under the content area. Harry also wrote a detailed article about the CSS styles he added to the stylesheet in his article “Media queries, handier than you think“. A nice example of how a couple of simple CSS adjustments can improve the website’s appearance across various devices.

Css-wizardry in Responsive Web Design: What It Is and How To Use It

Css-wizardry2 in Responsive Web Design: What It Is and How To Use It

Bryan James
This last design by Bryan James shows that responsive Web design need not apply only to static HTML and CSS websites. Done in Flash, this one features a full-sized background image and is flexible up to a certain width and height. As a result of the design style, on screens that are too small, the background image gets mostly hidden and the content can become illegible and squished. Instead of just letting it be, though, a message pops up informing the user that the screen is too small to adequately view the website. It then prompts the user to switch to a bigger screen. One can discuss if the design solution is good or bad in terms of usability, but the example shows that Flash websites can respond to user’s viewport, too.

Bryanjames1 in Responsive Web Design: What It Is and How To Use It

Bryanjames2 in Responsive Web Design: What It Is and How To Use It

Conclusion

We are indeed entering a new age of Web design and development. Far too many options are available now, and there will be far too many in the future to continue adjusting and creating custom solutions for each screen size, device and advancement in technology. We should rather start a new era today: creating websites that are future-ready right now. Understanding how to make a design responsive to the user doesn’t require too much learning, and it can definitely be a lot less stressful and more productive than learning how to design and code properly for every single device available.

Responsive Web design and the techniques discussed above are not the final answer to the ever-changing mobile world. Responsive Web design is a mere concept that when implemented correctly can improve the user experience, but not completely solve it for every user, device and platform. We will need to constantly work with new devices, resolutions and technologies to continually improve the user experience as technology evolves in the coming years.

Besides saving us from frustration, responsive Web design is also best for the user. Every custom solution makes for a better user experience. With responsive Web design, we can create custom solutions for a wider range of users, on a wider range of devices. A website can be tailored as well for someone on an old laptop or device as it can for the vast majority of people on the trendiest gadgets around, and likewise as much for the few users who own the most advanced gadgets now and in the years to come. Responsive Web design creates a great custom experience for everyone. As Web designers, we all strive for that every day on every project anyway, right?

Further Resources

(al) (vf)


© Kayla Knight for Smashing Magazine, 2011. | Permalink | Post a comment | Add to del.icio.us | Digg this | Stumble on StumbleUpon! | Tweet it! | Submit to Reddit | Forum Smashing Magazine
Post tags: CSS, elastic layout, flexible layout, fluid layout, mobile design, responsive web design

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
(PRO)
No Soup for you

Don't be the product, buy the product!

close
YES, I want to SOUP ●UP for ...