Hacker News Reader

Comment by potatolicious | Hacker News Reader

I disagree - native apps aren't somehow an extension of websites, they address a different use case altogether.

The two examples brought up should never have been apps (and if apps were built, someone is doing something very wrong) because they were never regular-use services. How often do you book a driving exam or look up city regulation?

There are use cases where you don't want a website-first approach. Instagram would never fly as a mobile site, nor would Facebook, nor Twitter. When you're building something you're expecting users to hit multiple times a day, the native experience is far better.

The reverse is also true: if your product is not something that people will be hitting every day, don't build an app for it and stop wasting time.

View on HN

The question was not whether native apps generally make sense, but whether "the government should also be investing heavily in mobile apps?"

And I think that the policy to focus on mobile web first is sound for that use case.

> "but whether "the government should also be investing heavily in mobile apps?""

And that depends entirely on use case. A generalized "web first before native" seems misguided. If this was, for example, a schedule app for the tube, a weather service, or any such thing that users would can be expected to use daily, then an app IMO makes more sense than a website.

I'm still not sure about that, I still tend to equate native apps to native apps as you traditionally saw them on desktop or laptop computers when considering downloading them.

People love hoarding things, and downloading them with the "I'm going to be super efficient with this new tool!" thinking when in fact they barely even touch it after having downloaded it. My brother's iphone now has I think 6 full pages of apps... and I'm pretty sure a lot of times he spends more time searching for the app he's looking for than he would have to spend simply opening up chrome and typing in the URL.

I'm also worried that if you give these companies access to your phone by going native they're going to continue getting sneakier and sneakier to try to get your attention in artful ways to ultimately sell you stuff (or sell your information to others). The power lies with the user if he sets the boundaries, and indeed, I believe he would be best served by making the decision of keeping the web on the web.

My question is: how can we make the web experience better, so it can meet the native experience headway? How much time will it take to get there until the web experience is truly comparable or better than the native experience?

With bandwidth capped wireless, the push in the future is going to be less web apps and more native apps for things you need to do on a regular basis.

It would probably be better just to expose weather and tube schedule information as JSON and allow third party developers to use it.

AFAIK this already happens to some extent.

Sort of. I'm all for open access and government data behind APIs, but it also leads to some level of unfairness. In NYC for example the MTA has opened subway schedules and (on some lines) live arrival estimates via API, which has led to an explosion of commercial applications.

So taxpayers have to either pay a private entity for access to public data, or download scummy "free" apps and have it hoover up their private data.

Opening up APIs should not preclude the government from building its own frontends, in whatever format makes sense.

Sure, I didn't mean to suggest that the government should not provide any front end at all. After all outputting a simple HTML page with the same data in addition to a JSON dump should not be a difficult task in any sane web development architecture.

However if you want app for your iphone 6 that integrates with the wardrobe planner that tells you what to wear when it is wet outside I think it is reasonable to let that development be funded privately.

If you read the full article, you'll find this:

The 5 questions civil servants should ask before contemplating asking for an exemption are:

1. Is our web service already designed to be responsive to different screen sizes? If not, why not?

2. What is the user need that only a native/hybrid app can meet?

3. Are there existing native/hybrid apps which already meet this user need?

4. Is our service available to 3rd parties via an API or open data? If not, why not?

5. Does meeting this need justify the lifetime cost of a native or hybrid app?

I think this is a good set of questions for a government to ask before deciding to develop an app.

I exclusively use the facebook mobile web app. The native app used to be much slower and have less features than the web incarnation. The speed issues were apparently remedied by going 100% native (it was hybrid before?) but I've never felt the need to go back. And I guess the web app will always be ahead of native in terms of features given that it's probably in lock-step with the desktop web app?

I find your argument a little off though. If native is so important for regular use services why is there no desktop facebook app? Yes, faster connections, but these days I have no problem in 95% of situations getting a good mobile connection.

