Mobile, Desktop, Neither, Both

If you design or develop web sites for a living (and if you’re reading this, you probably do), for the past couple of weeks your Twitter stream, RSS feed or [insert news firehose of choice] has likely been filled with everything from detailed rebuttals to complete bewilderment regarding Jakob Nielsen’s latest alertbox column, Mobile Site vs. Full Site.

Probably my favorite quote on the topic is this, from Josh Clark:

When you see a “full desktop site” link on your phone, you’re looking at an admission of failure.

As much as I agree with that sentiment, admitting failure is still preferable to ignoring the problem altogether. What if the site you’re browsing on a phone doesn’t even have that link, and you know that the content you need does in fact exist on that company’s “desktop” web site?

A Mobile Browser in Disguise

Well, if you use an Android phone running Ice Cream Sandwich (4.0), there is an easy option for circumventing the dumbed-down mobile experience on such sites: toggle on the option to view the “desktop” version of any given site in the latest version of Chrome browser for Android, released just this past week.

Chrome for Android browser settings, "Request desktop site" checked

Advanced users have long been able to tweak desktop browser settings or use plug-ins to change the browser version or type advertised to web sites. The mobile version of Chrome just puts this option within easier reach of its users, perhaps anticipating (correctly) that they are more likely to need it due many of the poor choices sites have made in how to serve up mobile content. And it works the same way, by changing the user agent string of the browser — in this case, to a desktop version of Chrome. Below are examples of the UA string, both before and after:

Default “mobile” user agent for Galaxy Nexus, running Chrome for Android:

Mozilla/5.0 (Linux; Android 4.0.2; Galaxy Nexus Build/ICL53F) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.133 Mobile Safari/535.19

Spoofed “desktop” user agent for Galaxy Nexus, running Chrome for Android:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.45 Safari/535.19

Switching up the user agent string foils most web sites’ attempts to redirect such requests to their “mobile site,” since all clues as to its mobile-ness — the device name, the true OS and true browser — are stripped away or obfuscated. Result? The mobile-dressed-as-desktop browser is served up the default (desktop) content.

A Carrier Collision

Unfortunately, there’s another player in the web browsing experience that can get in the way of a user, his browser, and a web site. And it’s someone with a pointed financial interest in your browsing habits: the mobile carrier.

Such was the rude realization had by by my boyfriend Josh when attempting to visit a web site a few nights ago on his Android phone, a Samsung Galaxy Nexus. Encountering a redirect to that company’s feeble mobile site, he turned on the “Request desktop site” option in Chrome and attempted to reload the page… only to receive content of a very different kind, and not from the requested site:

(“Mobile HotSpot” is just T-Mobile’s way of saying “tethering.”)

Why the upsell/road block?

Josh quickly deduced that not only was T-Mobile “listening in” on his web activity/requests, it had determined that he was using a desktop computer paired with T-Mobile phone (not broadband) data service. And that type of network activity is a definite no-no on T-Mobile unless you are paying an additional monthly charge for the ability to tether other devices, such as a laptop, to your mobile data connection.

The way T-Mobile likely decided that Josh was tethering? The same way his destination web site decided to serve him that lame mobile experience: via the browser’s user agent string. And perhaps they combined this with knowledge about the number of gigabytes of data he’d already consumed that month. (He habitually uses around 2-3 GB per month, preferring to use his phone as his primary device for accessing the Internet, even at home.) And given that the display resolution of the Galaxy Nexus is a whopping 1280 x 720 pixels, even that would not have helped determine mobile vs. desktop.

So a disguise engineered by Google to let him successfully pass as a desktop user was convincing enough to trip T-Mobile’s “unauthorized tethering” alarms and end up blocking him from the content he requested in the end.

Even worse, more tests the next day revealed that Josh was now getting blocked by the “tethering upsell” screen when using Chrome for Android regardless of whether the “Request desktop site” option was checked. Apparently, T-Mobile had decided that all of his web activity while using any variant of Chrome was suspect, even when it was accurately reporting itself as a mobile browser.

What This Means

This little episode was, of course, frustrating (and triggered a testy, 20-minute call to a front-line technical support rep including lots of explaining to said rep about how web browsers and servers work). And someone at T-Mobile has logged the issue in some database somewhere where it may or may not be addressed in some manner (someday).

