
New Startup? Think Twice About Mobile First - jamiequint
http://jamiequint.com/why-i-believe-in-mobile-second
======
LanceJones
Actually, I believe the term "Mobile First" was coined by Luke Wroblewski, and
Luke's post below pre-dates Fred's by nearly a year:

<http://www.lukew.com/ff/entry.asp?933>

One of Luke's key tenets on Mobile First is about how smaller screen sizes
force you to focus your messages -- and lack of focus is a huge issue for most
Web sites.

Fred seems to be coming at it from a slightly different angle, but I think
it's important to include Luke's ideas here in the discussion... it's how
designers and UI experts think about the term "Mobile First".

~~~
SkyMarshal
Yes, and the OP is also using the term "Mobile First" differently than my own
sense of it.

To me, Mobile First means developing websites targeted at smartphone screens
first, that scale gracefully upward to desktop size. The 320andup boilerplate
is a good example [1].

I see it also means a more general business strategy of focusing on your
mobile app first, be it native or HTML5, and then your website. But could be
some mixed messaging due to the multiple meanings of that term.

1\. <http://stuffandnonsense.co.uk/projects/320andup/>

------
rwhitman
From a UX perspective I think you're at an innovation disadvantage if you
launch today without a touch-focused UI. Its a somewhat trivial leap to go
from mobile UX to desktop, but much harder the other way around.

Desktop focused products have been making slow and really clumsy forays into
mobile but I've yet to see a mobile product translate poorly onto desktop...

~~~
msrpotus
The ideal solution is a site or app that works well on both, like how Apple's
site works no matter what type of screen you use.

~~~
bigiain
This is how we view the "mobile first" movement - not in terms of first
developing a mobile version and then working out later how to turn it into a
desktop site, but instead using the laser-like focus that "mobile" requires to
properly identify and prioritize your goals.

It's much more about getting your design requirements listed in order of
importance - if you spend the time thinking about questions like "if I have to
fit this product/site/app onto a 4inch diagonal screen, what are the
absolutely most important bits to show first?", you'll have a much easier time
designing upwards to the tablet/netbook/laptop/desktop sized versions.
Shrinking down to a 4" screen from the 1600pixel wide monstrosity that every
single stakeholder has insisted has _their_ "critical" piece included is _way_
more work.

I've often used the "mobile first" approach to gently encourage clients to
prioritize goals properly "I know we're not considering a mobile version of
this site at this stage, but there's a _lot_ of conflicting requirements for
your homepage here. If we were in the future to develop a mobile version,
which of these things would we cut and which would we keep if we only had a
phone screen to display everything on?" is an approach thats worked well for
me…

------
physcab
I agree with the author, but not for the same reason they mentioned.
Currently, the biggest problem in mobile is discovery. If you're not in the
top 25 for your category, its difficult to gain enough organic traffic to
build a sustainable business on. Companies much larger than you are buying out
all the paid inventory. As a startup, you'll be doubly hurt because no one
will know who you are. So you have all the problems of sustaining as a brand
on the web plus the added disadvantage of surviving on a platform where
discovery is inherently broken.

So unless you think long and hard about how to solve distribution and come up
with some interesting hacks, you're at a large disadvantage from day 0.

~~~
stewie2
how do people discover a new website then?

~~~
physcab
Many different ways. For organic traffic theres links, search results,
facebook posts and other social media. For the app store theres added friction
bc users have to install the app on their phone and there will be a dropoff
between viewing a listing and downloading (and also from downloading to
launching). For paid traffic, its much easier to build a sustainable business
on the web because the costs are, for the most part, cheaper.

------
cageface
_internet usage is moving rapidly off the desktop and onto mobile devices_

I don't think the current usage stats support this claim at all:

[http://gs.statcounter.com/#mobile_vs_desktop-ww-
monthly-2011...](http://gs.statcounter.com/#mobile_vs_desktop-ww-
monthly-201105-201205)

Mobile is definitely important but the truth is nobody knows if the
equilibrium point is 20% of the market or 90%.

~~~
jamiequint
I think a key indicator of the equilibrium point is the market share of mobile
to desktop in emerging markets. I think we're going to see usage patterns in
the US trend to those over time. For example, check out this graph from the
KPCB 2012 internet trends report on internet usage in India:
[https://dl.dropbox.com/u/120/Screenshots/emerging_market_int...](https://dl.dropbox.com/u/120/Screenshots/emerging_market_internet_usage.png)

~~~
cageface
The evidence in the US and UK seems to suggest that people that can afford
desktops or laptops aren't so eager to abandon them. It seems just as likely
to me that people in developing economies will upgrade to real machines given
the chance.

~~~
reddit_clone
It is actually different for economies like India. Majority of the population
never had computers or internet. But everyone is starting to have a mobile
phone.

They are doing an Ice -> Vapour thing skipping a step.

------
markerdmann
Jamie, what experience or research backs your claim that mobile development is
an order of magnitude slower than web development?

I've been coding iOS apps for the past 6 months now (after coding web apps for
years before that). If anything, I think iOS development is easier and faster
than web development.

