Adaptive Mobile UX Design

Thanks to everyone at the Midwest UX conference who attended my talk on user experience design for the mobile web. It was a lot of fun, and I enjoyed talking with folks both in-person and on Twitter afterwards. It turns out that there are quite a lot of former developers or tech-leaning designers in the UX community!

Below is my presentation on SlideShare, as well as a text-only transcript. Please share and enjoy!

[Slide 1]
Hello, and welcome. Today I’m going to talk about designing for the mobile web. But first I want to relate a recent experience that encapsulates a lot of what we’re trying to do when we design for mobile: connect what’s onscreen to what we’re trying to do, in the moment, in real life.

[Slide 2]
A couple of months ago, I converted a spare bedroom in my house from what was essentially a storage space into a home office. Fortunately, my desk is right in front of a nice big window. UNfortunately, it’s a single pane, old wood window, in my 100-year old uninsulated house. The room stays cold, and I realized pretty quickly I needed a space heater.

[Slide 3]
Since I didn’t want to wait for one I’d order online, I decided to purchase one from a store near me. I did go online first to research features and prices, but then I headed over to my local Sears, since I figured they’d have a pretty extensive appliance selection.

[Slide 4]
I got to the store, head upstairs to where the space heaters are, and find the one I want. The price was a bit higher than at other stores online, but still okay. Even so, I’m a savvy shopper, and I wanted to see if Sears maybe had a price-matching policy.

[Slide 5]
So I took out my smartphone, and did the following Google search in my web browser:

“Sears price match policy”

Great, a web page with that exact phrase for the title, at the sears.com domain. So I tapped on the link to view it. But this is what I got:

[Slide 6]
“The server has not found anything matching the Request-URL. ERROR 404 Not found”

Not good. Where was the web page that Google had tantalizingly dangled in front of me?

But looking at the error page URL, I see:

“m.sears.com”

Ah, sounds like a mobile URL. So the Sears web site KNOWS that I am on a mobile phone, but it can’t use that information to provide me with the appropriate experience based on the content I’m looking for and the context of me, standing in their store.

Then I went directly to “m.sears.com”, got their mobile site.

[Slide 7]
I repeated my search phrase there. But I didn’t really get anywhere there, either, just over 64 thousand results for things like jewelry. This was obviously searching their product catalog, not the site.

I even tried to go to www.sears.com, but I kept getting redirected to the mobile site. There was no way I could get to that page with the price match policy info from my phone.

Overall, not a good experience. And I’m not just talking about the mobile web site. While I did buy the space heater anyway, the entire process left me pretty grumpy.

[Slide 8]
What we have here is a failure to adapt. The Sears.com site couldn’t adapt to the combination of an incoming search query from a mobile device to a page on their main web site. They actually blocked me from getting to information they did have on their main site. I certainly hope web experiences like this do become extinct.

[Slide 9]
So, what is Adaptive Mobile Design? It’s an approach to creating web sites and applications that try to give each user the best possible content and experience, tailored to their device and browsing context. And the “try to give” part in there is pretty important, since we can never anticipate all of the factors involved.

As it turns out, this approach is nothing new. Another industry has been doing this for hundreds of years.

[Slide 10]
The ad industry is the perfect example. Display advertising, in particular, is a specific medium where within the relatively two-dimensional constraint of showing an advertising message, it adapts to the user context.

[Slide 11]
Here’s one from a classic roadside ad campaign.

[Slide 12]
Or this print ad, taking advantage of the then-novel full color printed magazine page.

[Slide 13]
Or Boston’s famous Citgo sign, where, in its pre-digital incarnation, shown here, the canvas was thousands of illuminated tubes of neon, lit up and set to animate.

[Slide 14]
The message adapts to, and sometimes even acknowledges the medium, as well as the setting. This tour bus ad, for example, is clearly meant for locals, as the tourists unwittingly become part of the ad. And the same campaign, adapted for taxicab and subway placements.

[Slide 15]
Here we’ve seen three major design considerations: canvas, capabilities and context. As applied to mobile design, Canvas is the varying display sizes and resolutions of phones, tablets and other devices. The capabilities of the device, from the processor speed to the data connection speed, also play a role. Finally, context: where the user is, what they’re doing, and their attention level.

