Five suggestions for the service picker, selections and integration with desktop

[David Kreuter]

In three usecases I found chrome's current webintent-service-picker to be too limited.

(this one: http://www.chromium.org/developers/web-intents-in-chrome/with.PNG)

Broken english ahead. I'm no native speaker.

I assume that if for example a blogging service implements the "share"-intent it registers a service for each account like this:

[[[ Choose service to share "whatever" ]]]

[Share to imgur - Account 1]

[Share to imgur - Account 2]

[Share to tumblr - Account 1]

[Share to tumblr - Account 2]

1. If the user was a busy blogger with 20 accounts they would probably want to have a way to organize the registered services: Maybe hierarchically, maybe with tags, maybe with keyboard shortcuts.

So there should be a way for browser extensions to redefine this picker because these big buttons (in the linked image) only look good if less than 10 services are registered.

2. If I have understood correctly only browser extensions can currently register as webintent-services. I guess (hope) that's just temporary. After that it'd be useful to have an URL-Input field at the bottom of the picker (similar to the Chrome Web Store suggestions) to try out services without having to "install" and "uninstall" them. Like this:

[[[ Chose service to share "whatever" ]]]

Installed services:

[Share to imgur]

[Share to tumblr]

Or choose a service from the chrome web store

[Share to G+]

Or input URL of service here: [http://asdfghjk.com/]

[Share to asdfghjk]

3. There needs to be a way to define default actions in some contexts. (For example: "All share-intents from http://lolcat.tumblr.com/* should be sent to service X") Using URL-Patterns works without cooperation of the client but doesn't allow fine-grained control. I suggest using some tokens like API-Keys. Example:

A blog offers reposting it's posts via WebIntents.

The user clicks the share of one post and the browser asks the user to choose a service.

The user does that and additionally ticks a checkbox labeled something like "Remember this choice". 

Because of that the browser gives the blog a token/key.

The blog, noticing that it recieved this key, further asks the user what this key should be used for:

"Share all posts using this service" 

"Share all posts by author X using this service" 

"Share all posts from category A using this service".

The next time the user presses "Share" the javascript of the blog looks for a key that is applicable for the post.

The intent is activated together with the key and the user is presented the picker again.

This time however the service selected previously is highlighted and activatable with just one click or keyboard-press. It's more a confirmation-screen rather than a picker in this case.

4. Selections. Use-case: User selects a post (click-drag-release) on a page that doesn't support webintents. They rightclick the selection, and services registered for the selection-intent appear in the menu. The chosen service receives the selected html-fragment and can scan it for microformats, images or just reformat it and trigger more specific intents like "share" or "add-to".

5. Integration with desktop-apps. The browser could use dbus-services as webintent-services.

Please post feedback. (And later: Can anyone relay this in a more understandable form to the developers of the standard?)

[Greg Billock]

On Friday, May 25, 2012 1:09:45 PM UTC-7, David Kreuter wrote:

In three usecases I found chrome's current webintent-service-picker to be too limited.

(this one: http://www.chromium.org/developers/web-intents-in-chrome/with.PNG)

Broken english ahead. I'm no native speaker.

I assume that if for example a blogging service implements the "share"-intent it registers a service for each account like this:

[[[ Choose service to share "whatever" ]]]

[Share to imgur - Account 1]

[Share to imgur - Account 2]

[Share to tumblr - Account 1]

[Share to tumblr - Account 2]

The service could choose to do this, but I'd expect services to manage multiple accounts on their side using their own account management mechanisms. So this would look more like one entry per service as opposed to one entry per account on that service. The spec doesn't really address this, though, as it isn't clear at the outset which behavior the user wants, and the configurability the user agent provides on this front (i.e., the kind of organization controls you describe) is more a feature of the User Agent and how the user chooses to configure it.

 

1. If the user was a busy blogger with 20 accounts they would probably want to have a way to organize the registered services: Maybe hierarchically, maybe with tags, maybe with keyboard shortcuts.

So there should be a way for browser extensions to redefine this picker because these big buttons (in the linked image) only look good if less than 10 services are registered.

This is a good point. The picker is a natural point for an extension API.

 

2. If I have understood correctly only browser extensions can currently register as webintent-services. I guess (hope) that's just temporary. After that it'd be useful to have an URL-Input field at the bottom of the picker (similar to the Chrome Web Store suggestions) to try out services without having to "install" and "uninstall" them. Like this:

[[[ Chose service to share "whatever" ]]]

Installed services:

[Share to imgur]

[Share to tumblr]

Or choose a service from the chrome web store

[Share to G+]

Or input URL of service here: [http://asdfghjk.com/]

[Share to asdfghjk]

There's still discussion about how web pages will be registered as web intents services. In the meantime, yes, in Chromium only extensions/apps can register as services right now. We definitely mean this to be a temporary situation.  (The spec has a lot about how web pages will register, get intents delivered to them, etc.)

 

3. There needs to be a way to define default actions in some contexts. (For example: "All share-intents from http://lolcat.tumblr.com/* should be sent to service X") Using URL-Patterns works without cooperation of the client but doesn't allow fine-grained control. I suggest using some tokens like API-Keys. Example:

A blog offers reposting it's posts via WebIntents.

The user clicks the share of one post and the browser asks the user to choose a service.

The user does that and additionally ticks a checkbox labeled something like "Remember this choice". 

Because of that the browser gives the blog a token/key.

The blog, noticing that it recieved this key, further asks the user what this key should be used for:

"Share all posts using this service" 

"Share all posts by author X using this service" 

"Share all posts from category A using this service".

The next time the user presses "Share" the javascript of the blog looks for a key that is applicable for the post.

The intent is activated together with the key and the user is presented the picker again.

This time however the service selected previously is highlighted and activatable with just one click or keyboard-press. It's more a confirmation-screen rather than a picker in this case.

Absolutely. Defaults are critical. That's an area of active development in the project right now within Chromium. Coupling an API key or other credential to the service is not something we've done at this point -- we're currently thinking that the service will be able to do this using the service url of the service they provide to the user. This is another part of the behavior that's important, and which the spec leaves pretty open for the user agent.

 

4. Selections. Use-case: User selects a post (click-drag-release) on a page that doesn't support webintents. They rightclick the selection, and services registered for the selection-intent appear in the menu. The chosen service receives the selected html-fragment and can scan it for microformats, images or just reformat it and trigger more specific intents like "share" or "add-to".

Integrating browser-provided intents and services is something we're interested in experimenting with. We haven't done anything in that direction at this point.

 

5. Integration with desktop-apps. The browser could use dbus-services as webintent-services.

This is definitely an interesting direction, and we've attempted to develop the spec in such a way that it will allow for integration with OS-level apps. I'm not sure when we'll get to experimenting with that in Chromium. Hopefully soon! :-)

 

Please post feedback. (And later: Can anyone relay this in a more understandable form to the developers of the standard?)

Mission accomplished; we're listening. :-)

-Greg

 

[Dan Nemec]

On Friday, May 25, 2012 3:09:45 PM UTC-5, David Kreuter wrote:

2. If I have understood correctly only browser extensions can currently register as webintent-services. I guess (hope) that's just temporary. After that it'd be useful to have an URL-Input field at the bottom of the picker (similar to the Chrome Web Store suggestions) to try out services without having to "install" and "uninstall" them. Like this:

[[[ Chose service to share "whatever" ]]]

Installed services:

[Share to imgur]

[Share to tumblr]

Or choose a service from the chrome web store

[Share to G+]

Or input URL of service here: [http://asdfghjk.com/]

[Share to asdfghjk]

For the custom URL perhaps it could use a discovery url (eg. tumblr.com/webintent) that contains metadata on which intents are available for that web page. Maybe using a page full of <link>s (<link rel="http://webintents.com/share" href="http://tumblr.com/share?url=%s" />) so that a user can just type in "tumblr.com" and the intent machinery prepends http:// and appends the discovery path to create the full search url.

That's really the only way I can imagine making a user input the service url in a clean way without having the user go to the page he wants to share to and search for a bed of links to copy and paste just to add a service inline.

 

3. There needs to be a way to define default actions in some contexts. (For example: "All share-intents from http://lolcat.tumblr.com/* should be sent to service X") Using URL-Patterns works without cooperation of the client but doesn't allow fine-grained control. I suggest using some tokens like API-Keys. Example:

A blog offers reposting it's posts via WebIntents.

The user clicks the share of one post and the browser asks the user to choose a service.

The user does that and additionally ticks a checkbox labeled something like "Remember this choice". 

Because of that the browser gives the blog a token/key.

The blog, noticing that it recieved this key, further asks the user what this key should be used for:

"Share all posts using this service" 

"Share all posts by author X using this service" 

"Share all posts from category A using this service".

The next time the user presses "Share" the javascript of the blog looks for a key that is applicable for the post.

The intent is activated together with the key and the user is presented the picker again.

This time however the service selected previously is highlighted and activatable with just one click or keyboard-press. It's more a confirmation-screen rather than a picker in this case.

My impression is that webintents are designed to avoid placing any responsibility on the host for keeping track of things like who's visiting and what they're sharing with.

I think having a built-in way to provide multiple intent contexts is a good thing (much like many blogs offer multiple RSS feeds with different content [eg. by author, by category, all comments, etc.]) but again, I don't believe the host should be keeping track of who uses which context.

Managing defaults would work better as a function of the browser (or whichever UA you're using). Plus, it's good for privacy.