Hacker News Reader

Comment by readams | Hacker News Reader

The correct answer here is ... web apps. They're just better than chat bots. The only real issue is an easy way to link identity and payment information into the interactions. These chat bot guys always claim their main advantage is not having to install apps. The web browser is already there and installed.

View on HN

A superficially obvious idea, but it misses the point of the article. Web apps solve almost none of the problems mentioned in the article, and the introduce some of their own.

They don't solve any of the deep inter-app and cross-app integrations Dan talks about, except discoverability. They arguably solve sharing, but that's very questionable when your only form of "sharing" is copy/paste, which is not as easy as tapping on buttons on mobile. They don't solve the problem of keeping track of apps (at best - if a user adds web pages to their home screen, they are no worse than normal mobile apps). They revert everything back to a pull-based model, when what Dan is suggesting is an organized push-based model (as opposed to the push notification chaos today). And so on...

And then web apps introduce massive (in relative terms) latency / load times, which is a whole other can of worms, which is even worse than downloading multiple mobile apps. Yeah, you can talk about <foo> initiative to speed up web apps, but the fact is, nobody can really enforce those things.

Actually, I think web apps could do it. Some browser could just add a ton of proprietary JS APIs for notification, payment, identity, etc, in the same way that WeChat and Kik have.

The Chinese web browsers are beginning to bolt on features in the same way the chat apps have. News, offline file storage, ebook stores with offline support, etc.

Chrome almost had the right idea, but their app store makes no distinction between web-based apps that actually make use of Chrome's app-specific APIs and those that are just normal websites. There is no standard for a good experience from a Chrome app.

No reason Chrome/UC Browser/Brave/Opera in the west couldn't throw caution to the wind and rachet it up all the way, then wait a few years for WC3 to come along and pick up the pieces.

Result wouldn't be as good as if the OS and web standards properly evolved, but it's one way to make it happen.

I was about to add that web apps could fix all those with more browser features, but somehow I don't think every web browser vendor implementing their own proprietary payment/share/identity API is what readams had in mind (they are certainly not going to agree on a standard any time within the next 5 years).

Google wroked/works on protocol called "the physical web " for a version of the web that is more push-based, fitting smart objects around you:

https://google.github.io/physical-web/

This makes me wonder why federated login via Facebook doesn't meet this need. It works quite well, but perhaps the OAuth confirmation scares people off (or they are worried the requestor will access data they don't wish to share, post on their behalf, etc.)

There is something really compelling about the totally-seamless experience, but do I as a user actually want that? I suppose it depends on my trust in the platform holder.

There are two problems with Facebook's federated login.

For one: Facebook doesn't need to know everything. While some are more peculiar about privacy than others, when information is used across boundaries that exist in our physical world, users start to care. I don't want to login for work-related sites or apps with my Facebook account and I'm sure most wouldn't login to a porn site with their Facebook account either.

Second problem is that the whole idea of federated login is that there are many providers who implement the same protocol, meaning whatever account I have, I can authenticate myself. Only implementing Facebook defeats the purpose of federated.

As someone who doesn't use Facebook, sites that offer only federated login via Facebook are worthless.

I have recently implemented the revamped Google Login in an Android app. IMO this is an awesome user experience ... as long as you are ok with Google handling your credentials. Since you are using an Android phone with Play Services, you are supposed to be ok with that though ..

Something like Persona might have been a better solution, but in the meantime this is by far the best login solution on Android.

I have not been able to test Facebook in perfect conditions (I don't want the app on my phone) but having to go through a webview is pretty annoying, and brings a ton of security issues.

It'll be interesting if the rumors of Apple Pay for web are correct[1]. One could see a near future where using mobile Safari, iPhone users could login and pay at any website just with the credentials stored in Apple Pay + Keychain and the use of their thumbs. I'm sure something similar could be built for Chrome on Android with Android Pay.

1) http://recode.net/2016/03/23/apple-pay-coming-to-mobile-webs...

I'd much rather see a web standard not tied to Apple or Google but I think you're right that we're not going to get it.

I agree! I so much prefer rich web apps on mobile rather than native apps! When my Android phone gets an update for finer grain persion settings for apps I might soften this position, but not by much.

Kik attempts to solve this with an embedded browser and SDK. If you click a link in Kik it takes you to its own browser, which has various Kik specific JavaScript available.

This is one of the things that WeChat provides. When I hail a car from within the WeChat app, the UI I'm using is a web app provided by the car hailing platform. It's rendered within the WeChat window, and can access my personal info and WeChat payment.

The future that the parent to your comment described is already here.

Reply on news.ycombinator.com