[Slide 16]
Knowing these things, how do we apply them to the design of mobile web sites?

[Slide 17]
There are many different approaches you can take, everything from creating a separate mobile site to creating a single site to serve all devices and contexts.

Crafting a bespoke site or app is great, if you can manage it. But the fact is, it’s time- and resource-intensive. And it can be tricky figuring out how to gracefully integrate and manage a number of elements — work streams, strategy, content — across multiple sites.

It’s also a big challenge to redesign an existing site to be truly responsive. The tools and technologies are there, but to successfully implement such a site, it takes both developers and designers with intimate familiarity with all of their capabilities, limitations and differences cross-platform, -browser & -device. That’s a pretty tall order, for even the most skilled teams.

An approach that’s likely to work for a larger number of companies, especially those looking to make incremental improvements today, is to be pragmatic. Apply new technologies to your main site, where it makes sense, in order to improve the mobile experience for your users.

[Slide 18]
And these new technologies? HTML5 and CSS3. These two are just the latest versions of both HTML and CSS, used to structure and present web page content. But they are chock full of new features — too many to cover here, in fact. The following are just those most relevant to the mobile browsing experience.

[Slide 19]
First, HTML5. There are five features — four big ones, and one little one — that we’ll be looking at:

– Smart web forms, with form input UI changing based on the form field type.
– Geolocation, where the site can know your location and use that info.
– Dynamic device orientation, where the site gets motion tracking info from your phone.
– Web-native video playback, such as what Apple uses to display videos without the use of Flash on its iOS platform.
– And, semantic web markup, which is less a feature than an architectural change

[Slide 20]
Here we’ll look at smart web forms as implemented on sites viewed with the iPhone’s Safari browser. Shown is the default soft keyboard, a Qwerty one with all letters. Since space is limited, numbers and symbols requires toggling to different keyboards.

[Slide 21]
But if we go to eBay’s mobile web site, we can see one of the new input types in action.
On this page, in order to bid on this Go-Betweens record, I would tap in the field for “USD” (dollars), where I want to enter an amount.

Since the field value must be a number, eBay has specified an input type attribute value of “number” for that field. So when the soft keyboard appears, the version shown is numeric, not the default Qwerty one.

And here is what the HTML code for that would look like. Since it’s a new attribute type, it’s simply ignored in older browsers without any ill effect.

[Slide 22]
Here’s another input type, on MailChimp’s web site. When you go to sign up for an account, there’s the familiar field for inputting an email address. Tap on the email field…

…and you get the Qwerty keyboard, but slightly modified, with the “@” symbol and a period sharing space with the space bar. This way, the user can enter an email address without having to toggle back and forth between the different default keyboard states.

And here is the code for that feature.

[Slide 23]
Next geolocation. This is something that is incredibly common in mobile apps, such as Google Maps, where it detects your current location to plot a course. But this is something that web sites can do, as well. On some platforms, such as the iPhone, you’ll need to explicitly turn on the ability for the web browser to use geolocation, as it’s turned off by default.

Assuming you’ve turned this feature on, Old Navy’s mobile web site has a store locator that uses geolocation. If you tap on the Find Store button…

…you’ll first get an alert asking you if you want to let this web site know your location. If you tap on “OK”…

You’ll automatically get a list of locations nearest you, without having to enter or tap on anything additional.

[Slide 24]
The next feature is dynamic device orientation. Like geolocation, this is something that’s being used in mobile apps now, primarily for games. Web applications of this feature are still pretty few and far between, but there are some demos online showing exactly how the movement of a device in-hand can effect objects onscreen.

Here is a brief video showing me using one of these web demos on my phone.

[Slide 25]
Another, more common feature, is web-native video playback. The de facto standard for video playback on the has been Flash, which isn’t a true standard at all, but a proprietary technology owned by Adobe.

Apple’s decision not to support video playback using Flash has given HTML5 video a real boost, and largely because of that, sites like YouTube and Vimeo have been adding HTML5 video support.