But the real lesson, I think, is in how users’ mobile browsing behavior is increasingly failing to map to outdated assumptions from both web site owners and mobile carriers about how their content and networks are being used. While iPhone users are known for chugging down data at a rate that far exceeds that of their other-OS’ed brethren, more Android users are trading their straws for steins as powerful new devices like the Galaxy Nexus or Galaxy Note are introduced, with their huge screens and fast, 4G network connectivity.

And, Jakob’s recommendations aside, a growing cadre of in-the-trenches designers and developers of experiences tailored for mobile and beyond understand how mobile is a user state, not a device. That context is increasingly difficult to pinpoint as users try to do anything and everything on their mobile device they would on a desktop computer. And companies who fail to shift with their users will be far likelier to, as Josh told the T-Mobile rep, “be tempted to take my business elsewhere.”


Revisiting Adaptive Mobile UX Design


Last month I had the pleasure of returning to Columbus, OH to speak at the inaugural M3 Conference, devoted to all things mobile. I gave an extended version of my Adaptive Mobile UX Design talk from the Midwest UX conference earlier this year, adding more on core UX considerations for a mixed designer-developer audience, as well as updating much of the material to account for all of the changes in the mobile space in the past six months.

I’ve posted the slides from my talk on SlideShare, also embedded below with a complete transcript of speaking notes. Thanks to all attendees, question-askers, live-tweeters and folks I got to hang out / geek out on mobile with.

Transcript:

[Slide 1]
Hi. My name is Jen Matson and I’m an interaction designer and user experience architect. Today I’m going to talk about ways of crafting a great user experience for the mobile web.

[Slide 2]
But there are no simple directives for doing so. And insights about how to make the right design choices often come from trial and error, as well as experiences we have as users. That was my path — a winding one. So I’m going to share with you a little of not only my thinking, but my process.

[Slide 3]
Think of it as a treasure map, but instead of one big “X,” there are a number of different stops on our journey, from a visit to a Sears store, to a look inside our users’ heads, to an exploration of some myths, to an examination of some concrete technologies you can use. First stop: Sears, or how I came to be there.

[Slide 4]
At the beginning of this year, 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 5]
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 6]
I go 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 7]
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 8]
“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. So then I went directly to “m.sears.com”, got their mobile site.

[Slide 9]
I repeated my search phrase there. But I didn’t really get anywhere there, either, just over 64 thousand results for things like jewelry. 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 10]
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 11]
Now this story dates from January or February of this year. So I wanted to check in and see how Sears is doing, mobile-wise. If you type “sears.com” directly into the address bar, you get taken to what looks like a new mobile site, much improved in both UI and functionality. But unfortunately, repeating my little scenario by following the top link on Google for “sears price match policy” resulted in…

[Slide 12]
This. Come ON, Sears! Clearly, there is still work to be done.

[Slide 13]
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 14]
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. Here’s one from a classic roadside ad campaign:

[Slide 15]
(Burma Shave ad, part 1 of 5.)

[Slide 16]
(Burma Shave ad, part 2 of 5.)

[Slide 17]
(Burma Shave ad, part 3 of 5.)

[Slide 18]
(Burma Shave ad, part 4 of 5.)

[Slide 19]
(Burma Shave ad, part 5 of 5.)

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

[Slide 21]
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 22]
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.

[Slide 23]
And the same campaign, adapted for taxicab and subway placements.

[Slide 24]
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 25]
So here’s where someone might say, “Great! As long as we understand these three things, let’s jump right in and create a great mobile experience. We’re ready!” To which I’d reply: “Maybe.” Because there’s one big thing, that can be summed up in one little word, that needs to be considered first and foremost.

[Slide 26]
That description of adaptive mobile design? That middle bit: “understanding user needs.” Above all else, you need to know your user, not just her place in space or gadget she’s using, but what really motivates her.

And if you already have a deep understanding of what drives your users to interact with your product, service or site in the first place, then: “Yes, fantastic, you’re ready.” Because that kind of research — really, just talking and listening to your users, whether it’s through usability testing, user interviews or even just surveys — is an essential not just as a first step, but an ongoing process. But hey, you guys are already doing that anyway, right?

[Slide 27]
Well, if you’re not, then all bets are off. Unless you’re designing something for which the target users are pretty much you, there’s a good chance you’re making some wrong assumptions about why and how people will use your site. And we know how that one goes.

[Slide 28]
Because, the funny thing is, Sears actually got bits of the “canvas, capabilities and context” piece right. They anticipated that yes, I might want to view content tailored to the small screen of my phone, and Sears.com correctly detected my mobile browser. But by fixating on the presumed object in my hand, the experience is disjointed, untethered from the thoughts in my brain.

