Design for Mobile First!

About Luke Wroblewski

As always we all had a great time last Friday with our long time friend LukeW at his second ZURBsoapbox.

Luke made a strong and valid case of why we should focus on designing for mobile vs. the desktop. Not only did he tell us why, he also focused on how we should design for the mobile. Listen to the full podcast as your read through the highlights below.

"Everyday 1 million mobile touch devices are put into consumers hands. If you do not design for this audience you're missing a million people a day."

Growth = Opportunity

Luke started out by shocking us with some amazing statistics:

• Smartphone sales will surpass PC sales in 2011.
• AT&T's mobile data traffic increased 50X in past 3 years (1492% increase).
• Mobile internet adoption has outpaced desktop internet adoption by 8X.

Everyday over a million smartphone devices are enabled and put into consumers hands. Anybody who doesn't have a mobile version of their product is missing a million people every day.

Constraints = Focus

Luke reminded us that one of the most impactful smartphone constraints is the screen space. Instead of 1024x768 size canvas we only have a 320x480 canvas to work with. Therefore every pixel on the smartphone screen needs to focus on core actions. Loosing 80% of the screen space forces you to focus on the most important set of features for your customers. A great example of this is Southwest website and smarthphone app examples below.

Constraints = Speed

You never know when your mobile network signal will drop on you. Luke shared some tips on how to speed up your app by making it leaner.

Reduce requests and file size:

• Eliminate redirects.
• Use CSS sprites to serve multiple images.
• Consolidate CSS & Javascript into a single file.
• "Minify" your code.

Take Advantage of HTML5:

• Load contents lazily.
• Use application cache for local content storage.
• Use CSS3 and canvas tag instead of images where possible.

Capabilities = Innovation

Luke boosted our desire to develop for mobile with a list of smartphone capabilities that we as developers and designers have at our fingertips to innovate on.

Using Touch

Touch reduces the level of input and makes the app simpler and easier for the user.

• The minimum touch target size on an iPhone is 29px wide by 44px tall
• A developer must first identify what action a user should perform
• Luke's basic touch gestures guide helps you figure out which gesture corresponds to that operation and how you can implement it

Using Location Input

Location input gives you a different lens for your design. Luke used Yelp as an example. Anybody trying to find a place to eat though the Yelp website will have to type in their location and sort through a giant map of places. The Yelp iPhone app combines Touch and Location to accomplish the same task of finding a place without the input of location and by using just one touch.

Luke continued on with a whole series of other capabilities we can innovate on such as orientation of the device, audio and video, and others. At the end of the day Luke reminded us to remember that:

• Mobile growth is exponential and we can't ignore it.
• Mobile constraints keep us in check and focused on core actions.
• We have tons of capabilities we can innovate on.

The talk had a lot more details and information which you can get by listening to the full podcast above or checking out Luke's interview with Jeffrey Zeldman and Dan Benjamin on Mobile First.

We'd like to thank LukeW once again for showing us why and how to design for mobile.

---

Transcript

Luke: All of these big corporate entities right now think that they need to do something with mobile, but they have no idea what to do with mobile. People that use Facebook on their mobile device are 50% more active on Facebook than non-mobile users.

Since I think that designing for mobile's important, I'm not just going to tell you it's important, I'm going to give you some practical things that you can take away right now, to go and start making mobile experiences.

Moderator : Thanks everyone for coming to ZURBsoapbox. Super-stoked to have Luke here, Luke the entrepreneur in residence of Benchmark Capital, and quite recently founder of a self-startup, which we all want to know more about.

Luke: It's a ZURB 2.0.

Moderator : He's the former chief design architect at Yahoo!, where he was responsible for one of the most trafficked websites of the world, no big deal.

Of course the author of "Web Form Design" and "Sightseeing: The Visual Approach to Website Usability." These books were praised by folks such as Jakob Nielsen and Irene Au, and many, many others.

With that, let's welcome Luke to his second ZURBsoapbox.

Luke: I want to apologize to you guys sitting behind me. I could try doing it like this, but I don't think it's going to work.

You guys all right? All right.

Yeah, thanks for having me. Excited to be giving this talk in a smaller, intimate kind of venue.

To set some context, I originally pulled this presentation together to go and talk at a conference for web designers, and really trying to put the focus on people that have been traditionally building for the desktop web, and give them a little bit of awareness of why they should start caring about mobile a bit more emphatically than they currently care.

Since then, I've actually gone into a couple corporations and walked them through the same talk. Wal-mart, Netflix, LinkedIn, doing Best Buy pretty soon.

The reason I bring that up is because it's really, really interesting how all of these big corporate entities right now think they need to do something with mobile, but they have no idea what to do with mobile.

There's a huge opportunity, one for people who have been doing web application and web services design and development for quite a while to take advantage of mobile.

B, the people out there that have the investment capital to do interesting things are very, very interested in this and foaming at the mouth, and are just waiting for people to come in there and say, "This is what you should do." They don't seem to have that.