Here are a couple of examples showing how iPhone and Android each handle things. On the iPhone, tapping on the “Play” icon for this particular video…

…Triggers playback using the native iPhone video player. Safari hands off the request to that app.

[Slide 26]
On Android, things work a little differently. Again, seeing the same video play icon, tapping on it…

…brings up a couple of programs from which the user can choose to play the video.

Handling video natively, each mobile platform gets to provide an experience that best meets the expectation of its users, instead of applying a one-size-fits-all approach.

[Slide 27]
Finally, semantic the new semantic tagging structure that HTML5 uses, something that should warm the hearts of information architects everywhere. Instead of faceless divs and spans that need classes and IDs to give them any meaning, the new content containers *themselves* have meaning. When we specify “nav,” “header” and “footer” in a wireframe, those elements can now be coded with “nav,” “header” and “footer” tags.

This also happens to be important for findability, as search engines are increasingly looking for structure to help apply meaning when parsing web page content. Properly structured and tagged content, especially when semantically tagged, will be more likely to be indexed properly and given greater prominence in results.

Those are the HTML5 highlights. Next…

[Slide 28]
CSS3. The story here for mobile is pretty much CSS Media Queries, whereby custom stylesheets, which determine web page layout, styling, and even content, can be served up for different screen size, page orientation and resolution.

[Slide 29]
A good example of a design that adapts to different screen sizes is the web site for northwest music festival Sasquatch. Here we see the full page layout, viewed in a web browser, close to fullscreen, on my laptop. But when viewed on my iPad…

[Slide 30]
…The images and other content scale accordingly, filling the entire screen in way that perfectly suits this browsing context. This, instead of presenting a zoomed-out view of the “full-size” web page. Or even worse, a page with the right side cut off and a dreaded horizontal scrollbar.

[Slide 31]
And on the iPhone, the smallest screen size, you can see how the design once again undergoes a transformation. The heading design is completely different, in order to fit into that small space, and no attempt is made to show the full navigation bar, which likewise wouldn’t fit.

And next to the screen is the bit of code that shows how a phone-specific stylesheet is served up via a media query that says: “use this design when this content is viewed on a screen, with a maximum device width of 480 pixels.”

[Slide 32]
Orientation is another media queries feature. Here we have two screenshots from my iPad of a web site that changes the design based on the dimensions of the browser window: blue if the window is between 400 and 1000 pixels wide, red if it’s wider than 1000 pixels. Above is the code that specifies which stylesheet to use for which orientation: landscape or portrait.

[Slide 33]
And the third feature is screen resolution. Here are three different phones, each with a different screen pixel density. The oldest phone here, the iPhone 3GS, can show 163 dots per inch. The Samsung Galaxy S has a 233 DPI display. The best picture is on the iPhone 4 — with it’s “Retina Display” it can show twice the number of pixels as the previous generation iPhone, at 326 DPI.

Why do these things matter? By targeting screen resolution, you could serve up an entirely separate set of high-quality images to users with displays capable of viewing them in all their fine-detailed glory. Otherwise images designed for a lower resolution display may not scale properly.

And the code for that media query.

[Slide 34]
Of the features mentioned today, it’s important to note that while not all are currently supported on even the most popular smartphone platforms, the majority are. You can see that iOS and Android are the two leaders in support, as they are in U.S. smartphone OS market share.

[Slide 35]
So, I know that’s a lot of information to absorb, especially in 20 minutes. But, to wrap up:

You’ll already be doing something right by considering any device, any context, any screen as part of your design process.

As you can tell, you’ll need to be working closely with developers to fully realize great mobile experiences, as there are many moving parts.

Modern smartphone browsers already have good HTML5 and CSS3 support, so you should start using these techniques now. And of course ensure your sites are build in a way that browsers without those capabilities are still able to get essential content and functionality.

Finally, while this talk has centered around mobile, adaptive design is not limited to mobile, and these ways of thinking about the fluidity of content and experience can and should be applied to web design overall.

[Slide 36]
Here are a few great resources if you want to learn more about HTML5 and CSS3. All of these sites have tons of examples, many of them interactive, so you can see these and other techniques in action. I hope you find them as inspiring as I have. Thank you.