[Slide 29]
What’s my immediate task? Get information on their site I requested by tapping on a link. And that’s actually a sub-task of getting price match policy info. And that is the same task whether using a phone or computer browser. And my actual goal, the reason why I’m standing there in the store? To buy something. Presumably, Sears wants me to do that. And wants to support me in any way they reasonably can to help me reach that goal. Define your user goals and tasks, and *then* you can start to use those mobile considerations to better shape the experiences you design.

[Slide 30]
So, considering your user’s goals and tasks is essential, but getting that data can be kind of tricky. To get it right, you ideally need to be doing your own research. And while it’s not a substitute for user research, industry research can be amazingly helpful in providing general information about user behavior and context issues. Much of this research generously shared by mobile pioneer Luke Wroblewski on a regular basis on his web site, at lukew.com. And mobile analysts like Horace Dediu and Michael Mace help make sense of this data, synthesizing, charting and reflecting upon it, to create a multi-dimensional view of what’s happening in the industry based on observing mass mobile purchase and usage behavior.

So along with insight about your site’s users, this research is valuable in helping to create a realistic picture of the mobile Internet user.

[Slide 31]
In fact, actual behavior is so varied, it can be most helpful to start training your brain to NOT jump to certain assumptions about mobile Internet usage. Mobile designer/developer/author Josh Clark has written and spoken quite a bit about some of these mobile context myths, but I’d like to review a couple of which are probably the most important — or dangerous:

[Slide 32]
Well, of course! What makes it mobile is that you’re, well, mobile. Some of the time, yeah. Catching up on email and news while sitting on the bus headed to work is a perfect example. But I’m also using a mobile device while sitting on the couch, watching an old episode of “Law & Order,” thinking “hey, that actor looks *really* familiar” and then grabbing my phone on the coffee table to hit IMDB to do a quick search. Both scenarios are equally valid.

[Slide 33]
Even if certain mobile carriers focus on the first one. Over and over again. After all, if we’re NOT on-the-go, then we’re less likely to be using their service, right?

[Slide 34]
But the research data tells that nuanced story that reflects my mixed home-and-away usage, and probably yours. In fact, an even *larger* number — 84% — report accessing the Internet on a mobile device while at home.

[Slide 35]
This myth stems somewhat from the previous one, in assuming on-the-go usage can lead to justifications for removing content or features to presumably better serve these distracted, impatient nomads. And sure, it’s much easier to chop things out from your desktop web site to fit a small screen than re-think your site structure and navigation to best accommodate mobile use.

Here on the “desktop” version of the web site for retailer Nordstrom, we see a lot of ways to shop, and links to support that activity by getting users to the right departments and brands.

[Slide 36]
Another feature that is very well-liked by users, and is an especially popular promotion around the holidays is the free shipping offer, something proven to help increase sales. Here we see it promoted in two different spots. Clearly, it’s important, right?

[Slide 37]
Well, apparently not so important to mobile shoppers, as the mobile version of Nordstrom’s site omits any mention of free shipping. For some reason, different content choices are being made here, and presumably not to optimize for the mobile context. In fact, this disconnect is likely less a choice and more an accidental byproduct of not synching sales channels. But it’s still an example of treating mobile users as second-class shoppers. And while there is a link to the view the full site at the bottom of the page, that’s only useful for shoppers who have a specific task in mind they can’t complete using the mobile site.

[Slide 38]
Oh, and I almost forgot — before I was able to see the Nordstrom mobile site at all, I had to suffer through this pop-up, one of my main mobile site pet peeves. You have an iPhone app. Congratulations! Now can I get back to shopping for a new pair of boots already?

[Slide 39]
Someone might say, well, people are more likely to shop online using their computer. Isn’t it hard to see pictures of clothing on a tiny screen? Well, 25% of U.S. smartphone owners, about 22 million Americans, say that they mostly go online using their phone, rather than with a computer. Those people will likely never see the “free shipping” message on the “main” Nordstrom site, because, for them, the mobile site *is* the main — and only — site.

[Slide 40]
So, you know your users and what they want, and you’ve got a better understanding of what’s fact vs. fiction through industry research. All you have to do now is start creating that experience. How do we apply them to the design of mobile web sites?

[Slide 41]
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 42]
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 43]
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 44]
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 45]
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 46]
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 47]
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 48]
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 49]
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 50]
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 51]
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 52]
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. This may sound like a fantastic way of tailoring your content for mobile, and it is. But media queries are not the silver bullet for your mobile solution. Ensuring you don’t serve desktop assets to devices on slower connections, for example, is something that is trickier and requires additional techniques to achieve.

