Jared Spool: Hello everyone. Welcome to another episode of The SpoolCast. I am Jared Spool, and I have with me here Josh Clark, who is calling in all the way from beautiful France to talk to us about mobile apps.
Josh, as you probably know, is the author of "Tapworthy," a fabulous book on designing for mobile, and one of the best resources out there.
And we're very excited that he'll be speaking at the Web App Masters Tour this spring as we bring it throughout the U.S., and he's also going to be doing a virtual seminar for the UIE Virtual Seminar Series. Josh, welcome!
Josh Clark: Oh, thanks! I'm really delighted to be part of this. Thanks so much, Jared.
Jared: Yes, you'll have to bring something French when you come over for the Web App Masters Tour.
Josh: I'm going to bring some strikes back with me.
Jared: Yes, or a dancing girl or something.
Josh: [laughs] OK. That sounds more fun.
Jared: Yes! Every time I think of France I think of Moulin Rouge. The whole city is like that, right?
Josh: No, exactly. That's exactly right.
Jared: Yes, it's guys running around in bustiers.
Josh: [laughs] How did you know? I thought that was... Is that the first question, "Josh, what are you wearing?" "I'm wearing my bustier."
Jared: That's it, that's it. A city of people who look like Toulouse-Lautrec. But enough about this frivolity. Let's talk about mobile, which is not something that I get to talk about very often. I'm still stuck in the world of desktops, but mobile is up-and-coming.
And you wrote a book. You wrote really one of the first books that tackled this subject in any meaningful way from a designer's standpoint. How did you get into this space? Where were you coming from?
Josh: Like a lot of us, web design. For the last 15 years the web was where all the exciting innovation was happening in software design and development, and those were all the new possibilities of the web.
And as that matured into the 2000s, I was casting about looking for new challenges when an iPhone landed in my pocket.
And while cell phones and mobile has certainly been around for quite a while including the mobile web, it was really when the iPhone came along with this very easy interface.
And this very personal nature of computing, this computer that knew so much about you, about your surroundings, about where you were that it really struck me that this was a really important step towards ubiquitous computing and a really very personal nature of computing.
It's funny, right? We've been talking about personal computers since the days of disco. In a very real sense, this new generation of smartphone - whether it's Android or iPhone or Blackberry, what have you - is really sort of the most personal, the very first personal, truly personal computer that we've really run across.
Not just because it's always with you, not just because it's sort of this computer that is always on and it's always available to you, but like I said, because it knows so much about you. It's packed with sensors.
It knows about what's around you and can integrate that into very compelling ways to give context to the tools and information that you have at hand.
I fell in love with the iPhone and now I'm an equal opportunity mobile phone lover. Sitting on my desk are an Android phone, an iPhone, a Blackberry. All these devices are opening whole new possibilities for us as users and certainly as designers.
Jared: I think that the book does a fabulous job of really describing what the challenges are. How did you get your head around all that?
Josh: As you said, there weren't and really still aren't very many design books for this sort of new generation of mobile and for designing for apps and for touch. There are a lot of development code books and of marketing books at how to hit it big in the app store, the android market.
And for me, I thought it was really important to step back and say, rather than talk about so much of the "how" - how do you code or sell an app - to really look at sort of "why."
In this case, the book is specifically focused on iPhone apps, and it's really looking at how to think iPhone. What makes an app mobile? What makes an app delightful?
What creates a great mobile experience, and what do you have to think about differently when you're designing for a handheld device that works by touch? What do you have to think differently from what you would if you were designing for the desktop?
So again, it's really a book that is about design and user experience and how to think iPhone.
What's been interesting, and I think very flattering in a way, is that I've had a lot of Android developers and developers for other platforms, designers say that they found it really useful for their own work.
So while the iPhone platform gives a focus, a lens to discuss all these issues of mobile and touch screen design, that it has a lot of broad lessons for mobile generally and not just iPhone.
Jared: Is it the case that those sort of general principles are pretty much going to stay the same for a while, or are things in the mobile space changing?
For instance, when the iPad came out, did that put a lot of things on its head, or did you find that it was really just a scaled-up version with the same underlying principles behind it?
Josh: Both, in a sense. The same way - I forget who said it, it's a great line - the iPad is like a big iPhone in the same way that a swimming pool is like a big bathtub. Yes, they work the same. It's got the same principles, but the form creates an entirely different context and set of opportunities.
Jared: It does, because doing laps in the bathtub...
Josh: Take it from me, that's actually where I'm most successful in my laps though, I'd have to say. I find myself getting stranded a lot less.
Jared: The back float is what I'm good at in the bathtub.
Josh: I'm pretty good at the stationary sit in both the pool and the tub. And now I'm talking about both my bathing and my bustier wearing.
Jared: [laughs] Yes, that's true.
Josh: So I'm sure everyone knows more than they'd like to know about me by now.
Jared: So anyways, I interrupted you. So, the iPhone and the iPad are like a bathtub and a swimming pool.
Josh: Yes. While the iPad obviously runs the same operating system as the phone, they both have such different forms that lend themselves again to very different contexts and even to different mindsets.
So in the same way that the phone demands a very different interface than the desktop, this middle ground area of tablet really does as well.
So one way that I think about it is that you have your mobile phone when you're on the way to the coffee shop, but it's your iPad that you use at the coffee shop.
The iPad is a device of calm and contemplation, that it's something that I've observed a lot of people, if they've got an iPad on their desk, they'll literally pick it up and go and sit in a more comfortable chair.
It's something for a calmer state of mind for longer sessions than the iPhone.
And of course with the form factor too, it means that your hands and fingers rest in different areas. You have to use more of your arm than just a flick of the finger as you would with the phone.
So in fact when you're designing for touch, this is one of the biggest things that I think is new for designers when they approach a touch screen platform, is that you really have to think about the physicality of the device.
That to press a button on the iPad isn't just a flick of the wrist like it would be to move the mouse on a desktop. You have to haul your arm over.
So there are honest to God issues of ergonomics to consider when you're designing for touch devices. It's entirely new to designers who are accustomed to the desktop.
So what you find a lot, I think, is that it's not just a challenge of graphic design, which we as software designers on the desktop are often largely accustomed to. It's really a challenge of industrial design because these devices are just blank slates with no interface to speak of until you impose one on it.
And because your interface defines the physicality of this device because it's going to be worked by hands and fingers, then it means that you have to have all these ergonomic considerations of button placement. Where's it going to be easiest for your hands to get at quickly?
Is it large enough? Are the things spaced out enough for fingers? It's really like designing a physical handheld device in a lot of ways.
Jared: And that's something that a lot of web designers haven't had a chance to see and haven't had a chance to experience. And I also think that in an ironic way, Apple may have done a disservice with the iPhone. And maybe Google with the Android is the same way, or maybe it's actually a little better.
And this is the wacky thing in that because the apps that come with the device are actually for the most part pretty well-designed, it's hard to really understand what went into the thinking behind them.
It's one of these things where good design when it's done well sort of becomes invisible and things just work the way the user expects. And all of a sudden as a designer, you don't know what you're emulating. You don't know the thoughts that went behind it.
The size of the target regions, for example, for the places that you touch. It's easy to do them wrong and not realize it.
Josh: Yeah, no that's right. In one sense I think that Apple was fortunate, as frustrating as I think it was for a lot of developers and a lot of users. That they had to wait a whole year before third party apps came out on the iPhone. I think that was frustrating thing.
But on the other hand, there was a whole year where you could only use Apple Apps. And so there was a sort of real sense of this is how the iPhone works. With these, whatever it was, eight or so, out of the box Apple apps that came installed on the thing.
That there was a boot camp, in a sense, of how things should look and work. And in a way that you've seen on Android, where it's all over the place, there wasn't that sort of period of getting adjusted.
And, of course, Apple being Apple, is also very controlling, in a sense of having a very specific set of human interface guidelines that are very clear about certain situations. They say, touch targets should be a minimum of 44 points. That's what they ought to be, which is a pretty chunky.
But one of the things that's also very interesting, when you look at the size and proportions of how Apple created the standard controls and interface elements, that you can use and just sort of get for free when you're developing for the iPhone.
All those things are this measure of 44 points, comes up over and over again. It's the exact height of a standard row in a list. It's the height of the tool bar. It's the height of the navigation bar at the top.
And so, really, how cool is that? They said the size of your fingertip is 44 points. So not only did they say that's how big buttons should be. They said we're going to use that as the measure, almost like the golden mean of the IOS interface.
So that everything is not only in proportion to other elements, again this 44 shows up over and over again. But also in precise proportion to your fingertip. So it's not only for the hand but of the hand.
And it's just something that I think shows a lot of the subtle thinking that really went into IOS. And I think is also because that was the first of this new sort of era of smart phone. I think the other platforms have really benefited from that real thoughtfulness that went into this sort of first of the generation.
Jared: It seems to me that from a developer's perspective, there really is a whole new world to consider. And the book does a really good job of laying that out from an iPhone perspective.
But lots of things are coming on the plate. We've got Android tablets now that are seven inches, not 11. So you've got different size form factors.
You've got new products coming out from RIM, the makers of Blackberry, that are supposed to change the game for both the Blackberry community and for people who want to get into that.
Even things like the way that net books are working, touch screens are becoming more prevalent. And Microsoft introduced a new version of the surface recently at the consumer electronics show that has a lot of interesting things on a wall size display.
How does a designer even begin to keep up and really get their head around what their choices are and what their decisions should be and all the different things that are supposed to really drive great design?
Josh: I think it's a great question and a real challenge. And I should say also, just before getting into how I think we can approach it, it's going to get worse.
Like at the moment it seems like, wow. There's a lot of fragmentation here, of different types of screens, different platforms.
In Android alone there are over 100 Android devices shipping or shipping soon, with different screen sizes, as you say, and different even themes, different apps that are included by different carriers. It sort of seems overwhelming.
But then, I think this is just at the start of an explosion of seeing screens everywhere. On our refrigerators, cereal boxes. As the prices get down, we're just going to find screens all over the place, with the expectation that our content will flow seamlessly from one to another.
And you're seeing that already for people who use the Kindle. Your book opens to the same page that you were reading before, whether you're on your phone or your tablet or your desktop.
Similar for Netflix, pause a movie, start it up again someplace else. There's a sense that we'll have screens everywhere that will flow to different devices. And we're going to be expecting those devices to operate appropriate to the form and context that we're using them in.
So it means getting used to, as you say, all these different form factors and all these different platforms. And it's going to get much wilder, I think, before it calms down.
One additional challenge to this is, particularly when looking at phones, if I want to develop an app for iPhone, I'm also interested in doing it for Android and Blackberry. It's a difficult thing to do, unless you have fluency with the device and the platform.
Looking at it as web designers, sure we had to do this for designing for IE versus Safari versus IE for Mac back in the day and so on.
But we had access to those platforms fairly easily. And we expected the web to operate the same on all those platforms. It wasn't like, oh, on IE it has to follow these IE controls and standards versus Safari.
But an IOS app has to look like the iPhone. An Android app should look like an Android and Windows phone seven and so on.
And the thing is, how do we get that kind of fluency in all these different platforms? I think it's a big challenge, not least because it means you have to have a different subscription for a lot of these things.
How can I, as an independent designer, afford to have eight different phone lines and eight different smart phones? There's a real challenge of how do I get the degree of fluency in all these platforms, to be able to design for all of them.
I think that it will probably be that we'll have to specialize. And whether that means that I'm, an IOS designer. Or I am an Android designer.
And, of course, this is where, well wait a second. Isn't this the problem that the web is supposed to solve? That the web itself was created as a single interface for every device. Build a web page and it will work wherever.
And that is true to a certain degree for the mobile web. But there are subtle things to consider though for differences. The Android users, for example, aren't accustomed to having a software back button. They've got this sort of physical button.
And yet, for people who are accustomed to using an iPhone app, if you want to build a web app that feels sort of native. You would need to include the back button on the top left on the screen itself, a software button. Even within platforms, different subtle conventions that you have to take into play.
But more important, it's the form. That I'm going to use a mobile phone differently then I'm going to use a seven inch tablet, differently then I'm going to use a 10 inch tablet, differently then this screen that I just made up on my cereal box or my refrigerator or a surface.
And so, I think that the idea of build it once, run everywhere, is as always something that's going to be a pipe dream. It's not going to be possible to be platform agnostic or device agnostic.
Jared: And I'm wondering as you're talking. I'm listening to this and what's going through my head is, that's just the tip of the iceberg.
Because you still have the decision of, do I do something which is a browser based experience on all these different platforms. Or do I invest in something that's native.
And of course, I guess it was the folks behind Tweet deck published that they're supporting more than 100 different versions of the Android operating system.
And so, native has these costs associated but they have these benefits, right. Because you get the sensors, you get to have a synchronicity that you can't easily do in an app. At the web app masters tour, you're going to be talking about this sort of struggle between deciding one versus the other. And it feels to me like that's a really big piece of the puzzle.
Josh: Yeah. As you said, if you were going to go whole hog and develop even just for one platform for Android and support everything and Google too, has over 100 build of their maps app. And they're struggling to maintain that code base.
And if Google is having a hard time doing it, how are poor Jared and Josh possibly going to keep up with that pace.
So yeah, I think that the web is definitely going to be, as always, the baseline. Everybody needs to have a great mobile website web app that can cover all of the platforms.
But I also think that it makes sense to reward, if you will, your flagship customers with an app. There are pretty clear demographics that break out across all the platforms that you can really identify who your audience is.
It sort of goes back to an old marketing question. Is there enough of an audience here to give them the improved native experience? I don't want to diminish what the web can do. It's amazing.
You mention sensors and more and more, web kit, which is the browser engine that runs on most of these devices, is increasingly incorporating access to sensors that you can get all that good stuff.
And while the animations are a little bit slower or the high test kind of graphics aren't quite as good as if you're doing native stuff. It's amazing what you can do. Every day there's new magic being minted, in terms of web apps, and what you can do with touch on them.
But it's still not quite as good. The gap is closing steadily, and it will continue to close as processor speed improves on these devices. But it's still not going to be as good as the full on native experience.
Testing native apps is a difficult thing, whereas it's very easy to provide access to a web app. There are real advantages there.
In a sense, it's an implementation question. I mean, I think that this, like so many things, in a complex environment, it's tempting to oversimplify it, and to be like, "Oh, the web is better, I choose the web." Or, "Native is better, I choose native."
And you see this familiar religious war brewing between the two. Oh, it will never be as, "Web will never be as good as native." And, "Native will never be as open as web."
And the truth is, that as far as the user is concerned, it's an implementation detail that they don't care about. And so the question is, well, what's going to be better for your user?
And, a lot of times, I think that a lot of companies are finding that, as far as the users concerned, it's a better experience when you can do it, to do a native app, with astonishing results.
I mean, eBay, which I guess, accounts for about 50% of mobile ecommerce, 70% of that is done through their iPhone app. Which is pretty astonishing.
Yelp, similarly, I think about a third of Yelp searches come from their iPhone app, even though that's about 4% of their users. So it's, when you provide that native app experience, you do see results that can be worth the investment.
But I think one option that's really important to know that's out there is that you can kind of have it both ways with so-called Hybrid Apps.That is you basically build a web app and bundle it inside a native app usin a framework like Phonebook app for example. Which is basically a custom browser, really, that you just pour your web app into there, and it talks to the network, and fetches information.
What it requires, though, is a real embrace of HTML5 for offline access, database access. And all the goodies that HTML5 and CSS3 provide. It really lets you build a rich, nearly native experience, and it's worth saying.
I know that you've been educating people about all the possibilities of HTML5. And it's worth saying that we as a community are sometimes slow to adopt new web technologies because of the drain of slower browsers, [cough] IE, to adopt this stuff.
The thing that's exciting now is because most of the smart phone platforms, with the exception of Windows Phone 7, are running WebKit.
HTML5 is already mature for mobile. It's ready, it's go use it; go learn how to use it, because you can make awesome mobile apps with the technologies that are on all of this new generation of smart phones.
Jared: And I heard that Windows 7 is, in its next release, is bringing back IE 5.5, just for that retro feel.
Josh: That's right, I mean, I believe it's basically running a spruced up version of IE 7, of that engine under the hood. So, it's not as robust as the other WebKit based browsers.
Jared: Well, I'm glad. We won't make it too easy for designers.
Josh: [laughter] That's right. I mean, the good news, though, is that, as web designers, we're not accustomed to this level of consistency, on a platform.
While it's incredibly daunting for native app designers and developers, where it's just like, wow, now I've got to support all these different code bases and all these different languages for each platform.
For the web, it's actually astonishingly consistent and how awesome is that? You know, it's wow; everyone is running, essentially, one version or another of the same browser.
Jared: That's just brilliant. You know, this whole idea that we might ever get past the browser wars. [laughter]
And, I know that you can get Opera on a variety of phones, and are they WebKit supported?
Josh: Jeez, Jared, I'm not sure. I don't think so.
Jared: I don't think so either. So that adds to it, too. I think it's a neat problem space that we're in, this whole new sort of thinking about where do we want to go, and do we want to go that easy route and get it up and running with the browser and then move it over.
I've seen a strategy folks have used where they actually create a browser version first, figure out that the limitations are, and then they have a better idea of what that native app needs to be.
Josh: Yeah. I mean, HTML, as always, really great for rapid prototyping interfaces, with CSS, and you can really get it out there, as well as more traditional mock-up tools, whether it's Photoshop or OmniGraffle or what have you.
Or one of my favorites for doing iPad, actually, is using Keynote, that I highly recommend.
There are these templates at Keynotopia.com, where you can get, for Keynote, basically stencils of all of the iPad and iPhone controls, if you're building an iPhone app, which then you, since you can show Keynote slides on your iPad, can actually sort of get a sense of how it feels.
It's so important, when you're designing a touch device, to get onto the device as quickly as possible, to get a sense of not just how your pixels look but how your pixels feel in the hand.
Jared: Yeah. And there are so many cool things you can do. Steve Smith, over at Sidebar and Ordered List, has come out with an app that runs under HTML5, and it's a slide-presentation tool, like SlideShare, except that one of the advantages is that you can synchronize all of the people viewing at the same time.
So if you're giving a presentation up in the front of a room, the audience can actually be synchronized, so they can follow along on their iPad or their iPhone, and as you advance your slides, their slides automatically advance.
Josh: It's amazing, right? I mean, it's this idea of, again, content flowing streamlessly from device to device, even from the presenter to the audience. We're in a pretty amazing period.
Jared: It really is. I'm very excited to see what's going to come of it. And I'm really excited that you're helping us get there. You'll be doing a virtual seminar for us in March. We have you slated to come onto the program March 17th.
Josh: St. Patty's Day, I should say.
Jared: St. Patty's Day. That's right.
Josh: Green beer will be served at the virtual seminar.
Jared: In Boston it's known as Evacuation Day.
Jared: The county that Boston is in, Suffolk County, it's a government holiday. All the banks are closed, all the government offices are closed.
It turns out, for years, because I worked in Boston proper, I couldn't figure out who would evacuate on St. Patrick's Day? Because if you know anything about Bostonians, they don't go nowhere on St. Patrick's Day, except to the pub.
And it turned out that it wasn't Bostonians evacuated; it was the British who had evacuated. For all of our UK listeners, there was a war that you guys fought against us, and you may not remember it, but it's big to us.
And so the British evacuated Boston on the 17th, and they've turned that into a holiday, coincidentally, as St. Patrick's Day. [laughs]
Josh: Right, exactly. What are the odds?
Jared: What are the odds? [laughs]
Josh: Way to go, Massachusetts.
Jared: I can understand why the Brits would leave, because who would want to be trying to fight a bunch of drunk Bostonians? That would be hell.
Anyways, back on topic. On March 17th, St. Patrick's Day - and here in Boston, Evacuation Day - you're going to be talking on our virtual seminar, so people can watch you online.
And in that, it looks like you'll be helping us understand how to get started thinking about this mobile design stuff. And then, starting just a week afterwards, you join us on our tour of Philadelphia and Seattle and Minneapolis.
We're coming to Philadelphia in March and Seattle in May and Minneapolis in June, and there may be another city or two that we add after that.
But that's our Web App Masters Tour, and there you're going to be talking about how to decide between going native and the issues there and going web, for mobile applications. This is all very exciting.
Josh: It is exciting. I can't wait for our road trip, Jared.
Jared: Yes, it's going to be great. I will not be able to get enough Josh. That's why we did it this way.
Josh: I'll bring the Doritos.
Jared: Excellent. Excellent. I'll bring the Bustiers.
Jared: So, this has been a lot of fun.
Josh: It really has. Thanks so much for having me be part of this. I love talking about this stuff, and it's great to talk it over with you, especially.
Jared: Great. I really enjoy it. And I'm looking forward to your virtual seminar. I'm looking forward hearing you on the Web App Masters Tour. People can find out all about that stuff at uie.com; there's a virtual-seminar link. Uietours.com is how to figure out about the Web App Masters Tour.
I want to thank our audience for sitting and listening to Josh as he enlightened us about all these mobile things that I know I hadn't considered and I'm sure were new to you. Of course, as always, I want to thank you all for encouraging our behavior. Until next time, take care.