This is an approach that I've been talking about, and it's pretty simple. Do the mobile version first. When you're thinking about something that's going to be a network integrated service, whether it's social-based or productivity-based, analytics-based, if you build the mobile version first, some interesting things start to happen.

Usually it's done very much the opposite way. We build to the desktop first, and then we think about how to port it over. I think that's increasingly a backward way of doing it.

Sub-bullet here, even if you're not planning a mobile version, this is worth doing. I'll explain why in a little bit.

Don't just take my word for it. There's actually a lot of other people who are a little bit more qualified than myself to speak on such matters.

One of which is the CEO of Google, who's basically saying the folks at Google are doing mobile first because A, it may create better applications, and B, that's what the top programmers over there want to do. Google is run by what the programmers want to do, for better or worse.

He feels that the mobile phone is an intersection of three intertwining factors that really define technology trends. One is computing power; we've got more computing power in smaller and smaller packages over the years.

Connectivity, everything's connected to the network now. Cloud computing, when you get connected there's services sitting on those servers there, content sitting on those servers. Through that connectivity, you can actually do stuff.

Don't just do things because Eric and I say so. Here's some actual reasons, and I'll walk through each of these.

First one's really about the growth that's happening in mobile, and it creates an opportunity not just to have a mobile version of your site, but to have an integrated experience across mobile, and across a desktop.

In my current role as an entrepreneur at Benchmark Capital, I sat in at a half-day presentation of all the companies that Benchmark has invested in. It was amazing how many of the companies there were seeing engagement and added growth through the mobile experience.

Companies like Yelp, companies like Open Cable, companies like Zillow all saw mobile as an addition to what they were doing relatively to the amount of engagement they have.

They've got a million users on the desktop, and then the people that are using their mobile version are adding to that. It's not that they're moving from the desktop to mobile, it's all coming together and creating more opportunities to provide value to customers.

Growth is happening. Constraints. I think if you work within the constraints that exist in mobile, you're going to end up with a better product over all when you move it to the desktop.

Then third, but not least, the capabilities that we have in portable computing devices now, really, outside of computer processing power, the capabilities we have from a sensor detection and environment awareness perspective blow away what we have on the desktop or on a laptop, which creates a ton of really interesting design opportunities. Since I think designing for mobile is important, I'm not just going to tell you it's important, I'm going to give you some practical things that you can take away right now to go and start making mobile experiences.

The first one is this opportunity that the growth of mobile provides. For years now, people have been saying mobile is the next big thing. It's become sort of a cliché.

If you look at what's happening now, a lot of really good data is coming from Morgan Stanley Research. They're doing a lot of releases of really interesting information.

The only thing to note here is, if you add up the amount of connected devices, including tablets, cellphones, smartphones, wireless home appliances, things like the Kindle, you're looking at a 10X increase in the amount of devices that are accessing web content than currently access it through the desktop one billion device model.

If you remember the exponential growth that the web had back in its heyday . . . it's still in its heyday, but when it was growing exponentially, the mobile web is growing eight times faster than that, which is astounding.

Literally next year, many predictors say smartphone sales are going to surpass PC sales. In other markets, that's already happening around the globe, but in the US it's coming.

Why did this happen? You can call me a fanboy if you like, but the process of browsing the web on a mobile device before the iPhone, before June 29th, 2007, basically sucked. If anybody tried to use the web on a feature phone, it's abysmal.

There was no reason to do it, and it was awful, terrible, and therefore no one did it. As soon as Apple came out and said, "Here's a device that makes it not suck, and actually makes it good and in some cases great," the usage took off.

AT&T, who's been the exclusive carrier of this device, has seen a 50 times increase in three years.

I have a whole bunch of other statistics on how mobile's growing. You need that to go and convince bosses or clients or anybody that pays the bills that mobile's important, can go in and see the crazy numbers across the board about the impact that this stuff is having.

That's one thing. It's not just an opportunity to say, "Hey, here's this huge growth curve, let's get on that and run it." It's also an opportunity to integrate what's happening when people are on the go with the existing service they have.

Instead of porting, really thinking about a more holistic experience.

This is Joe Hewitt. You guys can't see him so well, but he made this app. This application on the Apple App Store, it is locked in this one-two battle with the Koi Pond app for number one place.

Pretty consistently week over week. One time Facebook will win and the Koi Pond app will win, Facebook app will win, but regardless it's one of the most popular mobile applications on that platform.

I really like this quote from Joe. He says, "First I was trying to do this port, I was trying to make this mobile companion for Facebook." Then as he got into it and he started building it, he actually realized he was able to create a version of the product that was actually better.

If you look at the numbers on Facebook, people that use Facebook on their mobile device are 50% more active on Facebook than non-mobile users. Within the course of six months, Facebook moved from 65 million on Facebook mobile to 100 million people.

This is getting a lot of engagement.

There's an opportunity to capitalize on this growth, the next big computing cycle, and there's an opportunity to integrate and think about this as a new complement to the experience that provides incremental growth, that ties into what's happening on the desktop.

