Menu

Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

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

by Adam Churchill
on January 10, 2012

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.

Adam and Josh discussed a few more questions in this podcast. Listen to the remaining
questions at or read the transcript.

Another opportunity to learn from Josh Clark

Josh’s virtual seminar on Designing Tapworthy Mobile Apps (which you can view a recording of)
was so well received, we asked him to do another one. Check out Josh’s virtual seminar, Buttons Are a Hack, The New Rules of Designing for Touch.

Share your thoughts with us

Do you create content that is different for your mobile sites? What about apps? Share
your thoughts with us on the Brainsparks blog.