Hacker News new | past | comments | ask | show | jobs | submit login
Google, Mozilla Team Up to Create a Smarter, Action-Based Web (webmonkey.com)
73 points by mmahemoff on Aug 9, 2011 | hide | past | favorite | 14 comments



I love intents on android, its a really method of inter app communication.

I havent spent a lot of time thinking about security implications, but would this work as an ultra easy mechanism for integrating payment solutions?, just send off a "payme" intent and get back a confirmation of payment


That browsers will mediate the cross-app communications is a great step towards capabilities-based security and a safer web.

Also, it seems like a natural feature for jmiller's Locker Project.


Open Web Apps is great for a number of reasons:

- enables sites to push a set of apps, either built inhouse or by third parties

- users don't have to focus on an acquisition point such as the chrome web store

- built straight into the browser as a launch point unlike the JVM or Adobe Air, and should benefit performance and compatibility

- user can have a set of bookmarks as usual, and then a set of appmarks

- will apps and APIs be neglected over time versus how an underlying site evolves? Will apps auto-update?


As a small developer, this sounds really cool, but I wonder how much incentive they can create for large sites, especially walled-garden types like facebook.


It depends on which side. Walled gardens will still want to be in the game, so they'll be motivated to provide actions.

They might balk at pointing users to external actions, but even walled gardens can only provide a limited set of services. e.g. Facebook and Twitter don't provide services to edit/enhance photos, they could palm that off to services like Picnik in a Web Intents universe.


A walled-garden like Facebook may eventually expose actions themselves, after it's clear that web intents are prevalent enough that they finally acquiesce in lieu of their own proprietary embed scripts, but I can't see them integrating willingly with a lot of external services.

Sites like that tend to try to provide seamless experiences, and keep you on their web properties. I would bet Facebook would rather acquire or build a photo editor than to simply plug in a web intent and let you choose. Will be interesting to see how this plays out either way, since the idea is something developers have long wanted and this seems like a good implementation of it.

Google+ is another story, and Web Intents comes from inside the giant too, so all the more reason to support it.


For sure. The Open ID versus Facebook Connect experience shows the risks ahead for Web Intents - any new layer of abstraction will add extra complexity. The architects need to be sure there are enough benefits to justify it, and as little extra complexity as possible.

Fortunately, there's a lot of attention being paid early on to both user experience and developer experience of web intents. And there are definitely visible benefits to users if it's presented in the right way.


This looks like a cool geek thing but sounds like it has the potential to be a user-interface nightmare.

"You have no application configured for removing red-eye. Please select a photo editor for removing red eye from these 1000 choices."

For everything I might want to do?

Eventually they'll have to pick sane defaults from the most popular choices and at that point it seems like we're back to where we are now.

Either that, or it's a security/privacy nightmare. I don't want any site sending photos (for example) anywhere I haven't explicitly given access to, every time. I don't consider myself overly paranoid, either.

I do assume that Facebook does have some level of privacy controls in place; it would seem to make this desirable for a user you'd have to defeat those controls without asking.


"You have no application configured for removing red-eye. Please select a photo editor for removing red eye from these 1000 choices."

Isn't that better than just not displaying the possibility for removing red eye? Also, if you don't like the choices, you can do as you normally would and navigate to a website that removes red eye (or use desktop software).

I'm sure there will be privacy concerns, but "nightmares"? really? They'll just make it so that no data is sent unless you explicitly give it access. That doesn't sound like a nightmare.

Where you see all these "nightmares", I just see engineering problems that they're trying to solve, as with every new inventive piece of software.


Seems pretty easy to solve extrapolating current trends:

You have no app installed for action X. Would you like to go to the [Mozilla|Chrome] action app store for options?

In the Action App Store:

Below are the top N action apps supporting X, ranked by [popularity|featured|rating|price]. All apps in the [Mozilla|Chrome] app store come from verified providers who follow the XYZ privacy policy.

Most common packages of functionality would quickly be covered by roll-up apps, but around the fringes – where new capabilities emerge – there'd be openings for new entrants.

(In fact, the implied functionality/market model reminds me a bit of two old dreams of the software future:

• the 'Superdistribution' concept of Objective-C-creator Brad Cox

• the composite-document approach of Apple's early-90s OpenDoc initiative

Each saw future software being an assemblage of capabilities from many sources, enabling a richer provider ecosystem.)


That is not extrapolating. Mac OS X Lion already implements it for applications.

If you double-click a file named "test.hn", the Finder gives you the option to cancel opening, to choose an application, or to search the Mac App Store.

It turns out you can do searches like "extension:hn" or "uti:com.adobe.pdf" in the app store application.

(and yes, when reading about is, I thought of OpenDoc, too. I guess this scheme may fail for the same reason OpenDoc failed, that is: because engrained parties have no interest in making it easier for their customers to move elsewhere)


there goes the big secret plan of locking Chrome, Mozilla, Safari, and IE dev teams in a small room until they start making our web developer lives easier...


Wasn't this what SOAP was supposed to provide?


Aside from the gratuitous complexity of SOAP, it was a pure message protocol. This is a web standard involving user-interface components.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: