11 ms·

New Startup? Think Twice About Mobile First

103 points by jamiequint 14y ago

cageface 14y ago
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-201105-201205 http://gs.statcounter.com/#mobile_vs_desktop-ww-monthly-2011... Mobile is definitely important but the truth is nobody knows if the equilibrium point is 20% of the market or 90%.
- jamiequint 14y ago
  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_internet_usage.png https://dl.dropbox.com/u/120/Screenshots/emerging_market_int...
  - cageface 14y ago
    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 14y ago
      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.
  - mozami 14y ago
    The graph you've linked to looks too symmetrical to be realistic.
    - patrickg 14y ago
      If there are only two options that add up to 100% it must be perfectly symmetric.
      - grok2 14y ago
        But why do they add up to 100? What are they measuring to get the data -- traffic in the provider's networks?
        Danieru 14y ago
        Because that is how percentages work.
- allardschip 14y ago
  Comparing pure visits or pageviews to sites with a counter is not capturing the whole story. App interactions are not necessarily hits for a stat counter. A better indicator is time actually spent on different devices (which is not the same as 'time on site' in analytics). How many hours are people in front of a desktop computer and how much time do they spent on mobiles and tablets?
- huxley 14y ago
  If you start on December 2008 and end in May 2012, it is much easier to see the trend. I agree that it is an exaggeration to say rapid, but it does look like a definite downward trend for desktop and upward for mobile.
cluda01 14y ago
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.
joelhooks 14y ago
A solid hypermedia API first.
- kintamanimatt 14y ago
  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.
  - stan_rogers 14y ago
    I believe that it's a registered trademark of CompuGlobalHyperMegaNet Inc. (formerly InterSlice LLC). Buzzwords at their best.
  - johns 14y ago
    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 14y ago
      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.
  - joelhooks 14y ago
    Twilio is a good example. It boils down to delivering links with API results. So, given the root endpoint, a client can navigate/discover available actions for data retrieval/manipulation. You could certainly argue that it is a "buzz word" or whatever, but there is a fundamental lack of buzz around the subject. REST is one of those terms that has been beat to death. Used/misused to describe so many things so as to be useless. Hypermedia adds a specificity to the equation that is useful, at least to me. I like Fowler's description of the Richardson Maturity Model[1], which describes the "levels" of RESTfulness an API can have, with a full-on hypermedia API being the top level. Steve Klabnik's "Designing Hypermedia APIs"[2] is also shaping up to be a good resource, though it isn't free. [1] http://martinfowler.com/articles/richardsonMaturityModel.html http://martinfowler.com/articles/richardsonMaturityModel.htm... [2] http://designinghypermediaapis.com/ http://designinghypermediaapis.com/
anuraj 14y ago
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.
laktek 14y ago
"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.
nc 14y ago
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.
rwhitman 14y ago
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...
- samgro 14y ago
  I agree with this. Mobile first doesn't necessarily mean native first. From both design and engineering perspectives, it is much easier to build a website that looks good on both mobile and desktop and then add components to the desktop site than it is to start with a desktop site and pare it down to work well on mobile.
- msrpotus 14y ago
  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 14y ago
    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…
LanceJones 14y ago
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 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 14y ago
  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/ http://stuffandnonsense.co.uk/projects/320andup/
markerdmann 14y ago
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.
- nirvana 14y ago
  Same experience here. I'd say iOS development is probably about %50 faster than web development for me. Maybe %100-%200 for complex apps.
- marknutter 14y ago
  Even if that's true, you are developing for one platform so the comparison is a bit disingenuous. Mobile development is made slower because of fragmentation, not the tools. Unless you've magically found a way to port your apps over to Android and Windows Mobile..
  - flatline3 14y ago
    Windows Mobile is a bit player still, doesn't matter for startups (or non-startups). That leaves you with Android and iOS. Most startups can start with iOS and add Android later -- there just aren't the sales numbers to prioritize Android development. So we're back down to one platform, with native development providing definitively better results with less time. Supporting differing platforms is not ideal, but somehow we built the entire PC industry on top of this concept, and it worked out. Maybe we should be looking at ways to bring ObjC code bases over to Android, or something that would let us re-use non-UI code.
    - cageface 14y ago
      But most startups aren't built around making money off direct app sales anyway so Android sales aren't the issue. If you're an Instagram or Pinterest or Flipbook the Android userbase it way too big to ignore.
AznHisoka 14y ago
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.
mangoman 14y ago
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.
- deleted 14y ago
  [deleted]
- gte910h 14y ago
  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 14y ago
    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 14y ago
      >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 14y ago
        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!
programminggeek 14y ago
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 14y ago
  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.
- at-fates-hands 14y ago
  I had the same reaction. Anybody with HTML/CSS and decent JS skills can pick up any of the mobile platforms pretty fast. Not to mention, the abundance of responsive frameworks out there like Foundation and Twitter Bootstrap. Also, modern web development makes it insanely easy to pivot your message or your marketing direction to whatever market you're trying to focus on.
rglover 14y ago
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.
commanda 14y ago
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.
emehrkay 14y ago
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.
physcab 14y ago
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 14y ago
  how do people discover a new website then?
  - physcab 14y ago
    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.
- pm 14y ago
  This is assuming the product you are developing is a consumer product with the intetion of marketing through an app store of some kind. There are plenty of app markets for which an app store is only a method of distribution (the only one, really), and sales/marketing is handled in the traditional manner.
