Rethinking Mobile First(avc.com)
avc.com
Rethinking Mobile First
http://www.avc.com/a_vc/2012/12/rethinking-mobile-first.html
19 comments
I stated it in another comment, but the mobile-first strategy is more about user interaction design than implementation technology choices. The decision between HTML5 or native app or HTML5 wrapped as an app will be different in a year, but the fact that users are using most services mainly from mobile or tablets won't.
If you start a new startup today and you have resources to design a single user experience, it's a choice of designing for mobile/tablets or for laptops. Responsive design is not a solution here, as you have to think full user flows.
It's questions like how much text a user is willing to input? How will they pay? How will they bring their own data to your service? If you are selling anything virtual, you should probably leverage native in-app payment methods instead of expecting user to input credit card details. If user needs to bring his data (photos, documents, Excel sheets) to your service, how he will do it? In the mobile-first world, things like smooth Dropbox integration mean much more than on a laptop/desktop world.
If you start a new startup today and you have resources to design a single user experience, it's a choice of designing for mobile/tablets or for laptops. Responsive design is not a solution here, as you have to think full user flows.
It's questions like how much text a user is willing to input? How will they pay? How will they bring their own data to your service? If you are selling anything virtual, you should probably leverage native in-app payment methods instead of expecting user to input credit card details. If user needs to bring his data (photos, documents, Excel sheets) to your service, how he will do it? In the mobile-first world, things like smooth Dropbox integration mean much more than on a laptop/desktop world.
Absolutely. There are so many trade-offs with mobile and the ones you described are spot on.
I feel like the mobile first is a ruse in some ways that investors love to hype. I had a startup a few years back (mid 2007- late 2010) that got some pretty good angel money. A pretty decent amount to get everything launched and keep us going and keep us running over the years. We rolled out a web site first and slowly built our paying user base up.
But as soon as the iPhone came out, my partner decided that we had to be a mobile company. He told me to remove the website, truncate our db, and start from a 'clean slate'. I was totally against it and years later, we never made anywhere near the money we had before we went mobile (company 'IP' was chopped up and sold off last year). But the thing is, our app really was location based, so from one point of view, it definitely made sense to have a very strong mobile presence. But we killed off our main revenue source to be a 'mobile company' - the stupidest thing ever and I'm a total business 101 fail.
Sure, mobile (as per Mary Meeker and others) has not reached its full potential. But if I were starting a new project, I would definitely consider if mobile first makes sense. I am primarily an iOS developer, but have built on many languages/platforms on the server side for years. I love making mobile products and I believe that there's pretty much always a place for it. But the whole 'mobile first' argument only makes sense for products that rely on the unique traits mobile offers.
Companies/apps like Uber, Wikipedia, News, Music stores, ticketing, Foursquare, etc, make most sense to go mobile first (even tho some may not have). They can be used away from the desktop easily and usually have a benefit in the real world. But unless you product fits into something like that, I would agree more with Vibhu and do mobile later.
And whatever you do, don't kill your main source of revenue to be a 'mobile company'!
I feel like the mobile first is a ruse in some ways that investors love to hype. I had a startup a few years back (mid 2007- late 2010) that got some pretty good angel money. A pretty decent amount to get everything launched and keep us going and keep us running over the years. We rolled out a web site first and slowly built our paying user base up.
But as soon as the iPhone came out, my partner decided that we had to be a mobile company. He told me to remove the website, truncate our db, and start from a 'clean slate'. I was totally against it and years later, we never made anywhere near the money we had before we went mobile (company 'IP' was chopped up and sold off last year). But the thing is, our app really was location based, so from one point of view, it definitely made sense to have a very strong mobile presence. But we killed off our main revenue source to be a 'mobile company' - the stupidest thing ever and I'm a total business 101 fail.
Sure, mobile (as per Mary Meeker and others) has not reached its full potential. But if I were starting a new project, I would definitely consider if mobile first makes sense. I am primarily an iOS developer, but have built on many languages/platforms on the server side for years. I love making mobile products and I believe that there's pretty much always a place for it. But the whole 'mobile first' argument only makes sense for products that rely on the unique traits mobile offers.
Companies/apps like Uber, Wikipedia, News, Music stores, ticketing, Foursquare, etc, make most sense to go mobile first (even tho some may not have). They can be used away from the desktop easily and usually have a benefit in the real world. But unless you product fits into something like that, I would agree more with Vibhu and do mobile later.
And whatever you do, don't kill your main source of revenue to be a 'mobile company'!
Interesting story. What was your product exactly?
We were original doing Jaiku in 2006 with the full focus on mobile initially but pretty soon changed focus to web, because it was impossible to get mobile distribution at those days. We sold to Google in 2007, but had we continued, we would have faced a very interesting decision, when iPhone app store came out: move main focus back to mobile?
Thinking about this alternative history is very interesting. Twitter was clearly ahead on the web, although we gave them some challenge when Leo Laporte and his fans switched from Twitter to Jaiku. But in this alternative history had we realized importance of iPhone early enough (very big question mark, as we were based in Finland, the land of the Nokia) we could have had chance to execute on mobile better than Twitter.
We were original doing Jaiku in 2006 with the full focus on mobile initially but pretty soon changed focus to web, because it was impossible to get mobile distribution at those days. We sold to Google in 2007, but had we continued, we would have faced a very interesting decision, when iPhone app store came out: move main focus back to mobile?
Thinking about this alternative history is very interesting. Twitter was clearly ahead on the web, although we gave them some challenge when Leo Laporte and his fans switched from Twitter to Jaiku. But in this alternative history had we realized importance of iPhone early enough (very big question mark, as we were based in Finland, the land of the Nokia) we could have had chance to execute on mobile better than Twitter.
I stated it in another comment, but the mobile-first strategy is more about user interaction design than implementation technology choices.
I tend to agree, but for this discussion I'm trying to restrict my use of the term to the distinction in the original articles, which as I read them is very much about the technology platform choice rather than matters of presentation or user experience. (Perhaps I've misunderstood the author's intent and that is why I so strongly disagreed with the argument from the earlier blog post.)
If you start a new startup today and you have resources to design a single user experience, it's a choice of designing for mobile/tablets or for laptops. Responsive design is not a solution here, as you have to think full user flows.
With due respect, I don't accept your premise. We're doing it right now, with a web app that uses similar tricks to responsive design to present things differently on different devices. With the obvious exception of collecting payments, where a native mobile app probably has at least one major option that a web app doesn't, we aim for a very similar user flow regardless of the device used to access our service.
This particular app is more about consumption than interaction, so of course we're not representative of the entire field and YMMV. However, I'd say the main thing that lets us present a user experience that is similar across devices is just keeping the whole model very simple and designing the interactions/controls carefully so they are viable on both large and small screens. We do occasionally adapt a certain part of the UI to present things in a more natural way depending on the device, but we don't find this is a problem very often in practice. We've been considering various more interactive/social features, and I would agree that these require more adaptation to suit different devices, but even so, I don't see us building two fundamentally different user interfaces any time soon. Until evidence shows me otherwise, if your user flows are simple and your underlying data/presentation models are good, I don't see why a single user experience with localised enhancements/adaptations can't serve many kinds of device well.
I tend to agree, but for this discussion I'm trying to restrict my use of the term to the distinction in the original articles, which as I read them is very much about the technology platform choice rather than matters of presentation or user experience. (Perhaps I've misunderstood the author's intent and that is why I so strongly disagreed with the argument from the earlier blog post.)
If you start a new startup today and you have resources to design a single user experience, it's a choice of designing for mobile/tablets or for laptops. Responsive design is not a solution here, as you have to think full user flows.
With due respect, I don't accept your premise. We're doing it right now, with a web app that uses similar tricks to responsive design to present things differently on different devices. With the obvious exception of collecting payments, where a native mobile app probably has at least one major option that a web app doesn't, we aim for a very similar user flow regardless of the device used to access our service.
This particular app is more about consumption than interaction, so of course we're not representative of the entire field and YMMV. However, I'd say the main thing that lets us present a user experience that is similar across devices is just keeping the whole model very simple and designing the interactions/controls carefully so they are viable on both large and small screens. We do occasionally adapt a certain part of the UI to present things in a more natural way depending on the device, but we don't find this is a problem very often in practice. We've been considering various more interactive/social features, and I would agree that these require more adaptation to suit different devices, but even so, I don't see us building two fundamentally different user interfaces any time soon. Until evidence shows me otherwise, if your user flows are simple and your underlying data/presentation models are good, I don't see why a single user experience with localised enhancements/adaptations can't serve many kinds of device well.
I agree that with apps that are mostly consumption, responsive design can go a long way. However, I think the biggest wins in the future will be for products that somehow crack the problem of easy manipulation for different application domains in mobile. (We are working on that, rethinking what spreadsheets are in the touch device era)
> The fact is that today there is very little you can't do in a browser app and can do to a useful extent in a mobile app
I don't agree, there are important things that you can't do in a browser: editing content. Just try to use contentEditable in different mobile browsers to see what happen.
I don't agree, there are important things that you can't do in a browser: editing content. Just try to use contentEditable in different mobile browsers to see what happen.
I don't agree, there are important things that you can't do in a browser: editing content.
Sorry, I don't understand this at all. Web apps have for a long time been able to edit everything from formatted text, via spreadsheets and similar "structured" data, to mid-range graphics. There are several well-known web-based "office" suites, and while they can't compete seriously with desktop native apps, for mobile devices that are touchscreen based, I don't see what you think is missing or significantly inferior to what you can do with a native mobile app.
Sorry, I don't understand this at all. Web apps have for a long time been able to edit everything from formatted text, via spreadsheets and similar "structured" data, to mid-range graphics. There are several well-known web-based "office" suites, and while they can't compete seriously with desktop native apps, for mobile devices that are touchscreen based, I don't see what you think is missing or significantly inferior to what you can do with a native mobile app.
Try selecting text on a contentEditable area in iOS (Safari), Desktop, Android (Firefox, Android, Opera, etc) and you will see the differences. Those applications handle specific cases for different browsers.
More concrete: go to http://html5demos.com/contenteditable
i) I run the last Firefox version on Android and when I tried to select text in the content editable area, the begin/end marks go crazy (buggy!)
ii) I run the Mobile Safari on an iPhone. I select the text but nothing happens, just a flash effect (buggy!)
iii) Run the same on Chrome for Android and it seems to work correctly.
Do I need to test in Opera too?
More concrete: go to http://html5demos.com/contenteditable
i) I run the last Firefox version on Android and when I tried to select text in the content editable area, the begin/end marks go crazy (buggy!)
ii) I run the Mobile Safari on an iPhone. I select the text but nothing happens, just a flash effect (buggy!)
iii) Run the same on Chrome for Android and it seems to work correctly.
Do I need to test in Opera too?
Well, OK, but surely the solution to that is not to use an underpowered, poorly specified/not yet standardised HTML5 gimmick, and actually use real input controls and events?
It would be very tricky to do an editor by yourself, it hss a lot of complexities behind. That's why at the end developers use native controls.
[deleted]
"Mobile first" is a great way to design your website: design for the mobile web first, and design for desktop web second. Port to Objective-C only when necessary.
Some teams I've seen blindly follow the 'mobile first' strategy without thinking about what device their application is best suited for. Microsoft Word, Photoshop, and advanced developer IDEs are good examples of software that should be desktop centric. While there are text/image/code editors on mobile, the difference is that people end up crafting with these types of software. They put hours into them on one project and build something they consider truly great. Instagram makes sense on mobile because the amount of time you put into the app is likely under 10 minutes at a time. If you're expecting your users to craft, and to spend long periods of time building something in your app then give them a big screen and a physical keyboard; give them desktop/web.
In addition, I think the point about not being able to rapidly fix issues is a pretty good one. Average app store approval time is now 7 days, and while its possible to do testing to prevent issues, I imagine most first-time startups are not going to be able to fully predict the impact of scale on their app.
In addition, I think the point about not being able to rapidly fix issues is a pretty good one. Average app store approval time is now 7 days, and while its possible to do testing to prevent issues, I imagine most first-time startups are not going to be able to fully predict the impact of scale on their app.
To me it feels like the mobile hype is in decline. People still like their apps, but there hasn't been a breakthrough (non-game) success in quite a while. I say this as Instagram is only 2 years old. SXSW used to introduce a new category of apps each year (Gamified location apps, group messaging, photo sharing) and this year we got... Highlight. Which might be great but it's no Foursquare.
Hype may be in decline but only to rise again as modeled in the Hype Cycle. I think this "Mobile First" thing is a typical example of Amara's Law, overestimating the effect of a new technology in the short run and underestimating in the long run.
The installed base of smartphones and tablets will exceed those of desktops and laptops next year. There are 6 billion phone subscriptions in the world, and only 1 billion pc's. All those phones will become internet-enabled within a decade. It's almost impossible to overestimate the importance of mobile, but it's also impossible to predict winners and losers in that space because most of the growth still needs to happen and there are no precedents to base decisions on.
The interesting bit that I'd like to se more explored is the quote about "two companies that will not help app developers succeed". Those two are obviously Apple and Google, and I think a key of the problem could be right there, under our nose.
Why would Apple and Google not want to help independent devs push their apps on apps markets? (Let's suppose this statement to be true for a sec). We can find many reasons for Apple and Google to avoid random cowboys getting successful with a piece of code on "their" phone. First, it is concurrence. Google Reader has a lot of unofficial clients, and it must be some kind of annoyance, because they might not use the APIs as intended. Indie apps might bridge unwanted links with bigger competitors, or might just pollute the app store with ugly icons, semi-porn, ponzy schemes, or simply noise.
But from their point of view, maybe these companies consider themselves as elephants carrying most of the weight (hear development cost) and just don't want to let a horde of monkeys jump on their back and disturb the convoy. And we need to agree that this convoy has to get his way into the bush.
So app devs should go back to good ol' Web, following Vibhu Norby's advice? That smells like a defeat. Fred Wilson is right in saying that mobile is future, "like it or not". The problem is we, as devs, should make this future ours. We should fight, and we have weapons. I'd love to see "I broke out of my own jail" stickers on every iThing on tech talks. We should hear and speak more about the forks of forks of Android. We should make it the new hype to have one phone in each pocket, each with a different system, all running "pre-alpha" obscure OSes. We should make it cool, easy or even normal to have one's own VPN-NAS-cloud where all the things connect.
(I might have gotten a slip too far, but) if we don't push hard on this, both Apple and Google may slowly bring us all towards the nightmarish path of MicroSoft, where hundred of thousand of slaves push the wheels of a Gigantic Golden Sphinx, and kiss their own blood on the whips of their executioners.
Why would Apple and Google not want to help independent devs push their apps on apps markets? (Let's suppose this statement to be true for a sec). We can find many reasons for Apple and Google to avoid random cowboys getting successful with a piece of code on "their" phone. First, it is concurrence. Google Reader has a lot of unofficial clients, and it must be some kind of annoyance, because they might not use the APIs as intended. Indie apps might bridge unwanted links with bigger competitors, or might just pollute the app store with ugly icons, semi-porn, ponzy schemes, or simply noise.
But from their point of view, maybe these companies consider themselves as elephants carrying most of the weight (hear development cost) and just don't want to let a horde of monkeys jump on their back and disturb the convoy. And we need to agree that this convoy has to get his way into the bush.
So app devs should go back to good ol' Web, following Vibhu Norby's advice? That smells like a defeat. Fred Wilson is right in saying that mobile is future, "like it or not". The problem is we, as devs, should make this future ours. We should fight, and we have weapons. I'd love to see "I broke out of my own jail" stickers on every iThing on tech talks. We should hear and speak more about the forks of forks of Android. We should make it the new hype to have one phone in each pocket, each with a different system, all running "pre-alpha" obscure OSes. We should make it cool, easy or even normal to have one's own VPN-NAS-cloud where all the things connect.
(I might have gotten a slip too far, but) if we don't push hard on this, both Apple and Google may slowly bring us all towards the nightmarish path of MicroSoft, where hundred of thousand of slaves push the wheels of a Gigantic Golden Sphinx, and kiss their own blood on the whips of their executioners.
And how all this nonsense you describe in the third paragraph will help me as a customer/user?
What is so desirable in the future full of fragmented, incompatible, rushed out crap?
If there is a jail it is in the thinking, that development is something soooooo special and should be centre of thinking, politics and universe. Guess what: we make apps for our users. And they want none of that drunken ivory tower vision, they won't go whip out their phone, do what they want to do and go on with their day.
What is so desirable in the future full of fragmented, incompatible, rushed out crap?
If there is a jail it is in the thinking, that development is something soooooo special and should be centre of thinking, politics and universe. Guess what: we make apps for our users. And they want none of that drunken ivory tower vision, they won't go whip out their phone, do what they want to do and go on with their day.
I subscribe to @eli's point...
The constraint of having to rely on the App Stores is the stifling factor.
Mobile applications have still not gotten to the stage where a pure Mobile web app could do everything that a downloadable one can.
And for the downloadable ones the end consumer has become completely reliant on the "big two"...the other app stores are almost non-existent.
Being reliant on the "big two" stifle quick turnaround, experimentation, payment methodologies, and having to toe the line to bizarre rules drawn up almost by whim.
It is a matter of time of course that things can become mobile first (mumble mumble HTML5 mumble mumble)
Eventually..umm..hopefully.. It will come down to just "the Internet" once again rather than having to customize on platforms, as desktops become more mobile and mobile devices become as powerful as desktops.
The constraint of having to rely on the App Stores is the stifling factor.
Mobile applications have still not gotten to the stage where a pure Mobile web app could do everything that a downloadable one can.
And for the downloadable ones the end consumer has become completely reliant on the "big two"...the other app stores are almost non-existent.
Being reliant on the "big two" stifle quick turnaround, experimentation, payment methodologies, and having to toe the line to bizarre rules drawn up almost by whim.
It is a matter of time of course that things can become mobile first (mumble mumble HTML5 mumble mumble)
Eventually..umm..hopefully.. It will come down to just "the Internet" once again rather than having to customize on platforms, as desktops become more mobile and mobile devices become as powerful as desktops.
> stifle quick turnaround, experimentation, payment
> methodologies
I am a consumer too =)
And i enjoy subscribing to beta versions on all my web products...
I enjoy being pleasantly surprised...and that surprise won't happen unless the app developers have complete control over the eco-system, thereby freeing up experimentation... If i, as a consumer, am not pleasantly surprised i shall go my own way to the nearest competitor. But having the "big two" put down rules as to what an app developer should and shouldn't do stifles things. The app developers want a democracy and the consumers are smart enough to judge what is good and what is rot. Hence why the rules?
I enjoy being pleasantly surprised...and that surprise won't happen unless the app developers have complete control over the eco-system, thereby freeing up experimentation... If i, as a consumer, am not pleasantly surprised i shall go my own way to the nearest competitor. But having the "big two" put down rules as to what an app developer should and shouldn't do stifles things. The app developers want a democracy and the consumers are smart enough to judge what is good and what is rot. Hence why the rules?
This article and the comments here on HN seem to miss the entire point of mobile first (although the comments on the article itself are spot on): mobile first does not mean you're actually intending to build for mobile at all.
It means funnel everything your site is trying to accomplish down to how you'd design for small viewports so that the focus is on the most important navigable aspects of your site or service. In knowing where exactly you're trying to send your audience, there are less questions about the hierarchy of elements and calls-to-actions on the rest of your designs.
It means funnel everything your site is trying to accomplish down to how you'd design for small viewports so that the focus is on the most important navigable aspects of your site or service. In knowing where exactly you're trying to send your audience, there are less questions about the hierarchy of elements and calls-to-actions on the rest of your designs.
My idea of the mobile-first strategy (or it's younger sibling: a tablet-first strategy) is that in it's core it defines how you approach user interaction design. In the future, most of consumer internet services and a significant number of business tools are primarily used via mobile devices and tablets. In my opinion, this is a safe bet to make and startups starting today should make that bet.
However, it doesn't dictate neither your initial distribution strategies or your platform or technology choices today. For example you design a mobile user experience, but implement it with HTML 5 and Javascript and wrap that implementation to an app for distribution (and payment) purposes. Or you implement that as a native app because at the moment you can create a smoother experience that way. Or you skip the app part and build just an easy mobile web experience to make on-boarding easy. Distribution tactics and technologies change as mobile platforms evolve, but the fact you need to design for mobile usage doesn't.
Our new startup is doing serious data analysis tool, but from the surface it looks like a very simple tool. We believe this simplicity is essential to succeed in the world where our service will be mainly used via tablets and mobile phones.
However, it doesn't dictate neither your initial distribution strategies or your platform or technology choices today. For example you design a mobile user experience, but implement it with HTML 5 and Javascript and wrap that implementation to an app for distribution (and payment) purposes. Or you implement that as a native app because at the moment you can create a smoother experience that way. Or you skip the app part and build just an easy mobile web experience to make on-boarding easy. Distribution tactics and technologies change as mobile platforms evolve, but the fact you need to design for mobile usage doesn't.
Our new startup is doing serious data analysis tool, but from the surface it looks like a very simple tool. We believe this simplicity is essential to succeed in the world where our service will be mainly used via tablets and mobile phones.
User experience, discoverability, and offline. These three features have traditionally been the primary reasons to build a native mobile app, and even target mobile first. But the web, with its open nature and flexible usefulness, has a way of reducing the lead that native has in these three areas.
User experience - You can still create a better experience with a native mobile app, but that's changing and many apps don't require the snazziness of a native experience to still be amazing. (See Basecamp mobile)
Discoverability - The web hasn't changed much, but the app stores are hurting themselves. Vibhu's point that discoverability and the viral loop is VERY hard on mobile is illustrative of the lead that native mobile had in discoverability diminishing.
Offline - Although HTML5 can handle much of that problem on the web, I think a really great offline experience still requires a native mobile app. However, the increase in connectedness and the realization that most apps don't need to have offline at their core means the gap is narrowing as well.
User experience - You can still create a better experience with a native mobile app, but that's changing and many apps don't require the snazziness of a native experience to still be amazing. (See Basecamp mobile)
Discoverability - The web hasn't changed much, but the app stores are hurting themselves. Vibhu's point that discoverability and the viral loop is VERY hard on mobile is illustrative of the lead that native mobile had in discoverability diminishing.
Offline - Although HTML5 can handle much of that problem on the web, I think a really great offline experience still requires a native mobile app. However, the increase in connectedness and the realization that most apps don't need to have offline at their core means the gap is narrowing as well.
We've been here with the desktop before, and it's shaking out much the same way:
User experience: web apps are still worse than desktop apps and always will be. Good enough is good enough. On mobile the good enough tipping point for web apps is now.
Discoverability: the app stores don't have enough shelf space for new apps just like the physical stores didn't have enough shelf space for boxed copies. Web apps were more discoverable because word of mouth is the primary vector and nothing is easier than sharing a link. On mobile the same is true: going viral is easier with a mobile web app loaded in the browser, but people haven't caught on to that yet.
Offline: i've built and shipped an offline mobile web app. There is only one hard constraint, and that's the 50 mb of storage you get on iOS (and that with caveats). Otherwise it's just a question of the API's being nicer to use on native. That reduces offline on web to a matter of tooling and expertise, painful but solvable. You can implement all the same use cases, it just takes more engineering in some cases. On iOS you can even hide the browser's chrome, and put a nice glossy icon on the homescreen.
User experience: web apps are still worse than desktop apps and always will be. Good enough is good enough. On mobile the good enough tipping point for web apps is now.
Discoverability: the app stores don't have enough shelf space for new apps just like the physical stores didn't have enough shelf space for boxed copies. Web apps were more discoverable because word of mouth is the primary vector and nothing is easier than sharing a link. On mobile the same is true: going viral is easier with a mobile web app loaded in the browser, but people haven't caught on to that yet.
Offline: i've built and shipped an offline mobile web app. There is only one hard constraint, and that's the 50 mb of storage you get on iOS (and that with caveats). Otherwise it's just a question of the API's being nicer to use on native. That reduces offline on web to a matter of tooling and expertise, painful but solvable. You can implement all the same use cases, it just takes more engineering in some cases. On iOS you can even hide the browser's chrome, and put a nice glossy icon on the homescreen.
Seems like a complaint mostly against the current realities of the native app stores, not against the concept of mobile or even "mobile first"
The biggest argument in favor of mobile first is that it's easier to port your mobile UI to your web UI. This assumes that the use cases between your mobile UI and your desktop UI are the same.
This may be a valid assumption for many, but don't assume that this is true by default for you. Take the time to understand your users and use cases and determine what makes the most sense for your context.
This may be a valid assumption for many, but don't assume that this is true by default for you. Take the time to understand your users and use cases and determine what makes the most sense for your context.
Having come from a few startups and many more random experiments - most mediocre failures, I'd tend to agree that the web allow for much more initial testing and product validation (depending on the product and industry of course).
Gabor Cselle wrote an excellent post a few months back titled "The Biggest Problem in App Discovery" ( http://blog.gaborcselle.com/2012/10/the-biggest-problem-in-a... ) that every new startup with a basic MVP app will face (heck even with a fully polished app it's hard).
The point that needs to be really illustrated is that the web is still critical and regardless of the language used, will provide you with a suitable platform to test, iterate and improve before investing time trying to compete for minds, hearts and wallets on mobile.
Gabor Cselle wrote an excellent post a few months back titled "The Biggest Problem in App Discovery" ( http://blog.gaborcselle.com/2012/10/the-biggest-problem-in-a... ) that every new startup with a basic MVP app will face (heck even with a fully polished app it's hard).
The point that needs to be really illustrated is that the web is still critical and regardless of the language used, will provide you with a suitable platform to test, iterate and improve before investing time trying to compete for minds, hearts and wallets on mobile.
Kickstarter, Pinterest, and Airbnb are interesting counterexamples to the mobile first thinking. They are three of the biggest success stories of the last few years. Two have solid business models and seem to be scaling well. Pinterest at least has a path to one via affiliate fees. Of the three KS doesn't have an app. Pinterest's breaks a lot of the key functionality and makes it basically read only. Airbnb has done a really good job considering the mobile vs. desktop uses cases and designing appropriately.
Mobile is unquestionably the future, but it's a little surprising that there hasn't been a huge, non-game, break away money maker. As cool as Instagram was, it felt like a bit of a panic acquisition. Maybe we have to wait for Square to exit to see the first big proof.
Mobile is unquestionably the future, but it's a little surprising that there hasn't been a huge, non-game, break away money maker. As cool as Instagram was, it felt like a bit of a panic acquisition. Maybe we have to wait for Square to exit to see the first big proof.
Mobile is unquestionably the future, but it's a little surprising that there hasn't been a huge, non-game, break away money maker.
Mobile devices are surely the future for personal information retrieval and a lot of social interactions, which collectively makes up a huge part of the consumer market. Mobile apps, I am much more sceptical about.
For one thing, web apps and cloud buzzwords took hold partly because it was so much hassle to deploy and maintain traditional native apps on the desktop. I don't see any reason the same arguments won't hold for mobile over the long run.
For another thing, you have to consider the nature of the markets. Winning big in web app world, where there is real money to be made in B2B, is being Salesforce. Winning big in platform/channel world, where you're not just hitting consumers but rather every interaction between consumers and other consumers or businesses, is being Google or Facebook or Amazon or Steam or PayPal. Winning big in mobile app world, where users look at a $1.50 app that's going to save them 10 minutes a day and wonder if it's too expensive, is... maybe enough to pay the rent?
Mobile devices are surely the future for personal information retrieval and a lot of social interactions, which collectively makes up a huge part of the consumer market. Mobile apps, I am much more sceptical about.
For one thing, web apps and cloud buzzwords took hold partly because it was so much hassle to deploy and maintain traditional native apps on the desktop. I don't see any reason the same arguments won't hold for mobile over the long run.
For another thing, you have to consider the nature of the markets. Winning big in web app world, where there is real money to be made in B2B, is being Salesforce. Winning big in platform/channel world, where you're not just hitting consumers but rather every interaction between consumers and other consumers or businesses, is being Google or Facebook or Amazon or Steam or PayPal. Winning big in mobile app world, where users look at a $1.50 app that's going to save them 10 minutes a day and wonder if it's too expensive, is... maybe enough to pay the rent?
I think this comment by Brandon Burns made on Fred's blog puts things in their proper context.
I feel like a point is still being missed: mobile is a channel, not a product strategy.
Instagram worked mobile first because you use it to take pictures, which you do on your phone. You also use your phone to order a taxi, and to connect with friends when out — Uber and Foursquare.
Google still has more activity on the desktop than mobile; why? Because people don't like executing intensive searches on a small screen. Viral content driven platforms do better on desktop; why? People look at and share content mostly while goofing off at work, on the computer on their desk.
Your product defines how you execute it, not the channel.
Chase user behavior, not press headlines that say "X sector is growing!"
Think like an experience designer, not like a VC.
I feel like a point is still being missed: mobile is a channel, not a product strategy.
Instagram worked mobile first because you use it to take pictures, which you do on your phone. You also use your phone to order a taxi, and to connect with friends when out — Uber and Foursquare.
Google still has more activity on the desktop than mobile; why? Because people don't like executing intensive searches on a small screen. Viral content driven platforms do better on desktop; why? People look at and share content mostly while goofing off at work, on the computer on their desk.
Your product defines how you execute it, not the channel.
Chase user behavior, not press headlines that say "X sector is growing!"
Think like an experience designer, not like a VC.
Both arguments are correct - mobile is the future of customer engagement, and persistent engagement in mobile apps is hard. It’s especially hard because the tools we use in the physical or virtual world (CRM, messages, updates, tutorials, polls, questions, feedback, dialog, etc), by and large don’t yet exist for the mobile app world. These tools are the grease to iteration to get app engagement to a better place. Today the mobile apps publishers are hermetically sealed from both knowing and communicating with their app users. This is the problem our startup converser.io is addressing.
"If you design for the web and then port to mobile, you will find that it is really hard to fit your UI onto the small screen."
Then don't try make it fit. Try designing for it separately, since it's an entirely different experience.
If you're trying to work out which order to design in, this is really bad advice, as it isn't one-fits-all.
Think of it this way: should the majority of usage happen when we're out and about (native mobile), or when we're sat at a desk (full web)? or do you want to do both in the shortest amount of time (responsive web)?
Then don't try make it fit. Try designing for it separately, since it's an entirely different experience.
If you're trying to work out which order to design in, this is really bad advice, as it isn't one-fits-all.
Think of it this way: should the majority of usage happen when we're out and about (native mobile), or when we're sat at a desk (full web)? or do you want to do both in the shortest amount of time (responsive web)?
I'm wrestling with this right now with regards to a project I'm doing with my wife (http://www.cheergram.com). It's doing well and my wife would like to move into other printed products after New Years (baby announcements, etc.)
Right now roughly 40% of our traffic comes from mobile/tablet. Our web app works fine on iPad but not well on smaller screens. I'm considering an iOS app but can't decide if its worth it (my gut tells me no).
Right now roughly 40% of our traffic comes from mobile/tablet. Our web app works fine on iPad but not well on smaller screens. I'm considering an iOS app but can't decide if its worth it (my gut tells me no).
Another reminder to take all advice as advice and not fact. Luckily at Hall we actually thought this through and learned for us what was more important was Desktop First and we weren't shy about it... https://hall.com/blog/desktop-first/
what i find interesting is the disruption mobile/ tablets are causing. If you're a security company, what do you sell to a tablet user? who buys security software for an ipad?
... especially if it's a BYOD bring your own device, owned by the employee.
Why do so many people still pretend mobile and web are a binary choice? Web is a medium, mobile is a platform. Mobile devices can access the web. 90% of the apps people are making have no business being an app, and should just be a properly designed website that works on all devices. This is just like all those people selling "multimedia presentations" on cds in the late 90s instead of making it a web site.
This. I got strange looks when I discussed this issue with a few (non-technical) friends a while back. I said that Apps as they currently exist are more or less an interim solution. Sure, if you need to take pictures/videos it can be a useful thing to have a specialized app but most of the times a proper mobile webpage would suffice.
The only thing I am not so sure about when using your browser as your primary application container. What about UI/UX Guidelines. A well designed webapplication works for both ios/android users, but there still different UI paradigms in place.
Think of all the effort which is put in place to make for example java programs look native on the different systems.
The only thing I am not so sure about when using your browser as your primary application container. What about UI/UX Guidelines. A well designed webapplication works for both ios/android users, but there still different UI paradigms in place.
Think of all the effort which is put in place to make for example java programs look native on the different systems.
"a proper mobile webpage would suffice"
I think people have higher aspirations than "would suffice".
I think people have higher aspirations than "would suffice".
Can you be specific? For example, what exactly would a mobile app of hacker news provide above and beyond what can easily be provided by a web site?
Websites should look, feel and behave like websites. Trying to imitate the native look and feel of an individual device/platform combination is bad. Just as it was bad to make horrible flash monstrosities that tried to pretend a webpage was a windows app.
Sorry, but that is hubris, plain and simple. I know plenty of people who read the original post on the AVC blog. Most of us didn't buy it then, and still don't.
The fact is that today there is very little you can't do in a browser app and can do to a useful extent in a mobile app. Mobile browsers are driving support for HTML5 features and Javascript tools supporting useful features like geolocation, and they do it well enough to meet a lot of needs now.
If I write a browser app then I have a few portability/degradation issues to deal with, but I'm only maintaining one code base so I can spend all my development time getting those things right. If I write mobile apps, I need a whole new app on each platform I want to support, plus I still need a browser app or a native executable for each major platform if I want to support customers on desktops/laptops as well.
If I write a browser app then I can charge however I like using a variety of services, and aside from taxes and overheads for collecting payment it's all mine. If I write mobile apps, I'm losing an absurd proportion of revenues to the likes of Apple when people buy my app, and I have to comply with all kinds of onerous rules about charging later too.
If I write a browser app then I can distribute it under my control. If I write mobile apps, then I have app stores and their infamous approval processes to get through, and if they decide they don't like me, all my effort was for nothing.
In short, mobile apps suck (from a business or software development perspective). They have exactly one redeeming feature, in that you can still do a few things with them that are harder or impossible with web apps, and even that advantage is reducing almost by the day. Otherwise, for most information consumption or communication software -- which is, let's face it, about 99.99% of what everyone is running on mobile devices anyway -- it's hard to see any reason to invest in mobile apps today.