Rethinking Mobile First
avc.com
avc.com
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.
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.
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 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'!
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 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.
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.
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?
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.
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.
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.
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 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?
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.
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 - 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: 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.
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.
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.
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 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 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.
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)?
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).
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.
I think people have higher aspirations than "would suffice".