Comment by Silhouette | Hacker News Reader

Comment by Silhouette | Hacker News Reader

It has become a bit of a orthodoxy among the consumer social startup crowd to do mobile first and web second.

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.

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.

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

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'!

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.

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

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?

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.

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

Reply on news.ycombinator.com