~~~
emmett
In every company I know where there is a capable web programmer and a capable
iOS programmer adding the same features to their apps (supported by a shared
backend), the web programmer is an order of magnitude faster. There's no peer
reviewed studies on this subject but my anecdotal evidence (from advising
dozens of startups through YC) is all on one side.

~~~
markerdmann
An order of magnitude? Do you really mean that you've seen iOS programmers
spend 10x as long on something (e.g. 10 months vs. 1 month)?

Let's imagine a simple, specific example: you want to add a button that sends
a message to the shared backend and displays an alert upon success. Let's walk
through the code.

In your web app, you could add an HTML button, style it with CSS, and then use
jQuery to send a request and define your success handler. Probably not more
than 10 lines and a few minutes (depending on much time you spend with the
CSS).

In your iOS app, you could add a button with Interface Builder, link it to a
method on the relevant view controller that sends an NSUrlRequest, then add a
delegate method that displays a UIAlertView when the response returns
successfully. Again, not more than 10 lines. And no CSS, thank god. :-)

Where is the extra overhead that you're talking about coming from?

~~~
emmett
Perhaps a binary or ternary order of magnitude, rather than a decimal one. 10x
is probably an exaggeration I would say typically it's more like 2-4x.

As I'm not an expert iOS programmer, I'm not exactly sure where the overhead
comes from. Given the bugs that are usually present in iOS apps, the tricky
bits appear to be:

\- Handling screen reorientation

\- Making scrolling smooth (it's easy to load either to lazily or too
greedily)

\- Making it feel "snappy"

\- Not segfaulting when you have an error

The web executes on hardware far faster than mobile does so you have a lot
more leeway to be sloppy. Ditto for the fact that web apps can't segfault, and
it's hard to actually crash a browser.

Another really important point: Doing things on mobile is easy, almost as easy
as the web. Doing things WELL on mobile is much harder comparatively because
the platform is lower level and less powerful.

------
rglover
I think this skews the definition of mobile first a bit (I'm working from the
Luke Wroblewski definition). I've been designing/building a couple of web apps
that are "mobile first" and being built responsively. The result is fantastic
and makes for a much cleaner, more streamlined interface. Not to mention code
complexity is cut down, too. Mobile is imperative. If you're building an app
for the web, it should be mobile first.

------
cluda01
I would say that mobile browsing is supplementing desktop usage (not replacing
it). I just don't see how you could replace the experience of a large 21"
monitor, multi-core high powered processor, and a large quantity of ram on a
form factor several orders of magnitude smaller.

------
anuraj
Emerging markets are directly transitioning to mobile instead of web.
Developed markets will take little more time to shake off legacy. But if you
are starting today, you are ignoring mobile at your peril.

------
mangoman
Last weekend some friends and I participated in a hackathon. Our app was
primarily mobile, with some web. The web guys had a great looking product
done, along with our backend, in about 10 hours. The android guys had an okay
looking app that barely worked, plagued with memory issues, in about 23 hours,
1 hour before we had to submit. We ended up doing well, but the android dev
just took much longer to hack out than the web part.

~~~
gte910h
Eh, people's skill in stuff is all over the place. I think android, especially
UI based android, IS slower currently than iOS to make, however I am guessing
your iOS app was done by people who were better at their type of apps in
general

~~~
georgemcbay
Eh? The guy you responded to was talking about a web app and an Android app,
iOS didn't factor into it at all.

~~~
gte910h
>Our app was primarily mobile, with some web. The web guys had a great looking
product done, along with our backend, in about 10 hours.

Really? "Primarily Mobile, with some web" doesn't sound like a web app to me.
Sounds like a app that runs on a mobile phone, that's not android.

Perhaps he meant what you think he meant? It's unclear.

~~~
mangoman
Clarification: It was an app based around picture taking, and you could view
those pictures online. The viewing online looked great, but the taking
pictures, and view pictures on the android app was slow and running out of
memory all the time. We could barely get it to run on Android 4.0 which has a
larger heap size for apps than our target 2.3.3.

Sorry if that was unclear!