The other really exciting thing from the design development perspective is that designing for mobile really forces you to focus and prioritize, because of screen size, performance, and the constraints of the mobile context.

The first constraint that I want to talk about here is screen size. Essentially if you're designing for a typical web service application on a laptop or a desktop, this is how much space that people generally plan for, 1024 by 768.

Move to a device such as the first three gens of the iPhone, the first couple Android phones, or the first line of Palm phones, and you've got 320 by 480 pixels. Which means you just lost 80% of your canvass.

80% of the space you had to put shit on is gone, which I think is awesome.

Why do I think this is awesome? Because it forces you to really get down to the things that people actually care about. What are the things that are most important?

Let me show some examples. This is Southwest Airlines on the web. Everything in here I care about. This is Southwest Airlines on the mobile.

There's a great alignment in this experience here between what Southwest Airlines does and what I want as a user. They sell airline and car reservations, I can check into my flight, see how my flight's doing, I can manage my rewards.

Because it's a mobile device, fare alerts maybe matter a little bit more. If something goes down, I have my phone with me all the time, I can get an alert.

Here, this whole experience is really focused on the things people want to do and the things that are good for the business, and nothing else. Versus that.

If Southwest Airlines started with this experience, where they have to get rid of 80% of the stuff on the screen, it really gets them down to a focus. When they come back to the desktop, maybe they end up with something like this.

Ironically, this was the Southwest Airlines website before they did this. I don't know what the hell is going on over there. I think they hired a new VP of marketing. That's my suspicion.

You'll note here, in this version you have this. Fare alerts isn't as prominent. When I say do the mobile version first, there's things that make sense on a mobile device that maybe don't make sense on a desktop.

The two things don't have to be exactly the same, but in most cases you don't want to deprive people of the things that you do that they like just because they're on the go. Most of the stuff's the same, but there may be a little bit of variation.

Another example you guys may be familiar with. This is Flickr. You probably know that this is a photo sharing site, but you might not know all the things it does. In fact, Flickr has grown a lot over the years. Just looking at all the options they present to you, in this version there's 60 plus things here that you can do on the site.

When they designed the mobile version, they got down to eight. Eight things. You can check out what's happening in terms of who's commenting on your photos, what they're doing. See what kind of photos your contacts are uploading, see what's new and interesting.

Again, I mentioned there's this mobile component, see which photos are nearby.

How does Flickr go from 60 plus things down to eight? They really have to know their audience. This is Design 101, right? Know your audience, know what they're doing on the site, understand where you're creating value and where that creates value for your business, and focus on that.

Mobile really makes you do it. There's no choice when you lose 80% of your pixels. You can't have that kind of experience.

This doesn't just apply to sites at the top level. This is a page on Expedia, where you see your flight itinerary for a trip you booked on Expedia. The part of this page I care about is that. Everything else could just pixelate and die and go away. I don't need any of that.

The mobile version of Expedia, ironically, does that and does it even better. Here's when you're leaving, here's when you're landing. You can tab through the different dates of your trip, you can tab through the different itineraries.

All of this . . . I don't know what to call it, cruft, is gone. It's just focused on what you need from the service and what you can do.

Going through this process of getting down to 320 by 480 really forces you to focus. In order to focus, you need to prioritize, and in order to prioritize, you have to know your audience and what you represent.

That is very, very healthy. When you do this design for mobile process first, it's very healthy for the organization to keep whittling down, what do they do? Somebody says, "What about this?" There's not really room for that, is that really important as this? No? Okay. We just gained some clarity on what matters for us and for our audience.

One of the reasons why I like using the iPhone as an example of where you can start trying to design for mobile screen is they have a couple constraints that make it good.

One, if you compare Android, this is Android over here, this is the iPhone right here. Android, Nokia, a couple of these other devices, including Palm, have a menu button on the hardware, which gives you a whole bunch of options that you can access.

If you look at the iPhone, there's this one button here. On Android, they have this menu button. What that gives you is essentially a miscellaneous bin where you can throw functions that you can't agree on, whereas you can't do that on the iPhone. You have to put it on the screen, otherwise it's not there.

I like using that device form factor as a starting point here, because you don't have this cop out layer where you can take stuff, "I'll just put that in the menu." You have to determine whether it's actually important enough to be on the screen.

Working in that manner, not having a hardware dependency, forces you to work from the principle of natural user interface, where the content becomes the action.

You only have this amount of screen space, you can't devote it to a lot of buttons and sliders and widgets and all these sorts of things, because where's the content going to go? What you end up doing with the UI is you work to make the actual content the user interface.

On the iPad, you touch these groups of photos, they expand, you go in there and slide your finger across the photos. The content becomes the interaction.

With these sorts of devices, I think that's a very good approach to doing design, because it helps to get people interacting with the stuff that actually matters, as opposed to fidgeting with close icons and windows and all the other stuff that in the desktop takes up a ton of time.

