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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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);
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.
55 comments
[ 2.7 ms ] story [ 135 ms ] threadWeb 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.
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.
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/
* 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)
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.
When you think about it this seems to align well with the original philosophies of the web. Exciting times.
This is huge for web apps, and is a huge blow for local file system fans.
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.
It's less discoverable than a delay, but it is also far less annoying in the common case.
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.
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.
For what percentage of users is this likely to be a concern?
It happens occasionally to me and I'm not a smartphone "power user".
http://android-er.blogspot.de/2011/03/pick-file-using-intent...
After switching from Android to an iPhone, I miss the powerful User Experience that Android provides.
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...
One is about metadata and machine readability whilst the other is about linking web app capabilities.
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.
Good point about returning data.
You know, just throwing ideas to the wall to see if something sticks.
You'll notice that all of the editors are Googlers.
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/
http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview...
What are the security concerns?