The Decline of the Mobile Web
cdixon.org
cdixon.org
The other reason flash was a pain, incidentally, was because it was easy to bog down a client computer with overzealous flash stuff... just like the current tendency to use javascript to do all your rendering and computation clientside -- exactly when more people than ever before are browsing on pocket devices with far less horsepower than traditional computing devices.
The biggest issues are bandwidth/asset file sizes & using heavy-weight frameworks. They bog down the UX on mobile devices.
On my current project, I'm using browserify, Backbone, jQuery, & compiled Handlebars. The same codebase supports rendering on the web server, rendering on the web client, mobile web, & apps using PhoneGap. Things seem to be performing well, even on the S2.
Note: there are strange performance issues with the S4 stock browser.
Please understand I'm not passing judgment on the matter -- but I would like to highlight the relatively elite status of people with quad-core telephones.
I actually do handle the low end phones by rendering a basic html page on the server. Same codebase :-)
I love the irony that this accurately describes the very page we are reading this text on...
One wonders if performance could be solve by open-sourcing flash. I liked AS3 more than JS.
On your home screens idea - I think you could make the home screen over and it won't change the fact that most people use a handful of apps regularly (every day), another handful less frequently (once a week to once a month) and then a large pool of apps that never get looked at again.
Do you somehow think Flash people didn't believe Flash was being used to "enhance the user experience"?
I'd say 80% of developers who choose native do so for performance, and 20% do it because the app store and home screen placement is better for branding and content discovery than just sticking up your website on a server somewhere.
I think there's room for some sort of hybrid product but I'm not sure what it would look like. Maybe a mobile browser with super-aggressive caching (like not even a HEAD request for JS and CSS) and the ability to improve performance for the foreground page to the point where it's near-native. I'd use that for the mobile websites that I use less frequently, and continue to download the native apps for the things I use every day.
I recently built this as a side project using Bootstrap and it feels similar to an app (or faster) on iOS 'saved to my homepage': http://moneytrackr.ca/
Then later I found out about the Ratchet framework, so I think the potential is there.
appcache does something like this and is something that Firefox OS is pushing.
Both Android and iOS are built around promoting apps. The web is a second class citizen.
On iOS I would go as far as to say a third class citizen, since Apple are blocking the fast Javascript engine in native apps. This makes the idea of having an app as a simple web-wrapper much harder to accomplish.
But if the systems were actually optimized for open web, then content producers could build 1 web-app, that could have important logic and graphic stored offline in an app container, while still being just as functional via direct web access.
This could work great for 90% of all the apps that are basically just glorified websites.
This of course is the main mission of FirefoxOS.
Also - 'the mobile web' did not exist before the iPhone popped up. Now you have a blazing-fast mobile webkit used in Android, iOS and on more recent Blackberries, and have a quite decent mobile IE on windows phone. Each generation of mobile OS, the mobile browser performance improves massively, adding more and more features with every generation. But somehow they are blocking 'the open mobile web'?
Also - a browser is not the only 'web application'. You already have mail, RSS readers, calendar apps, twitter clients, ... in whatever form, webapp, native desktop app or mobile apps - they all exist. They're all using 'the open web'. I think inter-operability is more important than "it has to be html5". The open web is in my opinion: open API's and data format. And that is exactly what we have, a large amount of mobile apps are just a native more intelligent client for some web API or content for which a website is also available. Twitter, Facebook, Reddit apps, Kickstarter, ... all have 'native' apps - does that mean it's less open than using a web-browser? No - it's just optimized for mobile use, something that is very hard to do with pure html5. REST/JSON api's have taken over the open web. Native or web-apps are just front-ends for these api's - that's the direction it's moving in.
I don't see the problem really, web-browsing still is one of the killer apps of a mobile device - tablet or phone, and that's something neither Google, Apple, Microsoft, or any other large corporation will ever limit. Yes some apps are rejected for whatever reason, but there is competition to choose from if one of iOS, Android, Windows Phone, Firefox OS or Mobile Ubuntu makes choices in their rejections that conflict with your personal beliefs.
We've also been pushing for web app models as developers as a collective quite hard. Not so much with the mobile side of things (all got dollared eyes maybe?) We will likely see a push back into the web side of things once mobile browsers become less painful to use and more powerful in what they can do.
In other words, "decline of the mobile web", yea right. (don't forget half the article was about how we're spending more and more time in mobile web over desktop web.)
This would be better phrased as "and there are still only a few places where they do". Google Docs, for example, is great for basic collaborative editing (as long as you don't mind the NSA reading it), but has a UI that it a total pain (especially the world's worst keyboard shortcuts, e.g. having ctrl-enter and shift-enter reversed, and completely lacks advanced features.
We all started using Gmail because synchronising to a mail server is annoying and PCs where slow. Ten years later machines have a fast internet connection, 1TB HDD as standard and, maybe an SSD. When you have to wait 10 seconds just to view an attachment syncing makes a lot of sense. But generating a thumbnail of that same PDF would be much better handled pre-emptively in the cloud.
The problem is believing that one approach is better for every function of an app. Few user machines will ever have a guaranteed large amount of bandwidth. This is just as true on desktop machines as mobile, but less acknowledged.
There is still a future for for pure web apps that feel great. The framework will be released on Wednesday night.
disclaimer: I work at famous.
ServiceWorker (WIP) will do this. Its a WebWorker proxy in the browser's request/response pipeline for a particular origin, with a new cache API built on local storage.
It can process page requests and responses with similar semantics to what a WSGI/Rack/MVC controller normally does on the server. It does away with bullshit 'offline mode' divining and encourages apps to work 'offline first'. https://github.com/slightlyoff/ServiceWorker/blob/master/exp...
The polyfill is actually a node.js headless implementation, which makes this look more and more like an isomorphic controller API. https://github.com/phuu/ServiceWorker-Polyfill
Jake Archibald's talk at Chrome Dev Summit, December. https://www.youtube.com/watch?v=Z7sRMg0f5Hk
Chromium bug. https://code.google.com/p/chromium/issues/detail?id=285976
Except that anyone who actually uses the Facebook apps knows that the performance is horrible in the native apps– jerky scrolling, lots of on-demand loading requiring you to wait for multiple RTTs on every click, etc. I would be hesitant use Facebook as an argument for anything other than the need to place UI performance on equal priority with marketing.
I also don't want every mobile webpage I visit to use some slow janky JavaScript framework to emulate native app behavior either because in my experience the user experience for those are universally worse than just trying to be a relatively normal web page (perhaps with some media queries for image sizes, etc) and letting the mobile web browser do its thing.
It feels that Desktop apps are sorely neglected. Spotify for example feels really ancient, a weird UI for such a popular product. I only assume the mobile versions are more logical and easier to use. I wouldn't want to immitate the desktop versions. So I read your comment as somethnig like the immitation of Apple's cover flow. And yes in that way I agree.
Do you think it's the lack of standardisation of menuing/navigation/paging in web pages/sites that isn't helping matters?
That's why I have (and alas, need) 15 airline apps, but actually would prefer to have only two that could handle everything much better: Kayak and Apple’s Passbook.
The only app I installed on the Blackberry (my brief foray into smartphones...), was the independent app (newspaper), and I preferred accessing news through that than the website. A very simple interface that let me get to news quickly. I could even download the news up front over WIFI and then read it on the train without a data connection.
But then I don't want to have to download an app for every news outet. So you start thinking perhaps there should be a general news app and so on. One general app feels a little more managable.
But for infrequently used sites, the hassle isn't worth the benefit.
I personally love apps that are stupid simple and stupid straightforward. You know, like melon ballers: they do precisely one thing, but they do it so incredibly well, you don't understand how you got along without one before.
Melon baller apps.
Why download, upgrade, share memory space on my device for apps when I'm pretty sure I can't really trust the creators with my data anyway?
If I want to navigate on the web, I'll use a desktop. Only if I can't, and in that order, I'll try a laptop, tablet, or phone. The interface gets worse the more portable the device is, and at the phone extreme my usage is quite restricted to small apps, with few, to-the-point functionality or simple games.
If you simply must toss up one of those uber-annoying "Please install our app! PLEAAAAAAAAASE!" popovers, at least do me the courtesy of letting me look at a couple of pages on the site first. How am I supposed to know that I want your app when I haven't even seen your site?
Otherwise my answer is going to be not just "no" but "HELL, NO!"
It's difficult enough managing bookmarks. I'd feel hemmed in with apps on a smartphone, if I had to order icons, select and install applications. I don't think I could be bothered.
Having said that it has pretty much always been about the software. If I was compelled enough, I'd take the rough with the smooth.
- Users have a strong preconceived notion that websites on mobile just suck compared to native apps.
- Management allocates less financial and developer resources into mobile web because users prefer native app strongly.
- Developers time and effort are stretched thin for web because management focus more on native app teams.
The mobile web will continue to lag behind native app for a while.
This goes back to his original point , no one really has strong incentive to make mobile web performance better. The two primary gatekeepers (apple, google) are benefiting hugely from their app stores in terms of profit and pushing their agenda.
Not if mobile browsers keep up with these more sophisticated platforms. The problem (as the OP outlined) is that there are decreasing incentives people like Apple to keep improving their mobile browser. They hold the keys, and they want apps.
The problems with the mobile web are far broader than that. Being tied to JavaScript (a language whose semantics remove significant optimisation opportunities, unless you write in something else and target via asm.js), a UI layer that doesn't cleanly map to being hardware accelerated, and missing or incomplete APIs for everything from Bluetooth to push messaging.
If you look at the Chrome APIs (that is the stuff Chrome apps get access to) there is neat stuff, and they are attacking it slowly enough that what APIs they produce are sane, and this is clearly what they see as the future. The problem is the world moves faster than that, and just as the web people are beginning to even grok mobile they're going to be smacked around the head by an absolute explosion of tiny devices.
In a world where V8 exists, I'm not so sure. JS running on the main thread absolutely is a problem, and Web Workers are a clunky solution.
a UI layer that doesn't cleanly map to being hardware accelerated
Agreed this part is tricky. But existing hardware acceleration on mobile web isn't that bad.
missing or incomplete APIs for everything from Bluetooth to push messaging.
Mozilla is working on all this for Firefox OS, but of course no-one has incentive to agree with them.
Chrome is moving towards out-of-process iframes, which should help alleviate many performance issues (ads janking your page) and give you new capability (basically web workers with a full DOM). http://www.chromium.org/developers/design-documents/oop-ifra...
Mobile users are extremely demanding, in my experience. They DEFINITELY notice the difference between web & native interfaces. When mobile is accounting for huge %s of traffic and revenue, its a hard sell to settle for good-enough for philosophical issues. Particularly when the competition isn't.
And, as mobile screen sizes and 4G availability increase, it seems that it would be less of a problem running full-site versions on mobiles going forward.
Maybe more of this issue will resolve as Apple moves to larger screen sizes, but I have always had the impression that mobile-sites were a stop-gap until higher-bandwidth and larger screens became the norm. Reminds me of the short-lived WAP standard before smartphones became de rigueur.
As Joe-user, would you use a severely underpowered web app or a smooth as butter with fancy transitions native one?
As long as that is the case, the "mobile web" as the main method of creating applications will always lag behind.
I hate the "walled garden" environment that's developed around mobile apps. That said, I think native apps are superior in some cases. You can use them offline, they typically get better performance, and they are top-level, right on your home screen, rather than having to go through a browser and search for them. There are some mild other advantages like being able to have alerts and other interactions with your OS, or getting rid of the browser UI clutter entirely.
The big problem is that dipping your toes into something via a website (assuming you don't hit an auth wall) is easier than finding then downloading an app.
Besides, a lot of these "web" apps are just things like Facebook or G+ which are no more open to scraping or any of the other supposed benefits of an open web than your average iOS or Android mobile clients are. The web has morphed into an unholy mix of the worst qualities of everything else.
The web reduces the distance between content consumers and producers, cutting out the middleman. It's not a perfect solution. Standards are greatly influenced by commercial interests. But it's better than a locked-down app store oligopoly.
Users are free to use the mobile browser on their phones but most of the time native apps are a better experience. And guess who develops the framework and tools to create these value-adding native apps.
This is the free market at work.
The free market sometimes leads to a not-so-free market, which is ultimately bad for consumers. This is the entire reason there is anti-trust law.
I am not saying that there are current or even future anti-trust issues with app stores. I was simply using that analogy to illustrate that the "free market" can move in a direction that is less free to an extent that is negative for consumers. This can happen because consumers are free to choose.
In other words, that anti-trust laws exist and have been employed to combat this is simply offered as evidence that the great-grandparent post above overlooks the fact that the free market can lead to reduced choice for consumers.
Cool. And now, I'd like to introduce you to the world of ad-ridden, third-party-tracking-code infested apps.
Not to mention that apps usually have more/deeper access to your personal information.
Google could go quite far to fix this by enabling users to selectively turn off permissions, and requiring developers to handle SecurityException.
This is not a freedom problem. You have the freedom to buy an Android device, and you have the freedom to install any apk you want without ever even opening the Google app store. Moreover, Google even allows 3rd party app stores on their devices.
And of course these new players are acting as middlemen, but you are forgetting the fundamental difference, and this is what has changed the game. Anybody can publish their app, virtually for free. There are no gatekeepers, who decide what gets published and what doesn't, anymore.
Except Apple.
You can't publish any App on the Apple AppStore but only those that are kid-friendly.
You can't publish a shopping app on Apple's AppStore for free - you have to hand over all of your margin to Apple.
Apple is a gatekeeper. They decide what gets published and what doesn't.
What am I missing?
There are no gatekeepers, who decide what gets published
and what doesn't, anymore.
Apple routinely rejects applications to their App store. Have you not read any of the numerous stories where app devs get denied? This is not a freedom problem. You have the freedom to
buy an Android device, and you have the freedom to install
any apk you want without ever even opening the Google app
store.
The freedom to do something like "install any app via .apk" may exist, but it is still a "freedom problem" when there's a large barrier to installing an .apk on your device. I'm speculating of course, but real world anecdotes would lead me to believe that a very small % of the population even knows what an APK is.Yes, I am aware. And yes, you are right. But the gatekeeping on the app stores has nothing to do with the music, movie or even book industry. Could they be more lenient? Yes, but you can't denied that the game has indeed changed.
>I'm speculating of course, but real world anecdotes would lead me to believe that a very small % of the population even knows what an APK is.
I would say that you are right again. And you are also right, maybe this is a debate about freedom, but personally, I don't consider having to go to settings, security and checking a box, a large barrier to freedom. If you actually seek freedom, it's only a few (acceptable) steps away.
However, if I am starting a business, and most people don't know how to exercise that freedom to install an app from somewhere else, I am not going to get very far in my business if this is what is required for my end users to use my program. Therefore, I am not going to invest time in developing anything that requires that sort of installation, making it practically the same as not being able to do that at all.
The issue is not that people are not allowed to install apks, the problem is that people don't know how to exercise that freedom.
Standards are good because they bridge this gap. C runs on everything, e-mail runs on everything, the web runs on everything. Mobile web, for the most part, runs on everything.
edit: For the record, I do think that the mobile web standards need more work, but they're quite good at this point, and adoption is much better than 2 years ago. I'd like to see open standards for push notifications, for example (apparently there is some work done: http://www.w3.org/TR/push-api/).
Yeah, installing any apk is possible, but hard to do. Any apks and apps in the app store are a million miles from being on equal footing.
For any existng online platform that's already established itself on the web, you're probably seeing 50%+ of your traffic coming from Google and a big chunk of that will be mobile. Some of your userbase may be loyal enough to your brand to want to install your app but the rest will be lost if you don't have a decent mobile web presence.
In short: apps vs mobile web? Both
And random apps on the app store from unknown developers? I trust those even less. I may install one if the list of permissions is very restricted and reasonable. But I don't like spending time looking at the permissions and trying to figure out if it's ok.
Another example is banking apps. I remember there was news a while ago that many banking apps were not handling passwords properly. If I use the web, I can see the SSL lock icon, inspect the certificate, and know that it's properly handled. I can't do that for a native app.
Fool me once…
[0]https://play.google.com/store/apps/details?id=biz.bokhorst.x...
That doesn't look like the end of the mobile web - that just looks like people spending a lot of time gaming and on facebook.
It's a little dated now, but a Pew study found people overwhelming consume news from websites versus apps: http://www.journalism.org/2012/10/01/app-vs-browser-debate/
I also trust data from Pew considerably more than from Flurry.
Many mobile websites are broken. On a mobile phone, both websites and "mobile websites" are broken.
If anyone is looking for a money-making idea, here's a website I use all the time -
On my desktop it takes me five seconds to use. On my Android HTC One it takes me maybe five minutes to use.
If someone made an equivalent Android app, or a functional mobile web site of course I'd use it. Actually - I'm an Android programmer and could do it myself, but am busy with other things at the moment to do it singlehandedly.
That is just one web site. Many web sites I use are designed for the desktop, and work horribly on smartphones. No wonder people go running for apps when the functionality pops up in one.
- A web app/site is often an app within an app. This means that what usually works as an interface to this device is no longer true, or rather different. The gestures are different, how the app is treating them is different and so on.
- On the performance side the web apps suffer from UI delivery problem - the site must deliver both the app it self and the data for which you use this app. A native app have to work with the data only, and its not restricted to be always connected with the web.
- Another reason is that although the same on the surface mobile is actually shifting our usage patterns. Our usage is far less consistent, more spaced out, under more conditions and with smaller screens. The native apps work well here because their components are thought out to work under these conditions and of course tested for this.
- Finally because of the usage patterns we see some native apps more versed to cover specific use cases. This differs from the mobile web which just have everything the normal web has, but tested to work on mobile.
Some of this points of course can be tackled by html5 wrapped web apps. But this approach comes with own set of limitations and problems - we are compromising on both openness and performance sides. So while I want the mobile web to work, for now I think that native apps are winning.
The problem isn't the web, it's how many web developers choose to use it. If you want to really know how powerful the web is, check out many of the WebGL demos and game demos out there...
When the vast majority of simple websites (not even applications) have terrible experiences on mobile web browsers, is it really any surprise that users prefer using an app that at least puts effort into being usable?
HN and at least 80% of the linked articles I read on my commute have terrible mobile interfaces.
I really don't see the "performance" argument. It's unlikely anything you build natively is going to compete with a browser's raw HTML/CSS performance. That's something they do incredibly well. And really, that's all a static blog needs to be. I don't need your comments. I don't need your ads. I don't need your HTTPS. I don't need your massively broken up application that requires a GET for every asset on the page (and the 20+ JS files you've decided not to package together, none of which is needed). I don't need your parallax effects, your hover/click listeners, your scroll events, your damn lightboxes, or your image rotators.
At the end of the day, I don't use the mobile web very much. It's not because mobile web sucks. It's because nearly everything on the mobile web sucks.
Complex web pages are a pain to maintain. They're a huge liability, really. And there's really no need for them to be so complex.
The only reason I can see is people who have little understanding of how web pages are constructed are usually the ones in charge of designing them.
... Maybe I should transition over to web design.
Apps predated this model in more or less the same form we currently find them, with monetization inherent in the distribution model.
If native apps are dominating web pages in some medium e.g. portables and wearables, maybe that means the audience of that medium isn't inclined to create links or author documents, so isn't well served by the web model there. Specialized apps will tend to serve their specific needs better, especially if they can be monetized easily.
There will always be a place for the web, and for the dedicated app. "Web apps" were and are a bit of a hack, although often a very useful one. Creativity can be channeled into all of these media, and the barriers to entry are lowering for all of them. It's a great time to be online. As long as IP remains ubiquitous, I imagine there will always be a market outside of the AOLs, Apple Stores, Google Stores etc.
[0] http://coding2learn.org/blog/2013/07/29/kids-cant-use-comput...
There is a wide overlap in functionality, but if the experience via mobile browser is sufficient, users won't care. They may even enjoy not having to curate yet another app.
App Pros: Engagement lock-in Richer experiences (performance, native advantages)
App Cons: Dev costs Fragmentation costs Dependency on ecosystem(s) App release cycle + cross platform synchro of dev efforts
The Web also bears the burden of having grown up in the desktop keyboard and mouse environment. It's going to be at least as hard to touchify the Web as it is to touchify Windows.
Mobile website, infact normal websites are large, clunky and not designed for fingers, or high latency.
However, one thing is not true in what he says:
> Apps have a rich-get-richer dynamic
Yes, indeed, but so do websites; portalisation, or more simply the shear number of sites people visit spontaneously is not less than the number of apps they use regularly: three to five versus a dozen. There is a problem at the lower end of that spectrum: while the sites big enough overall to make an be maintained it are actually more common than apps that can do the same, users tend to spend an almost exclusive share their time in said ten-to-fifteen apps, and that challenges discoverability, i.e. the renewal of that class. That’s where the issue is, not in how many apps cover 80% of usage, or how many first letters people type before their browser auto-complete the rest.
(On that, I wonder how much the lack of success of Readability has to do with starting with the same letter as Reddit)
Would this still be the case if Web development wasn't a broken matrix of browser and OS versions powered by a language which people are constantly trying to paper over with abstractions? (Seriously, it's like a person you'd only have sex with as long as you'd put a paper bag over their head.)
But that's the whole point of the web. If it was broken into 2 platforms, each fully controlled by a company, we would see quicker innovation. But then we'd have all the drawbacks of apps, so what's the point?
Huh, is that surprising? They break their mobile sites and expect people to still use them more than apps? This is self fulfulling: if you make a sucky website, people will NOT use it. Make a wonderful mobile site and people will not care about your apps.
One reason could be that their stats don't include mobile web usage within apps (i.e. FB / Twitter). That discounts a lot of my own browsing behavior.
As always, look at the data for your own website/service before deciding which path to take.
(It's erroring out in production.)
http://webcache.googleusercontent.com/search?q=cache:www.cdi...
Anyone got the numbers for that?
Also this might be a stupid question but are Safari and Chrome considered apps in this context? I.e. do they count as app usages or web usage?
And text:
People are spending more time on mobile vs desktop:
And more of their mobile time using apps, not the web:
This is a worrisome trend for the web. Mobile is the future. What wins mobile, wins the Internet. Right now, apps are winning and the web is losing.
Moreover, there are signs that it will only get worse. Ask any web company and they will tell you that they value app users more than web users. This is why you see so many popups and banners on mobile websites that try to get you to download apps. It is also why so many mobile websites are broken. Resources are going to app development over web development. As the mobile web UX further deteriorates, the momentum toward apps will only increase.
The likely end state is the web becomes a niche product used for things like 1) trying a service before you download the app, 2) consuming long tail content (e.g. link to a niche blog from Twitter or Facebook feed).
This will hurt long-term innovation from a number of reasons:
1) Apps have a rich-get-richer dynamic that favors the status quo over new innovations. Popular apps get home screen placement, get used more, get ranked higher in app stores, make more money, can pay more for distribution, etc. The end state will probably be like cable TV – a few dominant channels/apps that sit on users’ home screens and everything else relegated to lower tiers or irrelevance.
2) Apps are heavily controlled by the dominant app stores owners, Apple and Google. Google and Apple control what apps are allowed to exist, how apps are built, what apps get promoted, and charge a 30% tax on revenues.
Most worrisome: they reject entire classes of apps without stated reasons or allowing for recourse (e.g. Apple has rejected all apps related to Bitcoin). The open architecture of the web led to an incredible era of experimentation. Many startups are controversial when they are first founded. What if AOL or some other central gatekeeper had controlled the web, and developers had to ask permission to create Google, Youtube, eBay, Paypal, Wikipedia, Twitter, Facebook, etc. Sadly, this is where we’re headed on mobile.
In general, I agree with the sentiment that the mobile web is only now getting it's feet under it. My main concern is that Apple/Google prefer app improvements over improving their browsers.
That said. Information can mean many things. And there will be hybrids.
You can do offline apps in HTML+CSS+JS right now, but it's a PITA:
var a = document.createElement("a");
a.appendChild(document.createTextNode("hacker news");
a.setAttribute("href", "https://news.ycombinator.com/");
If your app contains information, it's best suited for the www. But if it only contains a canvas, it's more suited as a native app.
That being said, I think the more time in apps vs mobile web might be a bit misleading. How many apps out there have webviews taking you to the web for various reasons? I can only imagine this time is counted as app time for the graph in the article, but it's really web time for all intents and purposes.
And frankly, I think that this is a much better user experience in a lot of ways. the facebook native app is much better than the web version is and even really could be (at least at this point). Much of what happens in that app though is clicking on websites to random articles around the web, and that is done in a webview inside the app. I like the app over the website, and i definitely don't want it to kick me out to safari while I'm in the app. This is a good ux, but I think it skews the data in this article. How many other apps have similar functionality?
All that being said, I strongly prefer the experience of native apps over the web, but I'm only interested in using the app if it's something I'm going to use all the time. If I need your site 1 time ever, I'm not wasting time downloading the app. If I use it every day, I absolutely would rather have an app. For everyone saying "Hell no I don't want your app", I suspect the above is actually true for a significant majority of people. 1 time use people don't want app. Repeated use people do want app.
But we've seen this pattern multiple times over the past 15+ years, the open web by its very nature needs time to catch up.
It doesn't mean that the current state of affairs is final.
It took the open web over a decade to start making proprietary "rich media" solutions like Flash obsolete. These things take time.
Open web will never be at the lead of innovation, it just provides the foundation for it. Also, most mobile apps still use the web to be networked. The browser is not the web.
I mean, I guess if you have FU money, don't work for the man, and travel to wherever you want with WiFi, sure, you probably spend more time poking with apps than you do in a desktop.
Lack a stable Internet connection? Native wins
Home screen apps vs Bookmarks in browser? Native wins
Ease of discovery? Native wins
Ideal user experience? Native wins
Mobile web is lagging behind for good reason.
HTML5 offline storage should let a mobile-oriented site store a fair bit of data offline, to avoid having to go out and fetch everything anew all the time. It's just that few web developers design that way b/c we've all been spoiled by desktop users' broadband connections.
> Home screen apps vs Bookmarks in browser? Native wins
My Galaxy S3 lets me set bookmarks for sites on the home screen (and anywhere else in the launcher I would wish to).
> Ease of discovery? Native wins
Slogging through ten million clones in an app store counts as easy discovery? OK.
> Ideal user experience? Native wins
I'm not sure about that. We heard the same noise during the 2000s about how users were going to prefer "rich client" apps to in-browser apps, because the rich client apps would be able to respect their platform's native look and feel. And then it turned out that "I can access it from anywhere without installing anything" was something they cared about a lot more.
But there is certainly a bubble in the app space which will bust sooner or later. Not sure what will be the next big thing though. Web does not seem like a candidate.
Also, I don't goto the web for anything I would do with an app generally speaking. Camera, calendars.
The device makers don't have a huge incentive to improve web browsers either, they have a store in which they want to take a piece of your earnings.
If the open web were to be redefined along those lines, I dont see why users wont use that.
Someone might spend way more time in Facebook.app than Safari.app, but within that, they might spend most of their time on pages linked to from their Facebook feed.
And Apple, at least, is keeping things that way on purpose. Consider this dig at Google by the master himself, Steve Jobs — a few years ago:
https://www.youtube.com/watch?v=CWd-xXfIEpE
He was saying “for some reason” but really the reasons for choosing apps over web are enabled largely by these platforms themselves. Because they are more locked-down, they won’t allow too much integration, and it’s harder to get web apps to catch on.
That said, three years ago I really became passionate about the problem of decentralizing the consumer internet again. We can see with git and other tools how distributed workflows are better in many ways than centralized ones. The internet was originally designed to be decentralized, with no single point of failure, but there’s a strong tendency for services to crop up and use network effects to amass lots of users. VC firms have a thesis to invest in such companies. While this is true, the future is in distributed computing, like WordPress for blogs or Git for version control.
Shameless plug: Qbix (my company) has been hard at work the last 3 years building an open, web-based platform that takes advantage of PhoneGap (Cordova) and emerging containers like MacGap and now WinJS! Write once, deploy anywhere, as a social app with contacts / roles / permissions / notifications / etc. working across all devices and integrated. So developers can focus on building the app and get best practices for virality and engagement (without annoying people) out of the box.
http://qbix.com/blog/index.php/2013/04/a-new-kind-of-platfor...
my 2c
And here we are, with Silicon Valley as the gate-keeper instead.
"Web applications on the desktop are way ahead of where they used to be. In a few years, it'll be the same for mobile web apps... they'll catch up to the native performance."
But this always seems to overlook another question...
"Where will native desktop and mobile apps be in a few years?"
I have no doubt that mobile web apps will catch up to the performance of CURRENT native apps. However, I absolutely doubt they'll be up to par with the native standard of their time. Web apps progress, but so do native. Worse of all (best of all?) it puts users into the habit and comfort of native and makes the standard for web increase.
Apps have an enormous advantage when it comes to acces to the device like photos, camera, address book and notifications.
[an error occurred while processing this directive]Good: It might stop the rot of websites turning their whole site into a mobile version with fat-finger buttons and massive text, if websites become the means of interacting for people with real computers again.
Bad: Apps are a far bigger security risk, and prevent casual interaction (i.e. following a link onto something, then going somewhere else) - having an app means you're in a selfcontained site and are kept there until you close the app and open another.
It will probably be based on cards as the unit of interaction.
However, on the flip side as wearable tech becomes more and more prevalent (think Google Glass, but also things like Jawbone), it make a lot of sense that more and more of our internet usage goes via these interfaces which are inherently non-web.
Information displayed needs to be understandable at a glance and relevant to the very here and now. Usable real estate is extremely limited in glass and interaction is limited to voice, simple gestures against the right frame, and GPS/accelerometer. So doing interaction with any amount of complexity gets frustrating and annoying very quickly.
I click on links that open up a UIWebView and read articles on the web.
Does that count as one hour in an "app"? In reality, it's more like 20% in the app and 80% following shared web links.
I don't see why we have to put our users through the web, just because its easy for us to develop or deliver for it.
Consumers have taken to apps like never before. Asking them to regress is stupidity. Take the simplest case of loss of internet connection. Browsers and browser apps continue to be terrible when your million dollar "UX" is replaced with an irresponsible "Page cannot be displayed" and no concept of offline experience.
Fuck browsers and mobile web. Please let's not go back.
Web - interconnections, links.
You don't get that with apps.
To provide a state of the art user experience on mobile devices, you need to write an app.
The issue is that apps are diverting attention - otherwise mobile browsers might have implemented push notifications for pages by now. Firefox OS does it, and Safari on desktop has notifications. It's close, but no-one is shouting at the manufacturers to push it over the line.
one example.
Flowdock has a great web site that works great on mobile. Their Android app used to be a stinking POS. They then rewrote it to replace the Web View with native to get a different POS. If browsers just supported notifications I could use their web site rather than their app POS.
While native has had roughly seven years lead when it comes to providing quality online experience, web apps can beat native easily. And no it's not that web apps or web development or talent for mobile web development is limited or is the bottleneck.
The bottleneck is usually the vendors and support of standards in the existing breed of mobile browsers that destroy the web experience.
For example, Apple introduced this shitty non-standard swipe gesture feature on iPhone Safari/iOS7 that breaks so many things:
http://stackoverflow.com/questions/18889666/ios-7-is-there-a...
But I think this will change with more competition among tablets and mobiles. IMHO, it is normal for the web to catch up a little later; but when it does native will find it hard to breath.
If you think Android and iOS are "done", consider where they are headed and you can see they are barely getting started. Consider input such as speed, physical gestures, breathing, brain activity. All manner of form factors. Integration with the "real world" such as Nest and Square. Wearables, cars, home appliances ...
Whatever early-stage web APIs exist for these things are vastly, tragically, fragmented across the various HTML5 runtimes.
The "other web", that of HTTP and REST and JSON and cloud services, is a freaking wonder of engineering and a giant productivity boost to developers of any client. But the UI side of the web is continuing to trail for now. Competition among tablets and mobiles will help native apps as much as it will help the web.
I agree with you that the competition will push either sides forward, but by how much at each end? - that is the question.
> as soon as 'UI side of the web' stops trailing too far
Except not likely it ever will.There has been serious improvement in many areas of mobile web/browser support in the last 12 odd months; for what I've seen. Thanks to Android, Chrome, Firefox and Dolphin.
I'm sorry, but there are only so many ways you can display a CRUD application. I don't see the next versions of Twitter and Instagram pushing the hardware much more than they are today..
Twitter and Instagram as photo-heavy apps could eventually support 3D models of the world, drone photography, wearables etc (Twitter already has a Glass app).
Same for their notifications - all sorts are possible on watches, speech, car dashboards.
And that's just assuming they stand still functionally.
As for CRUD apps, there's loads of innovation happening. Look at Amazon's new Dash device as one of many examples that change the interaction style from clicking on a web page to speech + real-world scanning. I'm guessing it's not powered by HTML5.
When it comes to mobile, I think we are in the "web exists and the tools are almost good enough but the networks suck" phase. When the mobile networks get fast enough, I suspect most applications will just be websites. Of course there will always be some applications that are built for native because of performance or they have some fancy touch-based interaction.
> While native has had roughly seven years lead
Nope, it has not. Remember, web apps were first on iPhone, before native third party apps. And that's not to mention "common" web.Also, the roots of HTML5 go back to 2004 when whatwg was formed.
> when it comes to providing quality online experience, > web apps can beat native easily.
You have no idea what you are talking about. Anyone speaking this: please, find a time and get familiar with native SDKs. You absolutely have no clue how far far far behind web tech for apps is. Just do not forget that being capable to do something does not imply that this capability if pleasant to work with, performant enough, or at all useable. I lost my hope that web-tech-for-mobile will ever go past "which mvc framework to use" stage.
1. Pleasant to work with, 2. Performant enough, 3. Butter smooth usability
... with HTML5 and decent browser support (and significant effort of front-end developers no doubt) without having to download an app on your mobile. Native SDKs are important, I agree with you, but future isn't in them.
If you want to do anything that harnesses the hardware or computing capability of the device, or anything more complicated the most basic HTML-based UI, then native apps are the way to go. This is independent of whether we're talking about mobile or desktop.