By the way, when you move to the iPad, just because there's more screen space you shouldn't add a whole bunch of stuff.

The other reason why iPhone is a nice platform to get you started on mobile . . . and don't worry, I'll talk about Android and all these other things in a second.

It's surprisingly stakeholders and business owners and these kind of things, people that generally don't care about design, when you all of a sudden start working on something on the iPhone, all of a sudden they really care about design. It's a nice opportunity to push the design forward.

This is an image of an app that somebody made for the iPhone. This is the Flickr conversation around it. "Dear God, my iPhone's crying." "Take his developer card away, please." "This is why Apple shouldn't allow anybody else to make apps."

There's this bar that you have in place that people are subconsciously and sometimes even consciously aware of. It pushes the design aesthetic forward, which is good.

If you're actually building for the mobile web, you have to think about more devices than just the iPhone. Maybe, maybe you don't, depending on what your strategy is. Regardless, you need a device strategy.

I'm not going to get into how to create a mobile device strategy. That's a much longer conversation.

Designing for multiple screens, if you choose to work toward multiple devices, is something you need to take into account. It used to be relatively easy. The iPhone came out, 320 by 480, the next series of Palm devices was the same. The first round of Android devices were the same.

Roughly this magic number over here, the PPI, which I'll talk about in a second, the pixels per inch, was relatively consistent.

Then you had the next set of Android devices, and I should put a few more of the new ones on here too. All of a sudden they're increasing the pixel density and they're really driving the PPI higher.

Devices like the N900 and now the new iPhone 4 are moving the PPI from what you get on a typical desktop screen to 256. What does this mean? It means that if you're looking at something that's 72 pixels per inch, it's this big. On the N900, it's that big.

If you're designing for something on your cinema display that's 94 pixels per inch, it looks that big. On Nokia N900, it's literally that big.

This device, pixel per inch issue is something that people need to start taking into account. If you're working through your comps at this level, nobody's going to be able to use it.

Working in vectors can actually help a lot there, and I'm still waiting for a product that works in vectors and locks into specific PPI, so you can just save out assets. That doesn't seem to exist.

That's one thing to take into account. Then if you're actually designing for multiple screens, this is something that I literally just took from Brian Reader, because I think he's done the best job of laying out a strategy here.

Your first role is to say, okay, based on the devices we're targeting, here's the way they group given their screen widths. You can use things like Device Atlas to get a sense of the screen widths out there, and make your own groupings, lots of different groupings online.

From those groupings, you say okay, here's the reference design for this grouping. Then you can design that first. Then what you do is define these rules for adaptation.

In our reference design, things work like this. When it goes to this other group, things shift like this. When it goes to that other group, things shift like that. You have this default reference design, then you lay out, here's the rules on how it adapts when it moves between the different groups.

Last but not least, especially on the web, if you use web standards and a flexible layout, and now CSS3 media queries, you can get a lot of these things happening a little bit more dynamically as you adjust them.

These fluid, scalable, flexible layouts that have been a good practice, but people go back and forth, grid, liquid, what have you. I think with a multiple device universe it makes a lot more sense now to always be thinking of fluid layout.

Screen size forces you to focus. In order to focus, you have to know your users. If you're going to start with some sort of device, I think a 320 by 480's a decent pixel screen size to start with.

Speed is another thing that is a constraint on mobile that helps you get to good product design, period. You never know, when you're out and about and this happens. Has this happened to anybody?

You have to really try and drive for great performance, and there's two buckets of things you can do on mobile. One is just reduce the amount of stuff you're sending over. That's not just file size, it's also the number of requests.

The other thing, which I think is more exciting, most modern mobile devices have HTML5 capabilities built-in. The notable exception is the Windows 7 phone, which is basically running IE7 with a little bit of IE8, and is terrible.

Everybody else is now coming onto web kit. Nokia and RIM are sort of the laggers, but they both are releasing web kit browsers in their next OS. Inside a web kit, you've got HTML5 support for things like CSS3, for things like app cache, which means you can store things locally.

You can use code to create images instead of sending images over, so you can do gradients that way. You can do rounded corners that way, drop shadow, text shadows, all sorts of fun stuff.

Performance doesn't just matter on mobile. It matters on mobile obviously because you have limited bandwidth, but across the web there is examples left and right of how even millisecond delays add up to negative experiences.

Google released their recent study that shows there are actually long term effects to this. They did a study. They dropped search speed a little bit in terms of milliseconds. Over the course of even three weeks, people weren't coming back. Because they had a bad experience with site performance, that doesn't just send them away, it keeps them away.

The third context that I think serves as a constraint is you have your mobile device with you everywhere, and you're using it in quick little bursts. This is a Microsoft marketing video, but it illustrates these little bursts.

Here's a woman, oh, she sees something she likes, she's going to take a quick photo and send a picture of it. Here's a kid killing a couple minutes to check the weather, now he's playing a game for two minutes.

In comes a text message, so he's going to go give that to Dad, and Dad's going to rattle off a thing.

