An Event Apart Minneapolis: Luke Wroblewski, "Mobile first!"

On Monday afternoon of An Event Apart Minneapolis, the first presentation was given by Luke Wroblewski, with a simple but revolutionary message for us: Web products should be designed for mobile first. Below is a summary of my notes: unless I specify otherwise, these brilliant thoughts are his.

In short, even if you’re not planning on releasing a mobile version, design web products for mobile first.

Luke pointed out that Eric Schmidt had said that Google programmers are doing work on mobile applications first, because they’re betters apps, and top programmers want to develop them.

Why mobile first? Luke’s three main reasons he returned to throughout the presentation:

  1. Growth = Opportunity
  2. Constraints = Focus
  3. Capabilities = Innovation

He also covered a host of considerations crucial for mobile design:

  • Multiple screen sizes and densities
  • Performance optimization
  • Touch targets, gestures and actions
  • Location systems
  • Device capabilities

Growth

Luke shared a graph that demonstrated that in the 90s, there were about 100 million PCs or more. By the 2000s, the desktop internet had over 1 billion users. Mobile consumers? In the not too far future, over 10 billion. That’s enormous growth.

He pointed out that due to the iPhone, AT & T mobile data traffic has increased fifty times in three years.

While the current numbers for mobile phones include more limited “feature” phones that lack full access to the web, smartphone growth is still huge.

Constraints

Another quote shared, from Brian Fling: “Great mobile apps are created for mobile, not ported there.”

Due to screen size limitations, for example, you must focus on core actions, know your users and use scalable design. However, these principles are not restricted to mobile: This is design 101.

The iPhone interface guidelines point out that in apps, the main function should be immediately apparent. Minimize the number of controls from which users choose.

As an example of this, Luke compared Southwest Airlines’ website with its mobile app. The mobile app focused on core actions, while the website filled up extraneous space with extraneous things.

He stressed that even though a mobile app may appear simpler, don’t cut off features. People should be able to do the same things in a mobile app that they can do on a website.

Another good nugget: By knowing your audience, you can build something that matters to them. Mobile constraints force focus on the most important things.

Again he shared a comparison, this time of and itinerary information page from the Expedia website to the same information in its mobile app, where it was so much easier to see what was critical.

One key challenge for mobile: How do you deal with different sizes and resolutions for different mobile devices? He laid out the following steps:

  1. Define device groups
  2. Create a default reference design
  3. Define rules for content and design adaptation for each group
  4. Opt for standards and flexible layouts

Another interesting aspect of mobile is that its constraints force you to figure out how make the content the action rather than cluttering the screen with buttons. For example, with an iPad, when you are looking at photos, the photos are the UI, rather than all kinds of icons and buttons and such.

An important sidenote: Design matters on the iPhone. If you put something on the iPhone, the design really matters. If you create something for the iPhone with a bad design, you will receive feedback by the truckload.

Another critical constraint for mobile? Speed. Keeping performance at the top of your mind include Ways to address performance roadblocks include:

  • Reduce requests to the server:
    • Eliminate redirects
    • Use CSS sprites
    • Consolidate CSS/JS in one file for each
    • Minify code
  • Take advantage of HTML5:
    • Load content lazily: load some data only when necessary, at the user request
    • Use the application cache for local content storage
    • Use CSS3 and canvas instead of images.

Capabilities

Luke then reminded us to keep in mind that people use mobile devices all the time: at home, in lines at grocery stores, at work, and throughout the day. Designing for mobile means designing for something that can be used all the time.

People don’t stay long with any one item in mobile. 25% access documents for less than four seconds. 50%: less than 10 seconds. The peak is between 2–3 secs. Design for short bursts.

Also, people use mobile with one-handed touch, so you can’t have things too cluttered: they must be simple.

A series of pie charts he shared showed a big shift from Keypad interaction to Qwerty and now to primarily a combo of Qwerty and touch.

Luke asked us if our designs are ready for touch. As an example, Apple recommends a minimum target size for something that should touched as 29 pixels wide and 44 pixels tall (hopefully I wrote those numbers down correctly). This is a big target area, because we have fat fingers. Of course the area varies by resolution. Also, the target area is not the same as the visual size of the item we want to touch. That should be 60–100% of the actual active target area.

Touch gestures include:

  • Tap
  • Double tap
  • Drag
  • Flick
  • Pinch
  • Spread
  • Press
  • Press and tap
  • Press and drag
  • Rotate.

Certain actions typically have certain types of gestures, so make sure you use appropriate gestures. Luke has a created a guide for this which is available at http://lukew.com/touch.

Another important consideration: Beware of hover overload, particularly because hover is an unintended action. You don’t know somebody is intending to hover. With mobile, hover is even more problematic.

Luke reviewed a variety of new capabilities for mobile devices, including:

  • Multiple orientations
  • Location and orientation serving as input
  • iPhones can be equipped with an RFID reader to interact with environment. Less awkward than relying upon compass and accelerometer.
  • Audio can be used for input, so can images
  • Video

How do all these new capabilities affect your application?

Personally, I was wondering if we design for mobile first, and a lot of these capabilities can only be used on native devices, what does that mean for websites? However, Luke must have been reading my mind, because just after I had that thought, he mentioned that traditional computers may catch up and have some of these capabilities in the future as well

My take

What I found most valuable is the insight that we should focus on critical actions and make things simple for users. This is a profound shift and a great perspective.

Also, while we think of the web as being something we primarily access through desktop and laptop computers, very soon that will not be the case. Mobile will be the primary device for accessing the web. If that is so, why would we not design for mobile first?

What I still struggle with is how intimately medium has always been to message. That is the promise of the web, however, casting off the tethers of content from their containers.

Archives