Mobile Design: Content and the Great Web-based vs. Native Debate

This article is an excerpt from an interview that Adam Churchill had with Josh Clark. You can hear the full interview on their podcast or read their transcript.

Adam Churchill: 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.” In the seminar, Josh gave us a broad introduction to the design principles for designing for mobile, whether that’s for apps or for mobile web.

We had quite a few left over questions we couldn’t tackle due to time. Lets start with a question from Cliff. Should the mobile websites actually feature different content from their big screen counterparts?

Josh Clark: Well, you know, as with a lot of projects, the answer, isn’t totally clear cut. It depends on what you’re working on. Broadly as design practitioners you need to really think about the use cases.

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.

A lot of this comes down to context. When anyone talks about mobile design, there’s always some 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 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 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 for some broad, mobile context, but it’s choosing a selected number 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 think about why people use your app or use your website on a mobile device? What are the scenarios? Then the kind of content that you want to feature might be re-jiggered. That the content on the desktop that’s important might take a lower priority than what’s on mobile.

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. I think the reality 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 simplify, focus and highlight on things that are likely to fit the mobile context. That’s the intent, that we assume in the different mobile scenarios that we identify. And then, craft a design for that.

There may be some cases where you want to have micro-sites that focus on specific content or specific tasks or audiences. But, in general, I think your goal is to have a website that addresses everything that a desktop does.

Adam: OK. Debbie wanted to know your opinion on native iPhone applications versus web applications?

Josh: This is a contentious topic. I think there’s a noisy contingent of people 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. So, of course, building an app for the web gives access to everyone.

And here’s the thing. It’s difficult to build for every platform. A few companies 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, 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 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 lowest common denominator. A web app addresses every platform or, at least, all of the modern operating systems. I would argue at this point you don’t need to build for the crummy web browsers of older feature phones.

So focusing on a relatively modern web kit browsers for mobile, I think is a great way to go, 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 flagship apps that really provide that great native polished experience.