> "If native is so important for regular use services why is there no desktop facebook app?"

I had a longer post written out, but it felt disjoint and fails to address the core point, which is:

Mobile browsers are extremely, absurdly, obscenely bad compared to their desktop counterparts

That's pretty much the only reason apps exist.

I also used the Facebook webapp exclusively for a while - when the "native" app was so bad that it out-sucked the iPhone's craptastic browser (a major feat, if I may so). Since then they've made a lot of improvements and I've gone native again.

To be somewhat simplistic, there isn't a desktop Facebook app, because you'd be hard pressed to beat the quality of experience you get from a desktop browser in the first place, especially when we're talking strictly about the mouse+keyboard world.

If mobile browsers ever stopped sucking, the app market would shrink to a tiny fraction of its current size overnight.

To be more specific, there are a bunch of problems:

- Touch detection is mediocre compared to native. A mouse click is a pretty binary situation and easy to judge - a finger is harder and involves more soft factors. Currently both the state of the art iOS and Android browsers will routinely miss clicks. The Surface browser stands out as particularly bad.

To extend this a bit: if you find yourself building even relatively complex native mobile UIs you'll inevitably start handling some low-level touch events yourself. The human finger is an imprecise instrument and once you go beyond the "touch this big button, then touch that big button" UI you will have to do some work to help your users do what they intended. This level of control is currently unavailable to websites, though this may exist in the future (I sure as hell hope it does).

- Caching behavior is plain awful. We have tabbed browsing, but we don't actually have tabbed browsing. On my PC I have an abundance of HDD and RAM, I have dozens of tabs open and I can return to any of them instantaneously - this is a huge part of the usefulness of the web. On mobile I can pop over just a couple more tabs and it's already dumping my cache, and returning to a previous tab means a complete reload of everything, across the network. Switching tabs on a mobile browser is frequently an awful experience - one much, much worse than the counterpart of switching apps.

Furthermore, mobile users use apps like they use tabs on desktop: many at once, with the expectation of seamless, instant resumes when switching. This mode of usage is completely absent on any phone browser available now, though the marketing material may insist otherwise.

- Lack of platform-specific interactions. There is, practically speaking, only one interaction available to mobile apps: the click/tap. A huge part of why smartphones even took off was the extended way in which you can interact with your device - swipes, pinches, rotates, in addition to "clicks". You "can" implement these in webapps, but the performance is almost universally atrocious (see: Google Maps mobile web) and unreliable. Web apps on mobiles stick out like sore thumbs because they almost always mean a substantial narrowing of interactivity in a way that's very user-visible.

So yeah, tl;dr: mobile-native exists because mobile-web is a pale, pasty shadow of desktop-web.

To add to your example, the Facebook mobile site also inherits all the mobile browser features that many apps lack. For example, the mobile web site has better copy/pasting than the app, works with browser extensions (eg AdBlock & Stylish) and allows multiple simultaneous views (browser tabs). The browser is also kept in the device's RAM so normally loads faster than other apps.

Very good poiny! I thought I had alluded to this in my original comment but I guess I removed before posting.

I know the browser UI better than I know your app's UI. I know how copy/paste works. I know what enter will do in the context of a form. I know how to open things in new tabs, or go into incognito mode. Shit I even know how to inspect the client-side code of your mobile app. And all the other things that I know because it's standard behaviour across browsers.

Twitter? Their web-app is awesome. I don't use the other examples you mentioned, so I wouldn't know, but I don't see what a native Twitter app would give me.

For me, having Twitter as something other than a web page seems completely backwards, since the main thing I do on Twitter is scroll, and click links. That open in a browser.

I agree pretty completely but Twitter does an awful job of "notifying" you of things on their web app, or on their website even. There are days that I'll be on Twitter.com throughout the day and not notice mentions, replies etc until I look at my phone on the way home and see the app's notifications.

Reply on news.ycombinator.com