A Book Apart: Mobile First By Luke Wroblewski
As a web applications developer, I know that people use mobile devices to access my work; but, unfortunately, this fact is still a bit of an afterthought in my life. Typically, I create one version of software: desktop. And, since most smart phones can view this version with zooming and panning, I tend to concentrate on desktop iteration rather than mobile development. After reading Mobile First by Luke Wroblewski, however, my thoughts about the subject have begun to change. I was afraid that the book would take on a "desktop is dead" outlook; but, instead, Wroblewski presents some excellent ideas on how designing for mobile first can help you understand your users and your software more deeply.
| |
|
|
||
| |
 |
|
||
| |
|
|
When I saw the title of this book - Mobile First - I was hesitant to get it because it sounded like it was going to be talking about how the world is moving to mobile as a primary means of interaction and how we should stop concentrating on desktop and start putting all our effort into mobile development. While I agree that mobile usage is skyrocketing, I'm immediately skeptical of anyone who thinks that mobile will replace desktop. I use both computers and mobile phones - one is not a substitue for the other.
Luckily, that is not at all what "Mobile First" is about. In the book, Wroblewski talks about mobile development as a constraint that forces us to think deeply about our users, what kind of people they are, and what kind of tasks they most need to perform (in which modes of operation). I think this paragraph nicely sums up the focus of the book:
"If you design for mobile first, you can create agreement up front on what matters most. You can then apply the same rationale to the desktop (and any other) experience of your web product. If you can agree on the most important set of features and content for your customers and business, why should that prioritization change with more screen space?", (Page 32 of 216).
On the desktop version of our software, we tend to put a tremendous amount of information on screen. After all, we have all that white-space to fill. On a mobile device, we have 20% of that screen space to work with (if that). As such, we are forced to pair down our interfaces considerably. In doing so, we are forced to think about what content and actions are truly useful to the end user. Furthermore, since it is a mobile device, we have to think about our users different modes of operations: (Page 70 of 216):
- Lookup/Find (urgent info, local): I need an answer to something now - frequently related to my current location in the world.
- Explore/Play (bored, local): I have some time to kill and just want a few idle time distractions.
- Check In/Status (repeat/micro-tasking): Something important to me keeps changing or updating and I want to stay on top of it.
- Edit/Create (urgent change/micro-tasking): I need to get something done now that can't wait.
Because a mobile device lends itself more naturally to different interaction tempos, we have to think more holistically about our users. Not only do we need to think about which content is most important (due to screen size), we have to think about how to make a variety of content actionable and how to let our users easily pivot their online experience.
I really enjoyed this book. I think Luke Wroblewski does a great job of explaining how a mobile-first approach to development can yield better, more effective software in the long-run. And, since mobile development incurs other constraints in addition to screen size, Wroblewski also talks about topics like optimizing HTTP requests, responsive layout design, and pixel density. Definitely a recommended read!
Reader Comments
I guess the good middle road is to design for iPad first. That way you have 1024 x 768 screen, big enough and finger interface where absolute minimum interaction area is 34x34px, instead of 9x9px. Actually its surprising how usable and good interface you manage to make that way. You cannot cram small buttons on the screen and you innovate and create great things in the process. Just did that with my last project.
@Priit,
That sounds pretty cool. In the book, he talks about the minimum touch points and the minimum distance points, which sounds close to what you're talking about. I'm excited to try and think about this more deeply for an upcoming project. Or maybe I'll make a small personal project, just to think about (always got a few kicking around in the old brain).
@Ben,
This approach (most difficult situation first) reminds me of Designing with Progressive Enhancement by the Filament Group. (They're the accessibility specialists behind jQuery UI and jQuery Mobile.) That book talks about the "x-ray perspective", which means seeing through the clutter of traditional UI to what really's being presented, and why.
From your description, Mobile First seems to be doing the same thing for screen real estate. The inaccessible app is the one that forces you to pinch and unpinch, over and over again, instead of adapting to your "disability" (smaller screen) and presenting the data in a more comfortable way to the user.
I'd be interested to hear Mr. Wroblewski's take on tooltips on touch screens, where there's no such thing as hovering. Also, Apple doesn't provide visual feedback that a div or iframe is scrollable. (You have to already know that the out-of-view content is there, because the scroll bars don't appear until you start to scroll.) Does he give a workaround, so that we can provide our users with more feedback than Apple wants to give them?
P.S.: I have my own solution for tooltips:
http://www.webmanwalking.org/examples/accessibility/dsp_tooltips_on_ipad.cfm
My solution requires a special-purpose server page that generates dynamic content from the URL (CF, PERL, whatever). There may not be any workaround better than that, but I sure hope Mr. Wroblewski has found one.
Ben,
actually Apple recommends 44px, Microsoft 34px. I have come to conclusion that generally 44px is too much for a single, orphan, element. By building a toolbar or something 44px is better. But it is good starting point to target 34px for universal layouts.
@WebManWalking,
In the book, Luke has a section called "Cover the Hover" which talks about how to deal with hover-based items. Not to speak for him, but either 1) remove them altogether or 2) Put them on a different page (click through).
But, I think more to your point about the scroll-bars (which is really tricky on iOS devices), if something is not necessarily intuitive, it might be an indicator that it needs to be redesigned.
I happen to know that I can scroll a DIV with two-finger-swipe on iOS; but, I know people that do NOT know how to do that... and certain interfaces are completely unusable to them.
This is actually one of my biggest concerns with removing scrollbars from Mac OSX Lion. It seems like the same limitation would be there.
@Priit,
I don't have an iOS in front of me, but 35px stands out in my mind as something that has felt pretty comfortable for "touchability".
@Ben,
There seems to be some chatter on Twitter lately about roll-your-own scrollbars. I'll let you know if anything seems promising.
We have 15 years' worth of web pages with scrollable divs or iframes, too many to refactor anytime soon. So I'm thinking of adding a special warning about 2-finger scrolling to our login page if the browser is iOS. That plus roll-you-own scrollbars might keep our iOS users happy.
@WebManWalking,
Yeah, overflow:auto was such a mind-blowing feature for a long time! I have definitely made ample use of it.
@Ben,
Just found the simplest scrollbars solution (because we already have jQuery Mobile here):
http://jquerymobile.com/test/docs/pages/touchoverflow.html
For non-jQuery-Mobile pages, the underlying trick is -webkit-overflow-scrolling:touch.
Odd, however, that when I google "-webkit-overflow-scrolling" site:webkit.org I get nothing found, and Google switches to showing me the results without quotes (not showing exactly that phrase). Where's a dude to go for official documentation???
Oh well, all in good time, I suppose.
I heart this post. And it summarizes what we all already knew, but didn't completely know.