My Thoughts...
My thoughts from reading the book - designing for mobile and responsiveness is more like the day of old.
We are forced back into the box. Old timers have an advantage.
Excellent text to use with Lori:
"Which brings us to our “small” idea. Websites and applications should be designed and built for mobile first. Going mobile first:
-
Prepares you for the explosive growth and new opportunities emerging on mobile today,
-
Forces you to focus and prioritize your products by embracing the constraints inherent in mobile design, and
-
Allows you to deliver innovative experiences by building on new capabilities native to mobile devices and modes of use.
In fact, there’s enough benefit to a mobile first design approach that it’s worth thinking about even if you don’t have immediate plans to ship a mobile experience. Just a half-day of brainstorming about your mobile experience can open up new ways of thinking about your product."
--
While it’s true the incredible growth of the mobile internet has been fueled by better and better devices, mobile still remains a very constrained environment. Screens are small, networks are unreliable, and people can find themselves in all kinds of situations when they pull out their mobile devices. But these constraints are not only good for business, they’re good for design as well.
This is especially true if you subscribe to the adage that design is the process of gradually applying constraints until an elegant solution remains. In other words, embracing constraints (rather than fighting them) will ultimately get you to better designs.
--
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?
There are, of course, differences based on mobile and desktop usage patterns; but the core value of a web service remains the same across both formats and beyond. In fact, you’ll quickly find your customers will expect to do just about everything (within reason) on mobile. Especially those who primarily (or only) use their mobiles to get online. So don’t dumb things down on mobile—focus on what really matters most anywhere people can access your website.
With mobile first, the end result is an experience focused on the key tasks users want to accomplish without the extraneous detours and general interface debris that litter many of today’s websites. There simply isn’t room in a 320×480 pixel screen for elements of questionable value.
--
You can require mobile users to download less by managing both the size and number of files (and thereby HTTP requests) you are sending to a device. On mobile devices, each HTTP request can be more costly because of mobile network latency. So make sure you:
-
Use image sprites to group multiple images into a single encoded file. (Just make sure it’s not too big when decoded!)
-
Bundle together and minify CSS and JavaScript files.
-
Limit or remove dependencies on heavy JavaScript libraries—especially if they are just being used for one or two functions.
-
Likewise, limit the use of CSS grid systems.
-
Use proper HTTP headers to ensure files are appropriately cached in the browser’s memory.
-
Where appropriate, take advantage of modern browser capabilities like Canvas (http://bkaprt.com/mf/29) and Appcache (http://bkaprt.com/mf/30) in HTML5.
-
And my favorite: use CSS3 properties for rounded corners, gradients, text shadows, and box shadows. This reduces the need for images across your entire site, keeps things looking great in modern mobile browsers, and provides a decent fallback for browsers that don’t support CSS3 well. Just don’t go overboard with heavy CSS3 effects, as too many items for the browser to render could actually hurt performance.
--
When many people first imagine designing for mobile, they picture a hurried businessman on the street. While that can be a real use case to consider, the places where mobile devices are frequently used are much more diverse. A recent survey (http://bkaprt.com/mf/32) looked at where people used their smartphones and found:
-
84% use them at home,
-
80% use them during miscellaneous downtime throughout the day,
-
74% use them while waiting in lines or waiting for appointments,
-
69% use them while shopping,
-
64% use them at work,
-
62% use them while watching TV (a different study claims 84%), and
-
47% use them during their commute.
---
When it comes to organizing the content and actions on mobile, solid information architecture principles like clear labeling, balanced breadth and depth, and appropriate mental models remain important. But the organization of mobile web experiences also needs to:
-
Align with how people use their mobile devices and why.
-
Emphasize content over navigation.
-
Provide relevant options for exploration and pivoting.
-
Maintain clarity and focus.
--
In their iOS Human Interface Guidelines (http://bkaprt.com/mf/42), Apple recommends making touch targets 44×44 points. They use points instead of pixels to deal with differences in screen density, which we’ll discuss in more depth later on. To account for screen density (or ppi) variations, it’s better to measure touch targets in physical dimensions.
Microsoft takes this approach in their Windows Phone 7 Guidelines by recommending 9mm touch targets, a minimum size of 7mm, and a minimum spacing between actions of 2mm. Other touch-UI guidelines from Nokia (and even Ubuntu) fall in the same range because they all take the average size of people’s fingers into account. MIT’s Touch Lab determined that average to be 10–14mm for finger pads and 8–10mm for fingertips (http://bkaprt.com/mf/43).
Taking these touch-target sizing recommendations into account doesn’t necessarily mean every icon and button on your mobile page needs to be exactly 9mm wide and 9mm tall. The touch target itself should fall in this range, but the visual representation of the action can be 50–100% of the actual touch target size. The image from Microsoft (fig 5.3) illustrates the use of padding or margins to ensure targets are the right size without having every visible user interface element appear the same.
Where do we touch?
When talking about the placement of navigation controls earlier, I mentioned that actions toward the bottom of the device naturally align with how people hold and use their mobiles. Well, there’s a bit more to it than that. Where you expect to find primary actions on a touch-screen mobile often depends on which fingers (thumb or index) you are using for tapping and if you are right or left-handed.
Since the majority of people are right-handed (about 70-90%) and use their thumbs while operating a mobile with one hand, optimizing for right-thumb actions is most common. This means primary actions can be placed in the middle or bottom of the screen and arranged from left to right (fig 5.6).
Cover the hover
Since we’re on the topic of tips, it’s worth noting that any tips or actions that happen “on hover” (when a mouse pointer is positioned over a trigger) won’t work the same way on touch-only devices. Quite simply, there is no pointer to position over an interface element. There’s just our fingers, and though they cast a shadow, no mobile device I know of considers that a hover yet.
Therefore, any actions that rely on mouse hovers in our desktop web experiences need to be rethought—and that’s a good thing. Many uses of hover actions on the web assume too much. Just because someone places their mouse cursor over something doesn’t mean they are asking for a pop-up menu of actions and options (fig 5.12). Unlike clicks, hovers are usually not explicit actions.
--
The power of the web has always come from people’s ability to not only view and consume content, but to contribute and create content as well. Input on mobile is just as important as output, but like all things mobile it typically requires its own bit of secret sauce:
-
Embrace mobile as an opportunity for people to contribute and create whenever and wherever inspiration strikes.
-
Use mobile-optimized labels to clearly ask questions.
-
Take advantage of input types, attributes, and masks to make mobile input easier.
-
Choose the right layouts for sequential, non-linear, and in-context forms.
-
Look for opportunities to go beyond the input field using mobile device capabilities.
--
The mobile sign-in screen for email-marketing site MailChimp highlights two of these points (fig 6.2). When entering a username into the first input field, the label inside disappears. (Note: this is default behavior for the HTML5 input attribute placeholder which, according to the spec, is intended for tips, not labels.) After an answer has been provided, the difference in color between the answer (“lukew”) and the next label (“password”) is just a subtle shade of gray. Neither of these two issues are likely to be a very big problem in such a simple form. But as forms get longer, problems stemming from these issues can get a lot worse.
Input a go-go
Though people have clung to their mobile devices for years, opportunities for input on these devices have largely been ignored. But today’s combination of more capable devices, better networks, and people’s increasing desire to share make mobile input an opportunity you can’t ignore.
-
Actively encourage input and allow people to contribute and create using their mobile devices.
-
Make sure your questions are clearly presented with mobile-optimized labels.
-
Get rid of the pain associated with accurate mobile inputs by using input types, attributes, and masks in your designs where possible.
-
Consider using custom input controls if they really help people provide accurate answers without a lot of work.
-
Lay input possibilities out appropriately for sequential, non-linear, and in-context contributions.
-
Take advantage of mobile device capabilities to capture input in new ways.
---
Appropriate adaptations of how we think about organization, actions, and input on the desktop take what we know about web design and make it usable on mobile. But how do we ensure it’s also usable across the wide range of mobile devices available now and in the coming months—not to mention years?
-
Come to terms with the fact that mobile is going to change at a breakneck pace for the foreseeable future.
-
Let mobile browsers know you are creating designs that fit them.
-
Be flexible, fluid, and responsive in your layouts.
-
Know where to sketch the lines between device experiences.
-
Reduce to the minimum amount necessary.
The only constant is change
Laying out the land
As the mobile landscape continues to change, we have to be ready with layouts that adapt to the task at hand—from big differences between device experiences to filling in the small gaps between device screen sizes and orientations.
-
Accept and embrace the rate of change in mobile isn’t going to change anytime soon.
-
Use the meta viewport tag to let mobile browsers know you’ve thought of them in your designs.
-
Account for differences in screen density by making higher resolution images available to the devices that support them.
-
Adapt to device variations with responsive and fluid layouts.
-
Account for the differences between device experiences in your responsive web design or server-side solutions.
-
Reduce complexity for yourself and your customers by cutting down to the minimum amount of functionality necessary for your website or application.
Resources
More data, please
Morgan Stanley’s Mobile Internet Report was a huge source of supporting facts and information for me. It’s filled with hundreds of slides with data about the biggest trends in mobile (http://bkaprt.com/mf/58).
Mary Meeker was the primary author of the Mobile Internet Report and has gone on to publish more of her findings in her new role at Kleiner Perkins (http://bkaprt.com/mf/59).
For ongoing mobile market information and data, keep up with Horace Dediu’s articles and pointers on Asymco (http://bkaprt.com/mf/60).
I also publish design-related data points about mobile computing and more every Monday on my blog (http://bkaprt.com/mf/61).
Mobile first development
While this book doesn’t dig into mobile first web development, others have.
Bryan and Stephanie Rieger’s write-up about the construction of their site, Yiibu, outlines how they approached mark-up, style sheets, and content development (http://bkaprt.com/mf/62).
Ethan Marcotte’s Responsive Web Design book outlines how flexible grids, flexible images, and media queries can be used to adapt web site layouts across many devices (http://bkaprt.com/rwd).
The Cloud Four blog is filled with many great articles about the intersection of mobile devices and the web (http://bkaprt.com/mf/63).
The great debates
Everything in technology and design gets debated and mobile is no different. Here are a few summaries of some of the thornier issues still being discussed.
Native mobile applications vs. mobile web solutions: when does each one make sense and why (http://bkaprt.com/mf/64, http://bkaprt.com/mf/65)?
Can we really understand and design for mobile context? Jason Grigsby sums up the issues and provides links to many pertinent articles (http://bkaprt.com/mf/66).
And last but not least: separate mobile web pages or responsive web design? It depends, says Josh Clark in his summary of the issue (http://bkaprt.com/mf/67).
Bibliographic Information
Mobile First
by Luke Wroblewski, ISBN 978-1-937-557-03-4
2011, A Book Apart, New York
These are notes I made after reading this book. See more book notes
Just to let you know, this page was last updated Saturday, Apr 27 24