stewie2 14y ago
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.
srram 14y ago
"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
LeonW 14y ago
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.

103 points by jamiequint 14y ago

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-201105-201205 http://gs.statcounter.com/#mobile_vs_desktop-ww-monthly-2011... Mobile is definitely important but the truth is nobody knows if the equilibrium point is 20% of the market or 90%.

jamiequint 14y ago
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_internet_usage.png https://dl.dropbox.com/u/120/Screenshots/emerging_market_int...
- cageface 14y ago
  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 14y ago
    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.
- mozami 14y ago
  The graph you've linked to looks too symmetrical to be realistic.
  - patrickg 14y ago
    If there are only two options that add up to 100% it must be perfectly symmetric.
    - grok2 14y ago
      But why do they add up to 100? What are they measuring to get the data -- traffic in the provider's networks?
      - Danieru 14y ago
        Because that is how percentages work.
allardschip 14y ago
Comparing pure visits or pageviews to sites with a counter is not capturing the whole story. App interactions are not necessarily hits for a stat counter. A better indicator is time actually spent on different devices (which is not the same as 'time on site' in analytics). How many hours are people in front of a desktop computer and how much time do they spent on mobiles and tablets?
huxley 14y ago
If you start on December 2008 and end in May 2012, it is much easier to see the trend. I agree that it is an exaggeration to say rapid, but it does look like a definite downward trend for desktop and upward for mobile.

cluda01 14y ago

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.

joelhooks 14y ago

A solid hypermedia API first.

kintamanimatt 14y ago
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.
- stan_rogers 14y ago
  I believe that it's a registered trademark of CompuGlobalHyperMegaNet Inc. (formerly InterSlice LLC). Buzzwords at their best.
- johns 14y ago
  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 14y ago
    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.
- joelhooks 14y ago
  Twilio is a good example. It boils down to delivering links with API results. So, given the root endpoint, a client can navigate/discover available actions for data retrieval/manipulation. You could certainly argue that it is a "buzz word" or whatever, but there is a fundamental lack of buzz around the subject. REST is one of those terms that has been beat to death. Used/misused to describe so many things so as to be useless. Hypermedia adds a specificity to the equation that is useful, at least to me. I like Fowler's description of the Richardson Maturity Model[1], which describes the "levels" of RESTfulness an API can have, with a full-on hypermedia API being the top level. Steve Klabnik's "Designing Hypermedia APIs"[2] is also shaping up to be a good resource, though it isn't free. [1] http://martinfowler.com/articles/richardsonMaturityModel.html http://martinfowler.com/articles/richardsonMaturityModel.htm... [2] http://designinghypermediaapis.com/ http://designinghypermediaapis.com/

anuraj 14y ago

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.

laktek 14y ago

"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.

nc 14y ago

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.

rwhitman 14y ago

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...

samgro 14y ago
I agree with this. Mobile first doesn't necessarily mean native first. From both design and engineering perspectives, it is much easier to build a website that looks good on both mobile and desktop and then add components to the desktop site than it is to start with a desktop site and pare it down to work well on mobile.
msrpotus 14y ago
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 14y ago
  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…

LanceJones 14y ago

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 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 14y ago
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/ http://stuffandnonsense.co.uk/projects/320andup/

markerdmann 14y ago

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.

nirvana 14y ago
Same experience here. I'd say iOS development is probably about %50 faster than web development for me. Maybe %100-%200 for complex apps.
marknutter 14y ago
Even if that's true, you are developing for one platform so the comparison is a bit disingenuous. Mobile development is made slower because of fragmentation, not the tools. Unless you've magically found a way to port your apps over to Android and Windows Mobile..
- flatline3 14y ago
  Windows Mobile is a bit player still, doesn't matter for startups (or non-startups). That leaves you with Android and iOS. Most startups can start with iOS and add Android later -- there just aren't the sales numbers to prioritize Android development. So we're back down to one platform, with native development providing definitively better results with less time. Supporting differing platforms is not ideal, but somehow we built the entire PC industry on top of this concept, and it worked out. Maybe we should be looking at ways to bring ObjC code bases over to Android, or something that would let us re-use non-UI code.
  - cageface 14y ago
    But most startups aren't built around making money off direct app sales anyway so Android sales aren't the issue. If you're an Instagram or Pinterest or Flipbook the Android userbase it way too big to ignore.

AznHisoka 14y ago

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.

mangoman 14y ago

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.

deleted 14y ago
[deleted]
gte910h 14y ago
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 14y ago
  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 14y ago
    >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 14y ago
      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!

programminggeek 14y ago

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 14y ago
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.
at-fates-hands 14y ago
I had the same reaction. Anybody with HTML/CSS and decent JS skills can pick up any of the mobile platforms pretty fast. Not to mention, the abundance of responsive frameworks out there like Foundation and Twitter Bootstrap. Also, modern web development makes it insanely easy to pivot your message or your marketing direction to whatever market you're trying to focus on.

rglover 14y ago

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.

commanda 14y ago

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.

emehrkay 14y ago

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.

physcab 14y ago

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 14y ago
how do people discover a new website then?
- physcab 14y ago
  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.
pm 14y ago
This is assuming the product you are developing is a consumer product with the intetion of marketing through an app store of some kind. There are plenty of app markets for which an app store is only a method of distribution (the only one, really), and sales/marketing is handled in the traditional manner.

stewie2 14y ago

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.

srram 14y ago

"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

LeonW 14y ago

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.