The combinations of web intents and Google's GDrive implementation / Dropbox seem interesting. I could link a file with a web intent, you use your Chrome App or similar to edit it, save it back to your Dropbox / drive - then your editor makes you another link which you can share with others to start the process over again.

When you think about it this seems to align well with the original philosophies of the web. Exciting times.

The key is that it decouples the services, we won't have to wait for service x to implement the api of service y. Instead you just say implement this intent and then boom you can use any service that supports that intent.

This is huge for web apps, and is a huge blow for local file system fans.

So what if I have 5 apps that can edit the file type. Do I have to choose which app I want to use, every time? That is the way it works on Android, and it is bad UX.

It depends. The UI in Chrome doesn't yet have a defaulting mechanism, but the intention is to have this so that you can set your preferred app to use and have it work seamlessly.

Defaulting is not enough. It has to be easy to switch to another. On my Android phone I have 5 web browsers installed. If I add a bookmark to the homescreen it asks me which web browser I want to use to open it. Every time I click on it.

I could, as you suggest, set a default, but if I do that then that browser owns all of my links and the only way to change it is to hunt down the setting to disable the default (which is buried in the settings UI I suppose).

So I live with the (extreme annoyance) of clicking on a link within the browser that then prompts me which browser I'd like to use to open it.

Getting the UX right on this is by far the most important part of the project.

This is a problem every major desktop OS solved years ago, by making the settings in a convenient and readily-accessible place, both for one-time overrides and changing the defaults (right-click -> Open With or similar). Hopefully the folks implementing this come up with something similarly usable.

No offense but your an edge case. Most users will have only 1 main browser they use.

Well Google itself ships two browsers-- Browser and Chrome, and Chrome is default almost nowhere, so it is an issue for almost every Google target user.

I too agree with this. Though web intents is really good and necessity for web but UX, by far, is the key for this. Just on the side note - there will be lots of other services (like translate etc) which would be intentified, and anything other than providing in-line UX will kill intuitiveness.

I don't think we disagree with the need for a strong user experience, and this will happen over time as everyone learns how users, developers and publishers use the system.

We do have an inline disposition, but it is not as in-page inline as I think you are suggesting, and even then it is up to the service how it chooses to be opened.

> and this will happen over time as everyone learns how users, developers and publishers use the system.

That right there says to me that UX is not the focus and it absolutely should be. Don't ship a feature that you haven't figured out the UX for.

UX is the focus, however we will still learn what happens as more users use it.

I'm annoyed by the exact same thing. Chrome Beta is good, but it is still a beta. For some sites, I've found the built-in browser to be better. A proper UX solution, in my opinion, would be using a 3-4 seconds dialog ("Opening with Chrome") with a Change button. That way, you can change the default app at the moment you notice it. Of course, it comes with a delay, so it wouldn't work well for others.

A 3-4 second delay on every app launch? No way.

Replacing the currently indefinite delay with a 3-4 second one sounds like an improvement.

That only works if you launch the wrong app every time. Extremely unlikely.

I'd rather see a long tap bring up options related to a shortcut.

It's less discoverable than a delay, but it is also far less annoying in the common case.

> On my Android phone I have 5 web browsers installed.

For what percentage of users is this likely to be a concern?

I get that popup whenever a file can be handled by multiple apps (youtube links: browser or native app, images: browser or some editor/viewer, etc.).

It happens occasionally to me and I'm not a smartphone "power user".

I would think that for a set of common intents, most users have more than 1 app that can handle it. It is bad UX to ask every time, and it's also bad UX to force them to choose 1 forever. I don't know what the solution is.

This is why I can't wait for more integrated speech/command based interfaces. It is great for infrequently used commands: "change this icon to open with safari." Only someone highly experienced with the details of a UI are going to be able to change settings faster than they can say them.

Surely this depends on the browser, rather than the mechanism in HTML itself?

I would imagine this would work somewhat similarly to Android, so you get a list of intent providers you have, and a way to make one the default:

http://android-er.blogspot.de/2011/03/pick-file-using-intent...

It's not only the intention, code is being written as we speak :)

It's so much worse in iOS- to share a picture on Facebook you need to close the camera, open up FB, then find the file and upload it.

After switching from Android to an iPhone, I miss the powerful User Experience that Android provides.

This is one of the use-cases I am pushing.

I really want Web Intents to take off. It's like assigning programs to certain file extensions, but instead assigning intents to web services. So you could take a photo, edit the image, and share it to your social network of choice. The websites would use a common API, they don't need to program exceptions for each-other like we do with iOS apps. Android does it a lot better, but this could really work on the web.

Hopefully Google and Mozilla will put enough resources behind this that it becomes standardized on, and maybe even Microsoft will get on board.

Apple, well, probably not.

Not sure why the Apple punch was necessary? You do see that this is a commit on WebKit, right?

Well they still haven't enabled HTML form file upload which makes uploading through a web app difficult if not impossible.

This discussion isn't wholly centered on mobile though - the OP mentions Mozzila, Msft, Google and Apple - I think we're equally talking desktop browsers.

And while I agree that file upload is a major, glaring omission and a constant source of pain, I still hope it's not permanent.

The difference between desktop and mobile is arbitrary. A cell phone is a very small computer that also has specialized hardware for making phone calls (which my laptop also has). Yes there may be some considerations for space and workflow on different devices but RFC 1867 has been around for almost 20 years. Its not something new and revolutionary, its something that most people expect to do from within a browser.

at some point powerful webapps disrupt the app store market

