“Thinking mobile” goes beyond scaling down an existing app to fit a smaller screen or making decisions about what content to include. The ability of an app to delight its users is largely dependent on the context in which it is being used. Because the app can be used anywhere by nature and the interface is manipulated with thumbs and fingers, there are much more than just aesthetics to consider. Josh joins Adam Churchill to address remaining questions from his Virtual Seminar.
Adam Churchill: Welcome, everyone to another episode of the Spoolcast. Last month Josh Clark, author of the book "Tapworthy," joined us for a virtual seminar on mobile design. It was called "Mobile Design: Designing Tapworthy Mobile Apps."
Josh has graciously offered to come back and tackle some of the questions we didn't get to address during the seminar. Hey, Josh, welcome back.
Josh Clark: Thanks so much, Adam. It's great to be here again.
Adam: Now, folks that didn't listen to the particular seminar, you can get at it in UIE's User Experience Training Library, which has just about 60 recorded seminars from super knowledgeable experts, just like Josh Clark.
Josh, for those listening that didn't join us for the presentation, can you give them an overview as to what we talked about that day and what we covered?
Josh: Sure. The seminar was really kind of a broad introduction to the design principles for designing for mobile, whether that's for apps or for mobile web.
And, I think that for people who come to mobile design from a desktop point of view, that's desktop software or sort of what we kind of consider to be traditional websites, right, desktop websites, there are a couple of things that tend to trip people up.
And, what I tried to address was one, kind of a big picture thing of how do you conceive a mobile app or a mobile website? And really thinking about, what makes it mobile? What's the context that you needed to really address and nail down to get a great feature set for a mobile app that will really address people's needs when they are in a non-traditional computing environment?
I think, it's actually, sort of one of the questions that we have, we'll follow that up and we can talk about that a bit more.
And then, the second piece is, what does it mean to design for fingers and thumbs? I mean when we were designing for the web, for the desktop, you know we're really designing for a mouse cursor and for keyboard controls, for sort of these prosthetics, in a sense.
And, what that means is that we typically approach desktop design as being sort of a graphic design challenge, but that changes a lot when you're designing something that's meant to be worked by hands and fingers.
And, it really becomes an industrial design challenge, in a way. It's a question of ergonomics. You know, how does your interface feel in the hand? Where is the placement for buttons? How big should these tap targets be? So, it's not a matter of just how your pixels look, but really how they feel. So, the seminar also addressed kind of a lot of the ergonomic issues of how layouts need to work to be comfortable in the hand.
Adam: All right, fantastic. Well, there were a lot of really good questions asked during the seminar. Let's get to some of the questions that were left over and maybe back over some of the key points of the seminar.
Josh: Sounds great.
Adam: So, lots of folks, obviously, are thinking about how mobile tasks are different from desktop tasks and other kinds of online experience.
Cliff asks this question: Should the mobile websites actually feature different content from their big screen counterparts?
Josh: Well, you know, as with a lot of projects, the answer, I'm afraid, isn't totally clear cut. It's kind of, it depends. Sort of, it depends on what you're working on. Broadly, just to sort of back up, it is really true that you have to think about, as always, you know, I think we as design practitioners need to sort of really think about use cases.
You know, how are people going to use the interfaces that we create, whether they're on the desktop or on mobile? Why are people coming to this? Why do they want to use this? And, I think the answer is often different for mobile than it is for desktop.
And, I want to say that a lot of this comes down to context. I mean when anyone talks about mobile design, there's always sort of this discussion of mobile context. And, I think that there's a little bit of a myth to that, that there's somehow some mythical or magical mobile context that you can design for.
Here's the thing, because our designs are mobile, that means they can be used anywhere. Right? So, mobile doesn't just mean on the go, and I think that's sort of the cliche, in a sense, of designing for mobile, is you're designing for somebody who's dashing through an airport, who has very little attention, and only, you know, a few seconds of time. And, that is certainly one use case. And, that does happen very often that we do use these things in environments that are very rushed.
But, we also use them on the couch, or in the kitchen, in sort of slower environments, where we might have a little bit more attention.
All of this is to say that it's really about designing not just sort of for some broad, mobile context, but it's choosing a selected number of kind of non-traditional computing environments and really understanding the mindset that people approach.
Now, what that means is, is that the content that I might care about in one case, might be pretty different than what I care about if I'm sitting at my desk.
So, as you think about, you know, why would people use your app or use your website on a mobile device? What are the scenarios? Then, yeah, often the kind of content that you want to, at least, feature might be re-jiggered. That the content on the desktop that's important might take a lower priority than what's on mobile.
So, here's the thing, though. That doesn't necessarily mean that you drop everything else for mobile. I think that all of us have had that frustrating experience of launching a site on mobile, getting the mobile site, being like, "Man, the one thing that I want to do here is missing from this site." So, we're sort of, you know, scroll around until we finally find the show full desktop version website, right?
So, I think the reality is,is that thematically, at least, you need to have the same content and the same features, or at least some really pretty big proportion of it, that mobile websites should be able to do, pretty much, what desktop websites can do.
But, there's a presentation challenge that we need to sort of simplify presentation, focus and highlight on things that are likely to fit the mobile context, and sort of the intent, that we assume in the different mobile scenarios that we identify. And then, sort of craft a design for that.
There may be some cases where you want to have sort of little micro-sites that focus on specific content or specific tasks or audiences. But, in general, I think the goal should be to have a website that addresses everything that a desktop does.
Adam: OK. Debbie wanted to know, Josh, what's your opinion on native iPhone applications versus web applications?
Josh: So, this is something that gets to be a little contentious. You know, I think there's a noisy contingent of people, I would say, who fall heavily in one camp or the other.
That you have to build a native app because, gosh, that's faster. You can get great performance. It will feel at home on the device. You know, an iPhone app will feel like an iPhone app, and man you can do great effects and transitions, and all that stuff, and it's much faster than building a web app.
There are also other advantages to native apps, incidentally, which are: payment is much easier to deal with through an app store, discoverability at an app store tends to be easier than on the web, where people aren't yet accustomed to building web apps.
The proponents of native apps correctly say that native apps have an edge, a performance and user experience edge over web apps, and that's true.
Of course, one big issue of user experience is whether you can access the app at all, right? I mean, if I don't have an iPhone, and you have only built an iPhone app then I can't look at it on my Android or BlackBerry device, right? So, of course, building an app for the web gives access to everyone.
And here's the thing. You can't build for every platform. You certainly could, a few companies, I would say, have the resources to do it and then even to maintain that sort of full collection of apps across all these different operating systems. And so, in that case, right, the web is actually an easier thing from a business point of view to build for because you can build it once, and it touches everyone.
The thing is that the correct thing to do is actually a combination of web apps and native apps. I don't think that it's either or. I think that you should do both.
I think that there should be a sort of lowest common denominator, in a sense, web app that addresses every platform or, at least, all of the modern operating systems. I would argue at this point you don't need to sort of build for sort of the crummy web browsers of older feature phones. A few of those people who have those even use the web browser in those. It was such a bad experience.
So focusing on sort of relatively modern web kit browsers for mobile, I think is a great way to go for that, and then that touches everybody.
But I also think that you need to identify one or two native platforms that really suit the personality and demographics of your key market, and then reward your best customers by building kind of flagship apps that really provide that great native polished experience.
So that there's really that combination that for some customers, they can really enjoy a full native app experience, and you can hopefully as a business afford to build and maintain one or two of those. And then, at the same time have a mobile web app that talks to everybody.
Josh: Yeah, interesting question. So, for folks who don't know, it is actually possible to essentially build a web app but then sort of bundle it as a native app.
There are platforms like PhoneGap, for example, which is basically like a custom browser where you get the source code for this browser and you essentially sort of put your web app files inside it and then you compile the thing and bundle it up. And then, you can sell it on the app store for iPhone or for Android or for BlackBerry. I believe they're working on Windows Phone 7.
So, there are drawbacks to this, though. I mean on the one hand, it's like, great. You can use the technologies you already know across all these platforms to do it. There's still sort of the problem that in some cases the web technologies just still feel, frankly, sluggish on these platforms compared to native code.
And that's just sort of the nature of the beast, especially if you're building kind of lighter interfaces that don't need to do necessarily tons of fancy graphics work, for example, it could be a good way to go. It's faster. It's easier, and it lets you hit platforms with less trouble. It is going to have slightly less sort of speed and polish, I guess I would say than what you would do if you were building it with proper native code, building your interface with proper native code.
The other aspect that I would say is because you're distributing these web apps as native apps bundled in PhoneGap, for example. What that means is you really need to make them look like native apps. You know? Because if I'm launching an Android app on my home screen it should look like an Android app. And if it looks like an iPhone app or if it looks like another kind of app, then I'm in this sort of unsettled position of like, what's going on here? This doesn't feel like an app.
We have a tolerance for different kinds of interfaces inside a web browser because we're accustomed to that, but apps are supposed to follow the conventions of the operating system. And so what that means is there's a real onus on you as the designer using this technique to use your HTML and CSS to really ape the look of a native app, and that's not necessarily as easy as it sounds.
So it's something that is a great way to kind of get up and running quickly. It's a great way to prototype apps for sure, but there are some downsides in terms of designing them that you know just, no matter what way you cut it, building a native app will always have, at least, a subtle edge in user experience over web apps, whether those are bundled in PhoneGap or online.
Adam: There was a section in your presentation that clearly had our audience thinking, and that had to do with the ergonomics of hand-held design. Can you talk a little bit more about that?
Josh: Yeah. Sure. As I said sort of at the intro here, you know you really are doing kind of an exercise in industrial design, you know, that these devices, all these touch-screen devices, they really are blank before you turn them on, before you fire up an app.
So what that means is that it's really waiting for you to impose an interface on it. And because it's a physical device, something that's meant to be worked with with hands and fingers, your interface becomes physical, too. So you have to think about where do your fingers and thumbs fall sort of naturally?
And it also means kind of following industrial design precepts. So one thing that that means is that it actually turns a lot of our preconceptions about what design should be for the web or for software in general, literally upside down. We're used to having primary controls and navigation at the top of the screen, right, where it's sort of most visually prominent.
It turns out in mobile that the best place to put it ergonomically is at the bottom. If you're holding the phone in one hand, as we typically are, that means that you're basically using just your thumb to tap through this. And sort of the comfortable area for the thumb is on the opposite side of the screen and at the bottom. So if you're holding it in your right hand that means that the most comfortable area to tap is sort of the left side and left corner of the screen, which means that that's a great place to put primary controls, at the bottom of the screen.
And this, like I said, follows sort of a basic principle of industrial design, is that you always want to put controls at the bottom and display at the top, for the simple reason that you don't want your fingers covering the content.
It really means that the primary area for controls and sort of the main buttons are at the bottom of the screen instead of at the top. And that's I think, one of the big things, one of the big takeaways, is that, while it's common sense, it doesn't necessarily hit people while they're working on their designs, usually in a desktop setting.
Adam: So, with the popularity of the Android devices, Don wants to know, how does the difference in the sizes of their offerings effects the optimal function?
Josh: Yeah, well, basically it's these phones started at a size of around three and a half inch screens, right? And then they have gone to four inch, and even sort of five inch. So, you've got these jumbo, phones, right? Which are certainly appealing for their display.
One of the problems with them, and I certainly have this, I've even got large hands, but I actually have to sort of shift the phone around in my hand to do sort of the full sweep with my thumb. You know? So, if I'm holding it with one hand, I actually can't do the full thumb sweep on it. There's an awkwardness to this phone size that makes designing interfaces for them slightly challenging.
Still, that basic rule for handheld devices is that you want to put the controls down toward the bottom. And, in fact, talking of Android, it's interesting, they have hardware buttons at the bottom, which is the proper place to put controls, as I was saying, from an industrial design. But they have these physical buttons at the bottom, which complicates things a little bit when you're designing for Android, because you don't want to stack too many virtual controls, that is, screen-based, touchscreen controls, sort of too high on top of those buttons.
So, there's a little bit of a challenge here, based on the Android's physical design, of sort of trying to finesse keeping controls at the bottom, but not sort of loading it too much so that you get mistaps in that area, where you're going for a hardware control but you get a touchscreen control. So there's a real challenge there, I think, with Android.
My personal take, and this is just a personal opinion, is that I suspect that this kind of jumbo phone size won't necessarily last. You know, I think that it's something that is not sort of ergonomically comfortable, it's an awkward size for a phone, and I suspect that the phone size will retreat back to more of their earlier version, sort of the size that iPhone is. While we sort of have kind of a medium-size tablet, like a seven inch tablet, and then a jumbo-size tablet, which is more iPad size or Zoom size.
The reason I say that is just that if you look at our history with paper, with notepads or with books, those things have, for pretty good reasons over centuries, tended to consolidate into three sizes: Very sort of small pocket size, sort of a paperback size, and then sort of a larger hardcover. And of course, we may still see, keeping this book metaphor, sort of a larger, coffee table size for a large tablet. But it seems to me that we'll see that consolidation of tablet size and phone size hit that as well.
Adam: So, Josh, along those lines, when you were talking about the ergonomics of handheld design, there were a bunch of people asking in the Q and A section of our Adobe room, "What about lefties? What do I need to do for lefties?" Is there something valuable that you can offer up that the designers can think about? Or is it, do they just need to stick to that thinking of keeping those controls towards the bottom?
Josh: Right. Well, so, a couple of things. One is, we're pretty fluid with these devices in terms of which hand we use. You know so, right-handed folks sometimes use their left hand, left-handed folks sometimes use their right hand, or even prefer that.
So, there aren't necessarily hard and fast rules the way there is for, say, writing, where right-handed people always use their right hand, with the phone. In fact, when we are writing, when you're right-handed, you have to hold the phone in your left hand and work it.
So, one thing just to say is that, you know, we can all tend to use these phones with either hand, so I don't want to emphasize too much that you must optimize for right hand. That said, a majority of people do tend to use the phone in their right hand the majority of time. So, sort of doing a gentle optimization for those folks helps.
But yeah, what does that mean for lefties? If you're optimizing for right-handed use, that, by definition means that you're putting the lefties, kind of out of luck. And some apps, a handful of them, Twitteriffic used to do this, for example, on iPhone, actually had a setting to reverse the buttons for left-handed users so that the navigation, the toolbars, everything flipped to the other side.
And that's something that you might consider for very tap-intensive apps. There's an app called, "PCalc," for example, which is a scientific calculator, lots of buttons. And it has a right-handed and left-handed mode for its landscape view. So, that if you're using both thumbs you can actually put the keypad on the side that you favor.
So, these are sort of subtle considerations. I guess I would sort of say though that thinking about these things, about, "Is it most comfortable for the right hand, for the left hand?" And optimizing for that one-handed use, on one hand of the other, these are the things that your users will not necessarily consciously recognize, but they're the kinds of things that make the difference between a good app and really a sublime app. You know?
The best way to go about it, though, is to try to create designs that are kind of neutral to hand. That is, you know, buttons that go that go across the entire width of the screen. And you'll see that for fairly important buttons in all of the platforms.
So, just to use iPhone as an example, the action sheets that slide up from the bottom of the screen provide a set of options. For example, if you're deleting a post, it'll ask you to confirm that by sliding up this little sheet from the bottom of the screen. And those buttons go across the whole width, so there's no right or left issue there.
So, in general, try to be neutral to which hand it will be. But if you're picking one side or the other, yeah you know, it's generally best to optimize for the right-hand use.
Adam: So, offering up all this wonderful insight for making mobile devices tap-worthy, we're not talking about just phones, are we? There's a lot of people that took it to the next step and were thinking about iPads and tablet design.
So, Dan wanted to know, how is designing for a small device like an iPhone different than designing for its larger counterpart, the iPad?
Josh: Yeah, it's a great question. And it's easy to sort of assume that the rules will be the same, especially when you're talking about going from iPhone to iPad. They run the same operating system, right? And, as you know, tons of people said when the thing was first announced, "Well, big deal about the iPad. Who cares? It's a big iPhone, basically. No big deal."
Well, like I like to say, it's, an iPad is like an iPhone like a swimming pool is like a bathtub. You know? They sort of have the same characteristics, but their form and their context encourage entirely different uses. And you see that even in terms of the mindset that people bring to these.
So, for example, with an iPad, you pretty much have to use it with two hands, trying to use it with one hand, that's sort of a different thing. What that means, when you've got somebody with two hands, and you see this even when people go into landscape in mobile, you have their attention, because you've got both of their hands.
It sort of draws you into the interface more. So you've already got sort of a more attentive mindset. Also, with the tablet, they're hard to use when you're standing up. They sort of encourage a seated posture.
What this all tends to add up to is that for tablets there tends to be a more leisurely and contemplative mindset, with longer sessions and more attention. So that also means that your designs should likewise reflect in general that sort of calmer, more leisurely mindset. Unless you're building a game, for example, where, you know, the more adrenaline the better.
So what that means in terms of aesthetics, is not to, like, crowd and pack as much content as possible into that screen, which is what you see a lot of people do. It's an enthusiasm, right? "Oh my God, I'm coming from iPhone and now I've got all this space. I'm just going to, like, use it up."
Or, people who are coming from the desktop are like, "Well, close enough. I think we can kind of cram our desktop interface into the tablet screen." You know, actually it's better to sort of think just more leisurely. Add that white space, make these designs calmer. It's OK to put some information another tap away.
I should mention it, just because I think it's worth saying, the web has made us a little bit squeamish about extra clicks, or in this case extra taps. And that's because of network latency, right? And then on the web every click involves a wait, and so they're annoying and you want to reduce that. With taps, the content is generally pretty much there, there's not that issue of latency.
So if you're dealing with that kind of situation where you have cached content that's available right away and there's no delay, I believe that having a few extra taps is OK, that it's better to have a screen where there's clarity, where you have less content but more focused content, and put additional content just a tap away. In mobile interfaces, whether it's for tablet or for phone, clarity always trumps density.
And I believe that tap quantity, for that reason, is much less important than tap quality. How effortless is it to use the screen in front of you? So as long as every tap delivers that quality, that there's a task completed or information delivered, or even something fun and delightful happens, that it's OK to have extra taps.
So I sort of went down a little bit of a rabbit hole there talking about the aesthetic of design for the iPad, but the ergonomics are different, too. You don't hold it from the bottom the way that, when you're holding a phone your thumb is sort of positioned usually at the bottom corner, at the base of the phone.
With the iPad, typically you're holding it toward the top, and usually with two hands so that your thumbs are positioned generally toward the top corners. And so the top left and right corners, in both portrait or landscape, are areas to target, rather than the bottom.
So we're sort of back, essentially, to our familiar desktop placement for a tablet, because the screen size is larger. The screen is large enough so that you might miss things that you see at the bottom of the screen.
Or even if you're holding it on your belly, for me, the tablet sinks a little bit further into my belly than I might like. And then it actually makes it harder to hit buttons at the bottom of the screen. If I'm in my Barcalounger with my bag of cheese puffs, that's not an easy ergonomic position.
So always sort of the top left and right corners are great places for controls. Avoid the top middle, because, as we were saying before, that means that your whole hand, or even your whole arm, is now covering the content. If you cluster controls sort of toward the top left and right corners, either along the top or along the sides, then you keep things out of the way, but also ergonomically within reach.
Adam: Mobile devices, people on the go doing lots of things, trying to do them quickly. Chauncey wants to know what impact loading performance has on an app user experience?
Josh: Yeah. Performance is super important for any app, whether it's mobile or not. I mean, Google has done these studies where even like a few microseconds of delay shows a marked decrease in use. People will drop off, even if they detect a few microseconds of change. In a search, for example, they will search less.
So there's already sort of this thing of, if it's not peppy, even in things that, God, how could you consciously even recognize this sort of handful of microseconds, you still see it somehow, and move along. So performance, super important in all contexts. But especially, as you say, in mobile.
And it's really important. Basically, I sort of think of mobile apps like take-out food. You know, if it's not fast, you're breaking a promise. So performance has to be great.
And, unfortunately, we see this in some native apps that they actually feel slower. They may not actually be slower, but they feel slower because of the way that they manage the processing, than their sort of web app counterparts. If you use the New York Times iPad app, for example, it's going to take a few seconds for that home page to kind of load up and get everything. So it's getting all the content at once.
So there's sort of this sense of delay that you don't have, actually, when you go to the website. There's more of a delay when you go to each page, right? But it's sort of distributed across the experience, rather than this big lump that you see when you're first launching the app. And you see this with The Daily, which is the big News Corp iPad app. It takes like 30 seconds to load that newspaper.
If you're building a native app, one of your great advantages is speed and performance. And if you've built your app in such a way that it feels slower than your web app, well, A, something's probably awesomely right with your web app, that's great. But it also means that something's not right with your native app. It's got to feel fast, it's got to feel peppy.
Adam: All right, Josh, that's great. Thanks for circling back with us and tackling those questions that were left over.
Josh: Loved it.
Adam: To our audience, you're going to want to catch more of Josh's insight, and you can see him and hear more of those insights on our Web App Masters Tour later this spring in both Seattle and Minneapolis.
Again, to our audience, thank you for your support of the Virtual Seminar program and for listening today.