[Slide 53]
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 54]
…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 55]
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 56]
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 57]
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 58]
Of the features mentioned today, it’s important to note that while not all are currently supported by browsers on the most popular smartphone platforms, the majority are. This is an excerpt of a chart from mobilehtml5.org that covers the features I’ve mentioned and many more. So you should refer to it when deciding whether or not it makes sense for you to use a certain HTML5 or CSS3 feature for your mobile site. Even so, it can only show you what the latest and greatest devices are capable of, as most Android users, for example, are stuck using older versions of that OS due to lack of updates from carriers or OEMs.

[Slide 59]
So, I know that’s a lot of information to absorb. 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.

Research is essential to get a mobile site or app right, since there are so many people doing it wrong.

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, in order to create mobile web experiences that are both adaptive and exciting, it takes close collaboration between designers and developers, with each ideally moving closer to the other’s role: designers familiarizing themselves with code to understand capabilities and create prototypes, and developers getting involved as early as possible in the design process, to help shape the discussion with their in-depth knowledge of platforms and technologies.

[Slide 60]
Here are a few great resources that have more information relating to some of the ideas presented today, including some folks I’d recommend following on Twitter for the great links and other mobile web-related content they post on a frequent basis. All the sites have tons of examples, many of them interactive, so you can see these and other techniques in action.

[Slide 61]
I hope you’ve found some tangible things you can use in crafting better mobile experiences. I also hope that you’ll find — as I did — that taking the first steps on that path by putting yourself in the minds of users, and starting to use these techniques to enhance your existing sites, you’ll be able to see how rewarding an adaptive approach really is.

[Slide 62]
Thank you.


The Illusion of Control


photo: P Hansen

My father took a lot of pictures. Photography was a hobby and, for a short while, part of his professional life while an engineer at Polaroid. I grew up loving the click-whoosh of an instant photo being taken, slip of murky proto-photo being ejected into waiting hands. Pulling to expand, then snapping flat the brushed metal and leather-paneled slab… just getting to handle the camera was almost as fun as staring at that inky square, waiting for the image to appear.

Photos would get pinned to the fridge by magnets or to the cork board in the entryway with pushpins. Most of those would eventually make their way into one of the large, three-ring photo binders that collectively served as our multi-volume Family Album. And there each photo would sit, layered in plastic against an adhesive-backed, card-stock page, waiting patiently for that holiday visit by relatives. Not long after their arrival, binders would be taken down off the shelf and rifled through for collective reminiscing and occasional moments of embarrassment. (Plaid bell-bottoms!)

Of course nowadays, I can snap a funny photo, upload it to Flickr or Twitter or MLKSHK, and quickly get comments (or “likes”) from my friends. Or I could go a step further and toss it up on a different kind of site, like Canvas, where my photo would serve as raw material for a cycle of remixes and captioning that ends only when all the lulz have been wrung out of that particular creative sponge.

Now, some people might dismiss the purveyors of silly photo mashups as nothing more than juvenile mouth-breathers killing time between flamewars. And many people want nothing less than to have their personal photos subjected to (often ridiculous) manipulation by strangers. But somewhere between that static photo album and the photo-free-for-all is the space in which most of us probably play. We want to share our pictures, and solicit comments, approval, acknowledgment. We’re willing to release them out into the world to be viewed and experienced in many different ways.

The web is not a photo album. It can’t be. It shouldn’t be. I put up content, you read it, view it, share it using a phone, a computer, a tablet, a PC. Then you might print it out, repost it somewhere else or make it your computer desktop image. You might even decide to make a CafePress t-shirt from it. (Though let’s hope in that instance I’ve released that image to the public domain or used a liberal Creative Commons or similar license.)

As part of sharing my content with you, I implicitly agree to your, at minimum, experiencing it in a different context than I might. After all, you might use the Flickr Android app to view a 320-pixel-wide version of my image, even though I might blanch at the thought of browsing my own photo library in anything less than full-screen mode using iPhoto on my 22″ widescreen monitor.

But as soon as I release that image onto the web, that’s my problem, not yours. I’ve relinquished a certain degree of control.

And such is the case for any content I, you or anyone might choose to put on the public web. Yet so many web designers seem to, if not actively fight against this notion, be made uncomfortable by the fact that you might choose to browse their shiny new web site using a netbook, or a phone, or just a smaller-than-fullscreen web browser on a computer. We need less “my design is meant to be viewed” and more “our content is meant to be enjoyed.”

