Comment by ollysb | Hacker News Reader

Comment by ollysb | Hacker News Reader

This feels like an engineers vision of the web. The two benefits of this over apis are:

1) The user gets to choose how to perform a particular activity.

2) Services can be found either automatically or by the user searching for services and saving them for later.

Don't the majority of users want this taken care of for them? Imagine going to facebook and having to find a service to perform a friend request. That's just an irritation for a benefit that most people don't want(wow I can send an invite using SMS with this service).

It's also notable that there's no styling on the examples. How is the UI going to be integrated, are all of the web intents supposed to follow a standard CSS format? How about the amount of space that service takes up on the page?

I suspect apis are popular because they're the best fit for sharing functionality on the web. Users want curated, integrated websites, not a set of mix 'n' match components.

I'm pretty sure this can be implemented without forcing the user to make any choices they wouldn't have to make anyway. For actions like share and pick, the user will want to choose which service to use. For view and edit, they may not care, so there should be a default choice, either by the user or the originating site.

Try thinking of it in terms of Android intents/activities. The vast majority of the time, it's handled automatically for you (where "it" is whatever you were trying to do), but when you want the option to choose, it's there.

In some cases (e.g., sharing) it's clear that there's never a single good option -- the choice should probably always exist. There are plenty of others (e.g., image editing) where a site might want to have a specific default, but allow for choice where appropriate.

The alternative, I'm afraid, is what we have now -- you only get the options (usually just one) that an app's developer happened to find time to integrate by hand, usually poorly.

I completely agree. There is only one good use case for the Web Intents API: sharing. But sharing should have a simple non-generic HTML tag and JS API just for that.

There's no other purpose for this unnecessarily generic API.

hmmm - whilst sharing is defiantly one of the first and easiest use-cases to envisage, there are a whole host of other API's that will be built on this including registration for authentication (via OpenID - only present the services the user uses), cloud-based file pickers, print, send, bookmark, and in the future a lot of system generated events.

The point isn't that this is an unnecessarily generic API - it is not, it is like saying postMessage is a unnecessarily generic API, rather it is firstly a service discovery mechanism and simple communication channel.

Reply on news.ycombinator.com