I'm missing the conclusion to that sentence. During 2011, the app store generated $3.4bn in revenue. Given Apples 30% cut, they'd see about $1bn revenue there, out of a total revenue of $108bn in fiscal 2011 [2]. That makes the app store about ~0.95% of Apples total revenue, compared to iPhone hardware sales, generating $47bn or 43% of Apples total revenue [3]. Now, you might argue that the app store accounts for some percent in that in that people buy iPhones to be able to play Angry Birds and whatnot, but from what I can tell, the most popular apps on iPhone are equally available on Android [4]. Pair this with the fact that iOS Safari seems to be the most capable mobile browser out there (or at the very least, in the top 2) [5] and I'm saying there's no published reason Apple would fight web intents or more powerful web apps in general.

Of course, I'm open to other interpretations.

[1] http://www.wired.com/gadgetlab/2011/12/ios-revenues-vs-andro...

[2] http://www.apple.com/pr/library/2011/10/18Apple-Reports-Four...

[3] http://files.shareholder.com/downloads/AAPL/1856667914x0xS11...

[4] http://www.pcworld.com/article/226531/apples_popular_apps_no...

[5] http://www.quirksmode.org/mobile/

App store apps give Apple lock-in to the iOS platform. Even if an app is available for Android, I would need to buy it again, which means I have friction to switch platforms. If everything is a web app, I can switch at will.

There are two big obstacles I see for web apps to take over:

* Poor interoperability between apps (solved by WebIntents)

* Monetization (though services like GitHub and Flickr do this well, and there are providers like http://chargify.com/ to make it easy for developers)

It's not the app revenue, it's the locked content stream. Open web apps would be able to sell content directly, as they never signed the app store contract. Long term Apple's growth model requires content sales. Hardware sales only grew 7% over last year if I remember their filing correctly.

Actually I think you're about a factor 10 off there, hardware sales FY11 was $99bn, compared to $57bn in FY10, which is a growth year over year of about 72%, while content saw growth of about 28% from $4.9bn to $6.3bn. As for total impact on revenue, hardware sales made up 91% of total revenue in '11, compared to 88% in '10.

Similar or related initiatives:

Mozilla web apps / web activities: https://people.mozilla.com/~anarayanan/webapps.html

http://blog.mozilla.org/labs/2011/07/web-apps-update-experim...

A overview of currently envisioned use cases: http://usecases.webintents.org/

Activity base schema (IBM, SAY, Facebook, Six Apart, Google, Microsoft, MySpace): http://activitystrea.ms/head/activity-schema.html

Web intents at w3c: http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview...

more info: http://webintents.org/

Web Intents is a framework for client-side service discovery and inter-application communication. Services register their intention to be able to handle an action on the user's behalf.

This could be a good push for interoperability, but it is more likely to end up being another vector for inadvertent data disclosure as the majority of people just click "Yes" when asked for permission.

This is not a background process but a way for a user to actively share data between web apps - it's a "push" action the user must instigate, not a "pull" from the third-party wanting access to the data. There is no more "inadvertent data disclosure" than when someone knowingly tweets a link to a file in their public dropbox, or uploads an image to Facebook.

At the moment there is a specific prompt for the user to choose the app that they want to use when an action is invoked.

Interesting that the JavaScript interface is very similar to Android's own intents. From the example in the spec:

  var intent = new Intent("http://webintents.org/edit",
                          "text/uri-list;type=image/jpeg",
                          getImageDataURI(...));
  navigator.startActivity(intent, imageEdited);

http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview...

You'll notice that all of the editors are Googlers.

There is also a lot of active contribution from a lot of other people and companies too on the list http://lists.w3.org/Archives/Public/public-web-intents/

Great explanation here for those of us who didnt quite understand at first

http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview...

What are the security concerns?

Hmm, why not just add an action attribute to the anchor tag?

    <a href="image.png" action="edit">
    <a href="myblog.feed" action="subscribe">
    <a href="rickroll.vid" action="view" target="_blank">

Or just make it easier for the user to register protocols in the browser like:

    <a href="edit:mycat.png">
    <a href="subscribe:myblog.feed">
    <a href="view:rickroll.vid" target="_blank">

Browser vendors get together and implement some basic protocols and a simple UI to change them.

Because protocols are not actions and also what your describe provides no way for return data to be handled. Likewise for pulling in data in to your app.

Note though that this is something we also considering, we will be bringing in RPH and RCH into the intent declaration.

The intent tag is about the declaration of abilities that your app has so in your model this would also be possible.

Ok, how about using the message event to receive data from the app? Not only return values, imagine an app updating the browser as data changes like:

    <a href="wallst.com?ticker=AAPL" action="stocks" onmessage="update(event)">

Kind of server events attached to the message event of an actionable link. Everything scriptable.

You know, just throwing ideas to the wall to see if something sticks.

We've been doing href="mailto:[email protected]" for centuries and it has worked very well.

Good point about returning data.

we will definitely be supporting mailto etc using all the existing methods.

This reminds me a little of OLE (but for the web). Not the same thing but a few similarities.

Seems like something you could probably already do with like an iframe and postMessage. There is a JavaScript based implementation, maybe that's how they do it.

http://www.webintents.org/

That is exactly how the shim works :)

How are web intents different from the Semantic Web? The only differences in ideology I can find right now is the prevalence of actions over data. But still, to what degree are these concepts similar?

I might be dim but I fail to see any connection at all.

One is about metadata and machine readability whilst the other is about linking web app capabilities.