So how to begin changing the conversation? While many of the ideas will be familiar to those who followed the aims of the Web Standards Project (“simple, affordable access to web technologies for all”), established in the early part of the past decade, the web thinkers, designers and developers rallying under the current banner of “Future Friendly” have summed things up quite succintly in three basic points. The first one, in particular, makes a rather nice manifesto in and of itself:

Acknowledge and embrace unpredictability.

In other words, get comfortable with being uncomfortable. Accept there will always be a new device, a new technology, and entirely different way of experiencing content. And step two is, naturally, to carefully consider and prepare anything you might unleash onto the web accordingly.

Perhaps unsurprisingly, most of the people behind Future Friendly are largely approaching this from having done a lot of work in the mobile space. Quite frankly, the explosion of mobile has been a much-needed kick in the pants to further dissemination and adoption of these broadly-applicable ideals. When mobile Internet usage is growing at such a fast pace that, by current estimations, its volume will exceed that of desktop Internet usage by 2015 (if not sooner), it becomes impossible to deny that web sites unfriendly to mobile use are simply unfriendly. Period.

Things that may be a minor annoyance when experienced in a desktop browsing context — minimum browser window widths, plug-in downloads and long page-load times — often become intolerable in a mobile one. Attempts by designers and developers to shape the experience by elevating form over function only serve to drive users away.

Sites like Media Queries strive to highlight some of these newer, adaptive designs that change to suit your screen size in the same way CSS Zen Garden did for site using web standards almost ten years ago. And there’s movement away from plug-ins towards web-native experiences, as evidenced both in an announcement by SlideShare this week that they were ditching Flash in favor of HTML5, and a report last month that more top web sites are now using web-native-technology-leveraging jQuery than Flash. And mobile web pioneers like Yiibu (Bryan Rieger and Stephanie Rieger) continue to not only evangelize for better context-appropriate web experiences overall, but share actionable insights in amazing presentations like this one about some of the ongoing issues with serving that right experience, at the right time, in the fastest possible way.

In these ways, we’re still figuring out the mechanics of how to harness certain technologies and approaches, and when to discard others, all in the service of removing barriers to truly delightful experiences.

And it truly was a delight, using that Polaroid camera. I may not longer own it (and getting more film for it would be a challenge in and of itself), but that kind of connection is something that I’ll always seek out, in experiences both tangible and digital. Designers and developers who strive to be future friendly should end up being user friendly, which gives them that much more of a chance of wowing me. And that’s a challenge I’d love for more of us web professionals to take on.


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!

Transcript:

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


Speaking at the Midwest UX Conference

This past weekend, I learned that the proposal for my presentation on mobile UX design was accepted for inclusion in the program for the Midwest UX Conference, happening April 9-10 in Columbus, OH.  Huzzah!  I am honored and excited at the opportunity to talk about some of the specific technologies and techniques used to create great mobile user experiences.  And I’m looking forward to meeting other UX peeps and learning a whole hell of a lot in the span of just two days.

While the Midwest UX web site has the complete and detailed program, below is the description for my talk, one of four mobile-themed presentations happening as part of the same afternoon session.

Saturday, April 9

Afternoon Session A 2:10 pm – 4:00 pm

Adaptive Mobile UX Design / 2:30pm 2:50pm

Whether putting pen to paper or mouse pointer to blank canvas in your wireframing program of choice, most of us still pick an unconscious 1024 x 768 pixel resolution, landscape-orientation starting point for our designs. And if we need to design for mobile, it’s often on a completely separate track that uses a limited subset of the content and functionality we plan for in the “main web site”.

But with smartphones now projected to be in the hands of half of all Americans by the end of this year (citation) it’s vital that user experience architects understand some of the mobile-centric techniques and technologies that developers are already experimenting with.

In this presentation, UX professionals will see specific examples of HTML5 and CSS3 that have greatest impact on the user experience, including:

  • HTML5 form types used to create smart soft keyboard UIs
  • CSS media queries that serve up custom versions of the same page, making them truly responsive to any screen size and resolution
  • Device-orientation and location-awareness technologies that add a context layer to the experience of using a site or application
  • Semantic HTML5 tags that bring our wireframes closer to the code that developers use to create finished web sites

Any user experience professional, even those not yet working in mobile, can benefit by viewing these new techniques and being aware of how they can be used today and involving designers and developers in that conversation.