She sends this over here, she's going to be in the record store, she's flipping through some photos and showing her friends. It's these little micro-interactions going on throughout the day and in context. Those define the kind of behavior people have with portable computing devices they have.

In fact, in a typical day, 80% of people are going to use their smartphone in miscellaneous times throughout the day, 74% of them are using them while sitting in line.

Services or applications that are optimized for these quick burst use cases, small, quick time-killing tasks, things like Twitter and Facebook where you can just check in for a minute, see what's going on? These things are going crazy on the mobile web and on mobile devices.

112% increase, 347% increase, because they're optimized for that use case. They're optimized for that, "I've got a couple minutes to kill, let me just check in on something."

When you look at the rest of the web, turns out that these quick, in and out behaviors are really all over the place. This is a study of half a billion URLs, and the peak time that they were displayed for was between two and three seconds.

In fact, over half of all visits to any of these pages was less than ten seconds. People are using these quick interactions anyway, and if you design for mobile first, you focus on these quick burst interactions and you get to have that advantage when you get to the desktop, too.

The other interesting mobile constraint is one-handed touch. Anybody seen somebody walking through the street, doing this kind of thing?

In order to accomplish this being effective, you have to simplify the UI, make sure it can be used with literally a thumb or a single finger, which is big, broad simple actions. Again, simplifying your UI is a good thing.

That was constraints. I'm sorry I'm going through stuff fast, I want to get all this info in before I keep you guys here too long.

When you look at constraints, there's screen size, there's performance, and there's this mobile context. When you start with the mobile version first, you apply those constraints and you get the benefit of being aware of those constraints when you move to the desktop.

You've made it really, really fast for mobile because performance matters, well, it's going to be fast on the desktop. You've optimized it for these quick burst, in and out actions. Okay, now you've made something on the web that people can use every day.

The other thing about mobile context that I didn't mention which is important is your mobile device is something that you have with you throughout the day. When you create a service for it, you should think about something that people can use throughout the day, and multiple times a day.

Again, if you do that first, then when you get to the desktop you have that benefit.

Capabilities is the next thing, and this is really an opportunity to come up with new, inventive stuff. I talked about this one-handed touch being a bit of a constraint, but touch is also a capability you can start to innovate with.

Touch is really permeating modern operating systems. In 2009, there was a million touchscreen phones per day. While I'm standing here right now, 100,000 Android phones are going to be activated today. 97,000 iPhones are going to be sold today. 35,000 are going to be sold today.

All of these things are touch capable devices.

Looking at 2009, this is only going to ramp further. Every day, over a million Internet connected devices that are touch capable are put into consumers' hands.

If you have a website or a service that doesn't think about how people interact with it with touch, that's a million people that can't use it today. There's a million people that can't use it tomorrow, and it starts adding up there.

This is Nokia's smartphone [inaudible @26:54] and you can see touch in 2008 was a little blip. In 2010, this year, it's more than half the pie. Nokia is a company that has put 1.1 billion devices into people's hands this year.

There's a lot of stuff happening here. They're moving this aggressively into touch, it matters.

Recently, Ubuntu released touch gesture support. They've got it. It's sort of a hint.

The first thing about designing for touch is being aware of touch targets. We'll also talk a little bit about core gesture, we'll talk about how you apply those things to user actions. Touch targets really matter because we have fat fingers, right?

See that little circle there? The actual touch target there is this yellow box. Apple has this recommendation, given their pixel per inch, that it should be at least 44 pixels tall because the finger looks like yea when it comes down to the screen.

Microsoft has done even more research in here. They get into not only the recommended touch size but the minimum touch target size, the minimum spacing between elements, what the visual size should be.

It's also important to note that here they're using millimeters, which is dealing again with that pixel per inch model. Apple can specify it in pixels, because before they were dealing with single PPI.

When you get to multiple devices, you have to actually start dealing with physical measurements, because you don't know what the screen density is going to be on a mobile device.

These numbers are rooted from studies that basically show the average human fingerpad is ten to 14 millimeters, and the average fingertip is eight to ten millimeters.

This is not going to show up in this dark room, but you see this cancel button? See this yellow overline? This is how some of these systems enable the fudgy factor of the finger. If you hit that cancel button anywhere in the yellow area, it's going to activate the cancel button.

There's this green layer which I'm going to outline for you, because I can see it on my screen, basically spans that amount of the screen. While you're holding on that screen, if you move off that yellow button but you're still in the green area, it's still going to trigger that action.

If you move off the green thing it's going to cancel that action.

Again, if you're one thumb walking, your finger moves around a little bit. A lot of these operating systems have built in these affordances. If you start building something from scratch, you don't get these affordances for free.

You need to make sure you're cognizant of the fact that people can't really keep their finger on a single target area as they're walking around.

I mentioned some of the platforms. I think I should add Ubuntu and Research in Motion, RIM's, 6.0 thing because it supports multitouch as well. I think Nokia's new one is on here as well.