~~~
wallflower
Unfortunately once you get into heavy picture viewing, you need to go to
OpenGL. In fact, almost all of the top selling custom launchers and live
wallpapers are OpenGL.

------
laktek
"Mobile First" shouldn't necessarily mean you should build a native mobile
app. You can put your efforts to build a responsive web app, that would scale
from mobile to web.

It's better if your MVP is ubiquitous, without being tied to either desktop or
mobile. This allows users of both demographics to explore and engage with your
app.

------
LeonW
This is a great post and I couldn't agree more. On top of the development
cycle something else comes into play.

There are so many dynamics around mobile, especially on Android you need to
understand. With Android, you really stand no chance to build a slick app,
unless you have 600+ devices at hand where you can test the app.

With iPhone, it is very hard to track where your signups come from and content
marketing on the web becomes a lot more difficult if you start with a mobile
version. Directing traffic to a mobile only solution is never a very
streamlined process for the user we found.

------
programminggeek
I think the author is coming to the wrong conclusion for the wrong reasons.
You can iterate VERY fast with mobile and dev doesn't have to be slow at all.
You can use HTML5 with PhoneGap or whatever and get to 80%-90% of the quality
of a native app, especially an informational/shopping app.

The key is that you probably will end up rewriting your app to be proprerly
native once you fight the right "product market fit" if you don't have good
enough performance. That being said, you don't have to be the worlds fastest
or best app to prove out a business model.

~~~
danielrhodes
This is a common mistake made these days: use webviews to jump start
development and then go native later. Many of the supposed benefits of
webviews simply don't exist, from increased reliability through fast iteration
to faster development. They are also hell on earth to work with because they
are far more fickle than a normal web browser. The reason mobile development
is slow right now is that the languages and frameworks are not optimized for
moving quickly and you need to do a more traditional software release cycle if
you plan on having an even remotely bug free app.

------
srram
"we believe that the future of shopping is primarily mobile (particularly
tablets), but we’ve consciously chosen a “web first” strategy. The reasoning
behind this is simple, mobile development is still slower than web development
by nearly an order of magnitude"

This makes absolutely no sense. Are you saying that though your customers are
approachable via mobile, you are choosing web because it is easier? This
reminds me of the guy looking for a lost ring under a streetlamp though he had
lost it elsewhere because it is easier to see under the streetlamp

------
commanda
It may be a little misguided to say that companies like Parse are speeding up
the iteration cycle for mobile apps. Every business is going to need a backend
to store all its data, so the time spent architecting and building the backend
layer should be equal regardless of whether your frontend is browser-based or
native mobile.

Parse only helps if you don't have anyone on your team who is fluent in
building backends. That being said, Parse is an excellent choice when you're
in that situation.

------
stewie2
I disagree with the author. I think writing an app is easier than making a
website.

HTML was invented as a format for document. it's essentially a document format
like Microsoft word file. Now, with the idea of web app, people try to make a
document look like an app or even a desktop application. And this is
difficult.

will you use Microsoft word to develop an app?

I feel that writing an ios prototype is much easier than working with
javascript.

------
joelhooks
A solid hypermedia API first.

~~~
kintamanimatt
A what? I have never heard the words "hypermedia" and "API" juxtaposed as
such. Is this something different to a REST API, which the results returned by
Google seem to suggest without clearly articulating the difference.

~~~
johns
A Hypermedia API is essentially what a by-the-book REST API is. Most "REST"
APIs don't meet the hypermedia requirement outlined in the original
dissertation. But because the term REST has been generalized beyond what it
actually was defined as, some purists have taken to calling truly RESTful APIs
"Hypermedia APIs"

~~~
kintamanimatt
That seems to happen a lot, kinda like how the Rails framework misapplies the
MVC pattern and is really a MVA framework. I just assumed it was some new fad
around APIs; I found a conference talk I'll watch later.

One day I'm going to release the OMFGBBQ pattern. I don't know what it does
yet.

------
nc
Sounds like you are mobile first (because you're targeting tablets). Which
makes this discussion about native (obj-c, java) vs web for prototyping
consumer tech services.

Most consumer tech services are seeing usage move to native apps which
emphasis great experience - surely working on that counts towards reaching
product-market fit.

------
AznHisoka
The revenue stream is also more mature for web than it is for mobile. So you
have a better chance of reaching profitability faster, giving you more
time/money to invest in the mobile platform in the future.

------
emehrkay
Cool site that he links to. It was fun to play around and only require an
email address to get in with no validation. My only gripe is that the pants
only goes up to 36 waist while weight options are upwards of 300lbs.