What we did when we took a look at what are the basic touch gestures out there and how to use it, we look at these platforms, we saw the touch gestures they supported, we saw how they were applied in the platforms and tried to rationalize that out so you have a bit of a toolkit.

If you look across these platforms, you can basically define some of these core gestures. One is tap at the screen. Double tap it. There's multiple finger versions of the first one. It's weird to double tap with multiple fingers, so that isn't very well supported.

You can drag things. You can flick things, flick is this quick brush. There's multiple finger versions of drag, not so much flick. You can pinch and spread things, and there's multiple finger versions of that.

You can press, which is hold something down, press and tap, press and drag. There's a couple variations on the rotate gesture.

These are the core gestures that they identified across all these platforms, but then how do you use them? The important thing is to know, what's somebody trying to achieve?

Are they trying to open something, are they trying to select something, are they trying to delete something, duplicate something, move something? Are they trying to pan through a list, scroll through a list?

This reference document that you can get a hold of here lays out these touch gestures from a, 'person wants to do blank, here's the common touch gesture that's supported across most platforms, and here's what it's called and how you can implement it.'

From there, you can start defining customized gestures. This is Microsoft Surface, where they have these user participation gestures. They take these core gestures and they extend them. This is essentially drag, that they've turned into simple drawing mechanisms.

Okay. If touch is a capability, what can you do with it? This is Yahoo!'s Finger Food app. You open the app. It makes a map of where you are. You draw a line or you draw a circle, and it says here's all the food in that area you just drew.

Instead of typing anything in or typing in a street corner or doing any of this sort of stuff, you just draw and use gestures as inputs to go and search for places to eat.

In fact, touch is making even basic, simple things better. This is a drop down menu on a desktop. Anybody tried to manipulate these? When you get to 50 states and they're two characters long, it's really great.

On a touch enabled phone, same interaction, you get this big touch target and you can essentially flick through this wheel to get to what you want really quickly. Hit a simple target and you're done. Android also has support for this, not as slick, but still.

Even to the extent that you can combine these together. Instead of dealing with three drop down menus per date like you have on the web, you've just got one scroll wheel that you move through and touch it, which I think makes things better. Android does the same thing.

Next thing I want to talk about is there is no hover. In some cases, hover is a kind of decent thing on the web. This is Netflix, when you hover over it gives you this back of bob thing. They spent a lot of time tuning and optimizing this in terms of how it behaves.

Then they started creating these kinds of hovers. When you go to something like a Barnes & Noble, you don't know what is going to hover where when you move your poor little mouse around there.

The problem with hover is that hovers aren't an intentional user action. It's, we're assuming what the user wants and we're doing things on it.

In general, it's usually a negative on the user experience side of the coin. In particular because these expectations aren't there. When you're on a touchscreen device, there is no hover, because there's no mouse clicking.

All this stuff you threw in here and said, "we'll just put that in a rollover layer," guess what? Now you have to decide if it goes on the screen or not. Which again brings you back to the level of focus. You can't use the hover as a crutch.

You can still use tips. A lot of times hover's just used for tips and information on the web. You can pop in a little thing and then fade it out, give people tips that way instead of relying on the hover.

Okay. That's location, that's a great capability that's permeating major platforms. Designing for mobile first forces you to think about how your web service is going to work on these touch based devices, and there's a lot more of those devices out there than there were before.

Location is another capability that's built into these devices. From a desktop, to find somewhere to eat in San Jose, I type a bunch of stuff, I get this map, and anybody here that knows San Jose knows that this is a huge area to cover.

I'm spending a bunch of time flicking through these filters, moving through these lists, moving around the map. When I use Yelp on the mobile, it default opens to what's near me. I just tap restaurants, and here's what's near me right now.

It really reduces the level of input and gets you information you care about right away. In fact, sometimes you don't even have to type in any input.

This is an app called "Where," and it just grabs your location and says here's the cheapest gas near you. Here's the weather near you, here's local news near you. You can get traffic near you, you can get movies near you. It gives it to you. You don't have to do anything.

It reduces input down to opening an app.

If you're interested, these are the types of systems that are in mobile devices and the degree of accuracy. They have different battery life and accuracy implications. Here's some more detail on it. I won't go into it.

Touch and location are very interesting capabilities, and hopefully that gives you a little bit of a sense of why it makes sense to design with them up front. Assume you have location, that will give you a different lens on your design.

If you assume you have touch capabilities, that will give you a different lens on your design.

If you design for the desktop, you can't assume you have that. In fact, we looked at app cache for local storage when we talked about performance, we talked about multitouch, we talked about location detection.

There's a whole bunch more capabilities that these devices have right now that you can assume are in the device when you design for mobile first, and then backport towards work away from them when you get to the desktop.

By the way, desktops are taking these things increasingly into . . . now Safari 5, Firefox 3.5, Chrome, all of them have the geolocation API, which gives you pretty reliable location information. Dell has released a bunch of new netbooks and laptops with GPS devices in them.

These things are coming to the desktop more and more, and I think that's a good thing. For example, Firefox recently released push notifications into their browser.

I have a whole series of things about some of the capabilities you can do, and I'll go through it really fast.

Orientation. When you change orientations, are you going to use that as an opportunity to make things better? Give people more room to type and include an action, or is the thing going to break when people change orientation?

Particularly on the iPad, there is no default orientation, so it's a thing you need to consider. This is a little notebook, and it flips into this mode. It's an orientation change.

How are you going to design your cooking service differently when somebody flips it like this and is actually in the kitchen making something? Or they're in this kind of mode?

Orientation right now is relatively early, but this is Firefox 3.6. It supports accelerometer access.

This demo's a little gimmicky, but you can start to think about okay, when somebody changes the orientation of the device they have, how are you going to change the experience? Is it going to be for the better, or is it going to be for the worse?

What kind of new things can we enable based on the fact we know the direction the device is positioned?

We also know the direction the user is positioned. Through location we know where you are. Through a digital compass or magnetometer, we know what direction you're facing, which means we can do crazy stuff like this.

Two years ago, if I slowed this slide it would be science fiction. Today, Yelp which released this little augmented reality monocle has seen a 40 to 50% sustained traffic increase through what they thought was an Easter egg.

The UI on these augmented reality applications is pretty clunky and broken, but the idea of overlaying digital information on the world around you as you're currently experiencing it? Pretty cool.

Voice. You can always do voice on the desktop, but it's really clunky. Google's Nexus One, any time there's an input field, you can hit a button or swipe the keyboard and it uses that as input.

You'll see an example here where you can search on Amazon using your voice. You can type a Facebook status. You saw that little swipe with a finger? It's great for when you're walking. You move your finger across the keyboard and say something into it instead of trying to type it.

Audio input is a capability you have available to you when you think about designing for mobile first.

Video and image input is also something you have available to you when you think about designing for mobile first. This is Google Goggles. You can put a picture of a book and it'll look it up for you. Tell you how much it costs, where you can get it.

You can take a picture of a wine label. You can take a picture of a business card and use OCR to scan the information and put it into your address book. You can take a picture of a work of art and it'll identify it for you.

You can take a picture of a landmark, and using your location and the image it'll tell you what you're looking at. You can take a picture of foreign text and it will translate it for you.

This is very early, crazy stuff, but the fact that everybody's got an integrated video and image capturing device in their pocket? That's really interesting capability that we can apply.

Now we've walked through that many capabilities. There's even more. iPhone 4 introduced a gyroscope and introduced dual cameras on the mobile device. I keep saying this, if you start on a desktop you can't assume you have any of this stuff.

If you start with the mobile, you can assume you have all this stuff, and it will probably lead you to very interesting interactions with the service and your product. You may have to back out of some of those when you go back to the desktop, but at least on the mobile you'll have that great experience that takes advantage of this stuff.

If you do the desktop version first and you never consider any of this when you port it to mobile, it'll be the same desktop version without any of these capabilities and any of these opportunities to do something interesting.

Those are the three things, wrapping it up. Mobile's growing like crazy, that gives you a lot of opportunity to take advantage of it. It's not just to have a mobile version, but to make your overall experience better through the integration of mobile.

Constraints force you to focus. Small screen, slow connections, mobile context, quick burst to use. Focus is always a good thing. As I mentioned at the beginning, I have a start-up right now and the number one thing we hear from everybody, "focus, focus, focus."

It's clearly something that's top of mind and seems to yield some type of value.

Capabilities, we talked about that. You've got all this stuff you can build on to do it. These are just some of the things I gave you to get going. How do you deal with multiple screen sizes and densities?

Performance optimization tips for mobile, touch targets, gestures and actions. What can you do for location, and what are the capabilities that are out there. If you're interested in more, I Twitter about this stuff, I write about this stuff, and if you want a book about web forms you can get it cheap.

Okay. Phew. Sorry I went through that fast, but I wanted to make sure you guys got lunch and I got through it.

Moderator : If you guys absolutely have to go, go ahead. We're going to do five minutes of Q & A really quick. If anybody has a question that came up during the talk?

Is there any product you shouldn't be designing for?

Luke: Sure. I'm sure there's some things that don't make sense at all on a mobile, but in general it's additive.

Again, I'm seeing more and more examples where companies that take . . . let's use the Open Table example. Open Table is a service for making reservations at restaurants that you can do online. You go in there and make the reservations.

They introduced a mobile component where it uses your current location to show you what's near you, and you can make reservations right then and there. They have integration with the phone so you can call them, what have you.

I can't remember the exact numbers, but they've seen something like a 25 to 40% increase in usage just through that simple capability. They've seen something like 500,000 phone calls made through the app to their locations, just through the iPhone app, to restaurants per week.

Something like that. [inaudible @42:23] This is a restaurant reservation thing. Zillow is a real estate app. Yelp is a place to go eat. I showed others, Southwest Airlines is an airline company. All these guys have something to do on mobile, I think. Maybe not.

Audience Member: What about the presence of ads as another design constraint?

Luke: Yeah, that's actually great. There's not enough room for big honking ads.

Audience Member: I agree. Yeah, but we seem to be being pushed that way.

Luke: To put more ads in there?

Audience Member: Yeah. They seem to be showing up by themselves.

Luke: I think the market will fix that appropriately. With applications, you choose to download them, and you remove them or add them yourself, right? If there's something that's annoying or you don't use, it goes away. Gives another competitor an opportunity to get in there.

I also think that with all these sensors that I outlined before, it actually gives advertising an opportunity to be more relevant, too. Because there's sometimes when you actually want advertising.

"I really want to eat something now. Give me the offers around food based on where I'm at. Don't give me those offers around food when I'm browsing for a new car."

Yeah?

Audience Member: On the content side of things, you really didn't really address [inaudible @43:49 to 43:53] . . . have you seen any differences with the [inaudible @43:55] most people are just opening things up and then shutting them down. Is that refocus your attention on how [inaudible @44:03] or is it . . . what did we learn about the content?

Luke: I think the same rules that make good content writing on the web are the same things that make good content writing on mobile, times two.

Getting to the point quickly, making sure you have scannable headlines and sections, not being overly verbose, which is all good on the web because people essentially scan content on the web to a large extent.

I think Jakob Nielsen released a study that said 25% of people actually read an entire article. 75% of them scan the bulk of them. We saw the same thing when we looked at Yahoo! News and Yahoo! Sports and all those.

Audience Member: On the web or mobile?

Luke: Web. This was on the web.

On the mobile it's probably even more exaggerated. That said, there are new services that are popping up that are optimizing readership for these new connected devices. The example I like to use, you guys may not be familiar with, called Instapaper.

Instapaper is an app where you see an article on the Web, you just save it for later. It strips out all of the navigation and everything, just gives you the text rendered as a nice article. Then you can access it on any other device.

What I've been doing, and many other people I've talked to do the same thing. They'll go and save a bunch of articles on the web, and then they'll sit on their couch with their iPad and just read through it, like it's a personalized newspaper for them.

It's actually more reading, because the device is better optimized for readability, and the content that they get through the Instapaper channel is more optimized.

In fact, Safari 5 introduced this controversial feature called a Reader, where they'll take any page . . . it's great. I use that thing all the time. It strips everything away and makes it nice and big text. You can get to the content and read it.

It's really, really fantastic. This goes back to the point about consumers are going to start demanding this. I can click this button and read this in this beautiful prose. Why the heck would I go to your website where there's 50 million navigation options and 20 million ads attacking me?

Audience Member: Or you've got to go through 20 pages to get finished.

Luke: Exactly. That's the other thing that both these features do. They'll go through the pages and roll it up for you, which is a good user experience.

Content publishers should embrace that model and give people content in the way they want it, rather then fighting them. People are going to get their own way anyway.

Yeah?

Audience Member: With all this stuff that's on mobile devices, how do you make a decision on what's going to be useful and what's going to be gimmicky?

Luke: Again, if you go through that focus process of determining what your users want and what you make money off of, then you can use that as a lens to filter against this.

Our core premise is to let people make reservations at restaurants. What applies there? Location. Okay, this integration with the phone, that probably applies there. Maybe some kind of a video integration of where they are to orient them and get them there. Maps integration.

Audience Member: I would think that would be really gimmicky. I would think there was no way that needs to go in there, but they found that that's useful, so maybe . . .

Luke: I was as shocked by this as Jeremy was. They thought of this as an Easter egg, essentially.

The way a lot of technology goes, that the first use is really awkward. Even the phone, the first phone conversations were like, 'Hello? Hello? Hello?' Really, really awkward because people didn't know what to do with the technology.

Now it's second-hand, and these norms develop and people figure out how to use it.

I think these interactions are very awkward, I agree with you, and potentially gimmicky, but moving forward the ability to have digital information augment your current view of reality when you want it, that is cool.

Like, "How much is that house right next to me worth? What kind of food do they have inside of this place? What kind of rates are inside this bank?" There are so many different use cases that pop up, it gets interesting.

Yeah?

Audience Member: [inaudible 48:08] take in terms of apps that are running on these mobile platforms, what percentage of them are native code versus mobile? Where do you see that trend going?

Luke: Hopefully it's going more towards the mobile web. A lot of these browser manufacturers are putting in more support.

The thing you don't get with mobile browsers right now is integration into the OS. People will create native apps for two reasons, OS integration or discovery through the app store, because you get that marketing channel.

Right now there's a lot of stuff that you get through building for the native OS that you don't get through the browser. Simple things even, like images, video integration, you can't do that in a browser yet.

I hope that all these vendors continue to push that forward. Ultimately it's not sustainable to try and build an app for 50 different app stores. It's not going to work.

All right. Thanks.

Moderator : Thanks, Luke.