Disposition documentation added

26 views
Skip to first unread message

James Hawkins

unread,
Sep 13, 2011, 1:26:04 PM9/13/11
to web-i...@googlegroups.com
I recently added documentation on disposition registration for the service [1].  We have previously talked about having three dispositions: window, inline, background.

A few of us had a chat in SMO yesterday to figure out the semantics of the background disposition.  There are use cases for services using the background disposition, e.g., a link shortening service, and we agree the background disposition is the best user experience for services that do not need to provide UI to the user.

However, there are a few problems:
* What if the service needs to 'unhook' itself by displaying UI to the user, e.g., authentication.
  - Provide a window.show() method that transforms the background disposition to inline?
* Will the user become confused that an operation is ongoing, non-hosed?
  - Proper UI can attempt to alleviate this issue.
* Will the desire for brand recognition/face time cause service developer to ignore background disposition?
* How do we design the API such that the service developer will do what's best for the user?
  - That is to say, use background disposition instead of inline displaying a logo while the service crunches numbers in the background.

After much deliberation and consideration, we decided to drop the background disposition.  We envision the background disposition being an awkward vestige in practice.  We'd love to hear your comments before we finalize this though.

Thanks,

Sean Eagan

unread,
Sep 13, 2011, 3:23:08 PM9/13/11
to web-i...@googlegroups.com
Hi all,

I totally agree that dispositions beyond popup windows are needed.
However, I don't think the set of existing (or future) dispositions
for web content can or should be enumerated in any spec (my best
attempt is here:
https://github.com/PaulKinlan/WebIntents/issues/89#issuecomment-2055158).
Even if they could, disposition availability varies by form factor
(phones don't have popup windows for example). Also, all web content,
not just that which is triggered by a web intent, is subject to being
displayed in any given disposition, so any solution for allowing web
content to constrain its disposition should exist outside the web
intents spec. However, I don't think such a solution is even needed,
the basic premise of "responsive web design" is that web content
should "adapt" or "respond" to it's environment, which would include
it's disposition, rather than providing one or more static services
each constrained to a given disposition, which is more difficult for
the user and caller to manage. Also, sometimes web content is allowed
to change it's disposition anyway, such as by popping out of an
iframe, requesting full screen access for video content, or switching
between foreground and background. Users and clients ("startActivity"
callers in the case of web intents) ought to have ultimate say over
the disposition.

As precedent, with links, user agents allow users to "open link in new
tab", and allow clients (pages which include links) to specify `<a
target="_blank" ...>`, and conversely do not allow services (pages
being linked to) to declare their disposition. Services can determine
their disposition though via e.g. `window.opener`, `window.parent`,
view port size, user agent string, CSS3 media queries, etc.

Also, the proposed "inline" disposition cannot coexist with a default
service selection capability since it would cause services to be
displayed within the service picker which would not even be displayed
for intents for which the user has previously selected a default
service. Default service selections are needed, so that leaves only
"window", which gets us back to where we started.

I think one disposition that is in need of some support from the web
platform is "embedded", see
https://github.com/PaulKinlan/WebIntents/issues/80. The component
model (http://wiki.whatwg.org/wiki/Component_Model) may help in this
area as well.


Thanks,
Sean Eagan

Paul Kinlan

unread,
Sep 13, 2011, 4:07:51 PM9/13/11
to web-i...@googlegroups.com
Hi Sean,

Thanks for the email.

Default and Inline:  They can co-exist fine, the shim is not the ideal canonical example of default and inline because it is unable to open a new window without a user action initiating the intent handler.  Also, we haven't mandated the default is anything other then managed by the UA, Chrome for instance could not have a default option, if it did it could easily offer the user the ability to change their default inline action.

Target pages not specifying their dispostion: A lot of the reason behind this is because the UA never knows what is at the other end.  We believe that allowing the target to say concisely how it will be displayed is an important feature that needs to be handled by the target app.

Different UA's on different devices may choose to do inline in different ways, for example on a mobile device it might be a near full screen overlay and we would expect the service to be able to respond to the different constraints.

Embedded:  This is a longer term goal, are you saying that you would want to let the app define an area where the content might be rendered - but it has no way of manipulating or interacting with the content?

P



--
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5

Sean Eagan

unread,
Sep 14, 2011, 3:45:43 PM9/14/11
to web-i...@googlegroups.com
Thanks Paul! Responses below...

On Tue, Sep 13, 2011 at 3:07 PM, Paul Kinlan <paulk...@google.com> wrote:
> Hi Sean,
> Thanks for the email.
> Default and Inline:  They can co-exist fine, the shim is not the ideal
> canonical example of default and inline because it is unable to open a new
> window without a user action initiating the intent handler.  Also, we
> haven't mandated the default is anything other then managed by the UA,
> Chrome for instance could not have a default option,

Yes, but the absence of default service selection would make for a
pretty poor user experience.

> if it did it could easily offer the user the ability to change their default inline

A convenient way to change a default service selection when that
selection is loaded would be useful, however, displaying the full
picker UI despite the user having said "I don't want to have to pick
this again", would be annoying. It would be better to display
something like an infobar or notification that the user can click if
they want to bring up the full picker UI to change their selection.
Even in the absence of default service selection, when the user makes
just a regular selection they no longer want to see the picker, only
the service. A clean separation between the UI of the picker and
service also makes for a more consistent experience between web intent
and direct navigation loading of the service.

I think what you are really after with "inline" is a quick,
convenient, and compact service display mechanism. This could be
achieved via a dialog ( corresponding to (view-mode: windowed) from
media queries) or embedding (see below).

> Target pages not specifying their dispostion: A lot of the reason behind
> this is because the UA never knows what is at the other end.  We believe
> that allowing the target to say concisely how it will be displayed is an
> important feature that needs to be handled by the target app.

The concept of a "target app" (which I have been referring to as
"service") already exists outside web intents, for example apps can be
targeted via:

* window.open
* iframe
* embedded HTML/JS snippets

If apps need more control over how they are displayed, then they
should be provided this regardless of the targeting method (web
intents or otherwise).

There is already support for services detecting their disposition, for example:

* window.opener (for window.open)
* window.parent (for iframes)
* window.location (for embedded HTML/JS snippets)
* media queries

Services can then react to this info based on some criteria:

* security
* refuse to be displayed in a popup window
* break out of an iframe
* creat an iframe to be displayed within
* user experience
* request full screen access
* change layout based on view port size
* transparent background when in an iframe
* display "unsupported" message of some sort

Something which may be useful is a generalized version of
https://wiki.mozilla.org/Gecko:FullScreenAPI, which takes into account
all view-modes (http://www.w3.org/TR/view-mode/), not just fullscreen,
and even all media queries. Something like:

document.media.request("(view-mode: windowed)",
function(success){success && log("yay!");});
var isWindowed = document.media.query("(view-mode: windowed)");


> Embedded:  This is a longer term goal, are you saying that you would want to
> let the app define an area where the content might be rendered - but it has
> no way of manipulating or interacting with the content?

Yes, clients often embed service UI (maps, code/document editors,
sharing widgets, etc.) within their own UI which has obvious
advantages. Unless support is added, they will lose this ability with
web intents. Outside web intents this might look like:

document.getElementById('iframe').src = "http://example.org/service.html";

For intents this might look like:

document.getElementById('iframe').startActivity(intent);

One of the goals of web intents seems to be isolation and anonymity
between service and client, is that correct ? If so, then iframes may
not work, thus a new element may be needed as I suggested at
https://github.com/PaulKinlan/WebIntents/issues/80.

I think the only thing the service cares about here is adequate
viewport space, and pleasing their users.

--
Sean Eagan

Sean Eagan

unread,
Sep 16, 2011, 11:52:07 AM9/16/11
to web-i...@googlegroups.com
Looks like what I was calling document.media.query is already being
worked on as document.matchMedia [1]. This could be extended to have
a "requestMedia" method equivalent to "matchMedia" except that it
indicates a desire for the passed media queries to become true, or a
boolean parameter could be added to "matchMedia" instead which
indicates this desire.

This would allow web intents services to request to be in a dialog
window for example:

var mql = document.requestMedia("(view-mode: windowed)");
mql.addListener(function(mql) {mql.matches && log("yay!")});

They would run this code in <head> as early as possible so that their
preference can be taken into account before the document paints.

[1] http://dev.w3.org/csswg/cssom-view/#dom-window-matchmedia

--
Sean Eagan

Greg Billock

unread,
Sep 16, 2011, 12:50:55 PM9/16/11
to web-i...@googlegroups.com
Thanks, Sean!

We envision inline disposition with a default handler set as popping up the picker bubble with the contents of the service url displayed in it, so basically just skipping the step of the user selecting the service.

I totally agree that service pages should be expected to adapt to their display environments. Even if it's possible to detect that they're in a bubble versus a tab, that's probably not as interesting as the height/width layout constraints they have, which you're right will be very different on a phone or tablet or netbook or ... On a phone, for example, the presentation may end up being virtually identical in size for "inline" and "window".

An "embedded" disposition is probably out for phishing reasons. Any off-site web content which is fully enclosed in the embedding page is a phishing hazard. We think spoof-proof bubbles and the UA-chromed picker will make phishing attacks on intents services much more difficult to pull off. We've even discussed whether that fact means we should reconsider even having an option to default any selection. Time will tell.

One key rationale for having a "window" disposition at all is if a handler wants to ensure it looks like a tab, such as if it presents a login interaction and wants to make sure any SSL checks are available to the user, or something like that. Then it's prudent to make sure you're really executing in an environment that's well understood. We hypothesize that many of the most common intent actions will actually end up being most naturally to place inline, but launching a new tab is well understood by users and developers. If that's an option, then it should be up to the service to specify it, for that reason.

On Tue, Sep 13, 2011 at 12:23 PM, Sean Eagan <seane...@gmail.com> wrote:

Sean Eagan

unread,
Sep 19, 2011, 11:52:20 AM9/19/11
to web-i...@googlegroups.com
Thanks, responses below...

On Fri, Sep 16, 2011 at 11:50 AM, Greg Billock <gbil...@google.com> wrote:
> Thanks, Sean!
> We envision inline disposition with a default handler set as popping up the
> picker bubble with the contents of the service url displayed in it, so
> basically just skipping the step of the user selecting the service.

I don't think anything should be assumed about the picker UI, such as
it being a bubble, or requiring it to support inline loading of
services. It should simply be responsible for allowing users to pick
services. This, for example, would allow for a "mediate" action,
which allows users to use an intent picker service of their own
choosing. The UA could bootstrap this by implementing a simple
"mediate" action picker in its settings UI. This would all be
entirely optional, and could even develop organically outside the web
intents spec, as e.g. an http://example.org/mediate action. A
"mediate" action decouples the user's browser choice from their web
intents data choice, thus giving users more choice, as well as
removing any unfair advantage for providers of both a browser and a
search engine to index <intent> registrations.

I don't see the use case for "inline". Once the user has selected a
service, why would they want to still see any picker-related UI ? At
that point it is just getting in the user's way by taking up valuable
screen space that could be used by their selected service (whom would
also not like this, and thus would not want to register for it). With
android intents, once the service is selected, the picker goes away,
and the service loads just as if it was directly navigated to. I do
see a use case for services to request a convenient / compact / quick
UI, but as I noted before, I believe this use case extends beyond web
intents, and thus should be handled more generically, and also should
be handled at runtime so as to take into account all the various
factors which go into such a decision such as platform and form
factor. I think a `document.requestMedia` would be a great addition
in this respect.

In the case of a defaulted selection, the picker never even needs to
be displayed at all, the UA can provide some non-intrusive UI
indicator (such as an infobar, notification, or page action (chrome
terminology)) to alert the user that their default selection is being
used, which the user can click on to bring up the full picker UI on
the rare occasion that they want to change their default.

> I totally agree that service pages should be expected to adapt to their
> display environments. Even if it's possible to detect that they're in a
> bubble versus a tab, that's probably not as interesting as the height/width
> layout constraints they have, which you're right will be very different on a
> phone or tablet or netbook or ... On a phone, for example, the presentation
> may end up being virtually identical in size for "inline" and "window".
> An "embedded" disposition is probably out for phishing reasons. Any off-site
> web content which is fully enclosed in the embedding page is a phishing
> hazard. We think spoof-proof bubbles and the UA-chromed picker will make
> phishing attacks on intents services much more difficult to pull off. We've
> even discussed whether that fact means we should reconsider even having an
> option to default any selection. Time will tell.

I agree that any embedded content leads to spoofing/phishing concerns,
however, there are plenty of examples of embedded content which has
usefully existed despite such concerns for a long time, such as
embedded maps, like/tweet/+1 etc. buttons, code/document editors, and
all sorts of other widgets, so maybe there is a way to make it work,
need to think about it more.

> One key rationale for having a "window" disposition at all is if a handler
> wants to ensure it looks like a tab, such as if it presents a login
> interaction and wants to make sure any SSL checks are available to the user,
> or something like that. Then it's prudent to make sure you're really
> executing in an environment that's well understood. We hypothesize that many
> of the most common intent actions will actually end up being most naturally
> to place inline, but launching a new tab is well understood by users and
> developers. If that's an option, then it should be up to the service to
> specify it, for that reason.

I disagree. If an https service doesn't pass SSL checks or otherwise
misbehaves, the UA should provide a consistent UI to alert the user to
this, regardless of whether the service was loaded via web intents or
any disposition preferences the service may have. An "inline"
disposition is inherently visually inconsistent with non-web-intent
loading of services, and thus makes for a less well understood
environment for the user.

Thanks,
Sean Eagan

Greg Billock

unread,
Sep 19, 2011, 12:59:06 PM9/19/11
to web-i...@googlegroups.com
On Mon, Sep 19, 2011 at 8:52 AM, Sean Eagan <seane...@gmail.com> wrote:
Thanks, responses below...

On Fri, Sep 16, 2011 at 11:50 AM, Greg Billock <gbil...@google.com> wrote:
> Thanks, Sean!
> We envision inline disposition with a default handler set as popping up the
> picker bubble with the contents of the service url displayed in it, so
> basically just skipping the step of the user selecting the service.

I don't think anything should be assumed about the picker UI, such as
it being a bubble, or requiring it to support inline loading of
services.  It should simply be responsible for allowing users to pick
services.  This, for example, would allow for a "mediate" action,
which allows users to use an intent picker service of their own
choosing.  The UA could bootstrap this by implementing a simple
"mediate" action picker in its settings UI.  This would all be
entirely optional, and could even develop organically outside the web
intents spec, as e.g. an http://example.org/mediate action.  A
"mediate" action decouples the user's browser choice from their web
intents data choice, thus giving users more choice, as well as
removing any unfair advantage for providers of both a browser and a
search engine to index <intent> registrations.

Exposing the picker UI to extensions is a good idea. I think Mozilla is thinking along those lines. We don't have any specific plans to either do it or not do it on the Chromium project at this point.

In terms of how we envision users adding services to the system, obviously they'll be able to do so by using the Web Store on Chrome. The Mozilla folks want to include this capability as part of the app manifest as well. In our proposal from Chromium folks, there's a plan to allow <intent> tag registration from arbitrary pages as well, so users can be guided by sites they visit to install intent handlers. The idea is that services that users know and use will be installed and able to handle intents.

We definitely think that it'll provide benefit to users to be able to search for intent handlers. For Chrome, we've talked about having a way for the Web Store to expose such a capability to make it easy to find providers. Crawling the web for <intent> tag pages is also a good idea which we may end up doing, depending on how that capability works out.

We do envision storing user preferences for intents handlers in the browser. (You can see our commit logs for our prototypes of how this may end up working for Chromium.) I think that this is well within scope for browsers; users are accustomed to storing all kinds of user preferences such as this in the browser. Creating a preference storage solution using APIs to plug-in services isn't something we've talked about doing. I think it'd take a pretty strong case to lay out how this benefits users, however.


 

I don't see the use case for "inline".  Once the user has selected a
service, why would they want to still see any picker-related UI ? At
that point it is just getting in the user's way by taking up valuable
screen space that could be used by their selected service (whom would
also not like this, and thus would not want to register for it).  With
android intents, once the service is selected, the picker goes away,
and the service loads just as if it was directly navigated to.  I do
see a use case for services to request a convenient / compact / quick
UI, but as I noted before, I believe this use case extends beyond web
intents, and thus should be handled more generically, and also should
be handled at runtime so as to take into account all the various
factors which go into such a decision such as platform and form
factor.  I think a `document.requestMedia` would be a great addition
in this respect.

In the case of a defaulted selection, the picker never even needs to
be displayed at all, the UA can provide some non-intrusive UI
indicator (such as an infobar, notification, or page action (chrome
terminology)) to alert the user that their default selection is being
used, which the user can click on to bring up the full picker UI on
the rare occasion that they want to change their default.


We envision the 'inline' display replacing the service selection components of the picker UI. The best way to follow our thinking on this is to think of tabbed browsers. The most "natural" way to think of intents is that picking a service opens a new tab with the service url running in it. This is familiar to users of tabbed browsers, it has the least UI novelty, and leverages the full capability of the browser chrome in displaying and managing the new rendering context. For some intents, though, it might be better to basically layer on top of the existing (client) page context, so the user can maintain a better mental image of what's going on with the intent work flow, and perhaps interact with the client page (i.e. copy-paste a title or something). That's what we think of as "window" vs. "inline". These may not be the best possible names for this behavior; they're just the best we've come up with so far. There's no guarantee about sizing, visibility, etc. in them, or what the browser may or may not be showing simultaneously.
That's a great explanation of why we think having a "window" disposition is important. At least right now. Perhaps we'll conquer the problem of managing a visually consistent language for displaying any UI indications needed on bubbles vs. tabs (or panels as well, in ChromeOS). For now, we're not confident enough in our ability to solve this problem to want to tightly couple the success of intents to solving that problem.

This is a great discussion. We've pretty much talked ourselves out of having a "background" disposition at this point, and believe me, it'd be great to get an good way to think about getting rid of "disposition" altogether. :-) I don't think we've done it yet, but I think we've identified some of the key problems that need to be solved to really make that the compelling way forward.

 

Thanks,
Sean Eagan

Sean Eagan

unread,
Sep 21, 2011, 9:55:11 AM9/21/11
to web-i...@googlegroups.com
> We envision the 'inline' display replacing the service selection components
> of the picker UI.

If all of the service selection UI is replaced, what useful remaining
picker UI will exist to distinguish it from any arbitrary bubble,
dialog, panel, etc. ? If none, then why would the service care to be
displayed there ?

> For some intents, though, it might be
> better to basically layer on top of the existing (client) page context, so
> the user can maintain a better mental image of what's going on with the
> intent work flow, and perhaps interact with the client page (i.e. copy-paste
> a title or something).

We agree on the use case of keeping the service UI in context with the
client UI. I believe that allowing the client to embed the service
directly within the page accomplishes this best. Regarding your
phishing concerns with embedded content, iframes fall into this
category, do you believe iframes should be deprecated because of this
? The component model [1] also enables embedded content, do you
believe it should not ?

I agree the next best way to preserve context is to display the
service within the same tab or window as the client, as with an
"inline" disposition. However, I don't think the service should load
"within the picker". There should be a clear distinction between the
picker and a given service. For one thing, a service could
potentially spoof the picker UI. Also, consider a service loading
within the picker and then subsequently kicking off a "nested" intent,
where should the picker for the nested intent load ?

Also, it ought to be clear to the user from which context a given
intent was launched. Thus, the picker for a given intent should have
some way to visually link itself to the browsing context which
initiated the intent. Having multiple browsing contexts within the
same tab or window, as with "inline" and embedding, may make this
difficult. One thing which may help is requiring browsing contexts to
have focus in order to initiate intents, and possibly making the
picker "modal" so that users do not switch browsing contexts and
forget which one initiated the intent. I believe the android intents
picker is modal.

So far we have mostly been discussing regular browsing contexts as
being the clients, however, there are many use cases for the UA itself
to be a client. For example, the UA may initiate an intent based on
something typed into the location bar, or a context menu click. I'm
not sure how "inline" will make sense when there is no client browsing
context.

> Perhaps we'll conquer the problem of managing
> a visually consistent language for displaying any UI indications needed on
> bubbles vs. tabs (or panels as well, in ChromeOS). For now, we're not
> confident enough in our ability to solve this problem to want to tightly
> couple the success of intents to solving that problem.

Assuming the picker consists of a UI component which has not
previously been used to host arbitrary web content, such as a bubble,
doesn't loading services within the picker as with "inline" just add
this new UI component to the list in which the UA must provide a
consistent UI ?

> This is a great discussion. We've pretty much talked ourselves out of having
> a "background" disposition at this point, and believe me, it'd be great to
> get an good way to think about getting rid of "disposition" altogether. :-)
> I don't think we've done it yet, but I think we've identified some of the
> key problems that need to be solved to really make that the compelling way
> forward.

My core arguments against the disposition concept as is are:

* It is a problem which all web content faces, not just
web-intents-loaded content, and thus its solution should be accessible
to all web content
* Services do not want the same disposition on all platforms and form
factors, so they should not be registering a priori, but rather at
runtime when they have access to such information
* The client and user should have ultimate control over the
disposition of the service since they know their own use case the best
* Unnecessary complexity

[1] http://wiki.whatwg.org/wiki/Component_Model

Thanks,
Sean Eagan

Peter Petermann

unread,
Sep 21, 2011, 10:15:05 AM9/21/11
to Web Intents
Hello everyone,

the last two days i spend a considerable amount of time looking into
what you guys are doing,
and the disposition thing is something that totally made me stumble.

It feels pretty weird to me to have the service define how it is
displayed,


> We envision the 'inline' display replacing the service selection components
> of the picker UI. The best way to follow our thinking on this is to think of
> tabbed browsers. The most "natural" way to think of intents is that picking
> a service opens a new tab with the service url running in it.
> This is familiar to users of tabbed browsers, it has the least UI novelty, and
> leverages the full capability of the browser chrome in displaying and
> managing the new rendering context.

This might be right for a service that is used parallel to my own web-
application,
but to me the more interesting use-case of WebIntents is stuff like
(not exclusively though)
picking an image from a cloud service, or picking a piece of
information from a service provides.

Now lets stick with the example for a bit:
1) user is in my web application, lets assume its a contact database,
which allows you to add photos to your contacts
2) user clicks on 'add photo', and which causes the app to start an
activity for picking photos
3) either to user picks an service, or his default kicks, does not
really matter
4) after that the user is basically in the context of the service
application, where he picks an image
5) user returns to my application which now has the information to add
the photo

Now, if you have a user who uses several services, and several
services decide to implement it in different ways
(one as window, one inline) you end up with a pretty confusing user
experience;

A window based service that opens in a new tab will make it feel very
strange,
since the User can switch back my contact app, which means i have to
explain to the user what he has to do,
rather than implying it - not really a satisfying user experience.

Now, i can see you suggesting to use inline next,
but the way inline is described so far, is not satisfying either. For
a Like button, that allows a quick comment, that might be ok,

but lets say i have a bit more complex webapp,
lets assume the contacts i spoke of are a small part of that running
in a window or a tab that the
webapp (not the UA) provides.

Lets assume i want to open a window/tab of my webapp for the service
thats opened,
so the user gets not confused through fully leaving the context of the
application.

Lets assume i want to block parts of the application till the user has
closed the window..

Either way, besides the two current options not being enough (or me
missing something),
my point is that the service provider won't know how my application
looks like,
and my app should always be able to overwrite the disposition the
service provider sets.


> > > of the most common intent actions will actually end up being most
> > > naturally to place inline, but launching a new tab is well understood by users and
> > > developers.
i'd agree with that users know tabs, but i don't think users are used
to having
several tabs interact with each other.
Personally a tab to me means a different website/application or
document - without any
interaction between the tabs.


> > > If that's an option, then it should be up to the service to
> > > specify it, for that reason.
i don't see why the service should be deciding if it's ok to break the
user experience,
specifically not since there is no way for me to influence
who is providing a service for an intent.

best regards,
Peter Petermann

James Hawkins

unread,
Sep 22, 2011, 2:34:51 PM9/22/11
to web-i...@googlegroups.com
Thanks for your feedback Peter!  Comments in-line.

Ah!  Here is where we lost you: it may not be spelled out well enough in the current draft, but the UA may (perhaps it should be must) return to the client context once the service calls postResult().  The user does not need to take any action to be taken back to your site.
 
Now, i can see you suggesting to use inline next,
but the way inline is described so far, is not satisfying either. For
a Like button, that allows a quick comment, that might be ok,

but lets say i have a bit more complex webapp,
lets assume the contacts i spoke of are a small part of that running
in a window or a tab that the
webapp (not the UA) provides.


I'm confused here.  Even if the webapp opened the window|tab, it's still provided by the UA, thus the user can interact with the Intents UI.
 
Lets assume i want to open a window/tab of my webapp for the service
thats opened,
so the user gets not confused through fully leaving the context of the
application.

Lets assume i want to block parts of the application till the user has
closed the window..


What is stopping the client from implementing this?

It sounds as though you are requesting an uber-inlined disposition, where the service is loaded directly in the client page (in an iframe perhaps).  We left this out of the API because it's too easily spoofed.  Once we have phishing sites using Web Intents as a vector of attack, the API is no longer trustworthy and thus becomes unusable.
 
Either way, besides the two current options not being enough (or me
missing something),
my point is that the service provider won't know how my application
looks like,
and my app  should always be able to overwrite the disposition the
service provider sets.


Can you provide a concrete example of a scenario where the *user experience* would be better if the client could specify the disposition?
 

> > > of the most common intent actions will actually end up being most
> > > naturally to place inline, but launching a new tab is well understood by users and
> > > developers.
i'd agree with that users know tabs, but i don't think users are used
to having
several tabs interact with each other.
Personally a tab to me means a different website/application or
document - without any
interaction between the tabs.


Users don't need to know how the tabs are interacting.  If both the client and service provide good UI (e.g., client: Edit, service: Save edited image), then the user will not be confused.
 

> > >  If that's an option, then it should be up to the service to
> > > specify it, for that reason.
i don't see why the service should be deciding if it's ok to break the
user experience,
specifically not since there is no way for me to influence
who is providing a service for an intent.


As above, can you provide a concrete example of how the service choosing disposition breaks the user experience?  Our guiding principle when designing the API is first and foremost the user experience.

Thanks,
James

Peter Petermann

unread,
Sep 23, 2011, 7:54:39 AM9/23/11
to web-i...@googlegroups.com
Hey James,


>> Now, if you have a user who uses several services, and several
>> services decide to implement it in different ways
>> (one as window, one inline) you end up with a pretty confusing user
>> experience;
>>
>> A window based service that opens in a new tab will make it feel very
>> strange, since the User can switch back my contact app, which means i have to
>> explain to the user what he has to do, rather than implying it -
>> not really a satisfying user experience.

> Ah!  Here is where we lost you: it may not be spelled out well enough in the
> current draft, but the UA may (perhaps it should be must) return to the
> client context once the service calls postResult().  The user does not need
> to take any action to be taken back to your site.

you are missing the point that im trying to make,
as a user i am used to one browser tab equals one website/webapp instance,
tabs are just another way to have several browser windows open.

if a website opens a new browser tab, it feels like
'oh, it just opened another website for me',
and no matter if you return after postResult (and you are right, i believe a
'must' is a good idea there), you still end up in a situation where the user
might switch tabs, for example back to the app that started it
(and maybe even launches another activity there? which might make it even
more confusing); which totally breaks the flow of the process.

>> Now, i can see you suggesting to use inline next,
>> but the way inline is described so far, is not satisfying either. For
>> a Like button, that allows a quick comment, that might be ok,
>> but lets say i have a bit more complex webapp,
>> lets assume the contacts i spoke of are a small part of that running
>> in a window or a tab that the
>> webapp (not the UA) provides.
> I'm confused here.  Even if the webapp opened the window|tab, it's still
> provided by the UA, thus the user can interact with the Intents UI.

its provided as much as any element on any website is provided by the UA,
its rendered by it - im not speaking of the webapp opening a UA tab,
im speaking of webapps that have their own tabs - for example tabs through
some fancy js library like jquery.


>> Lets assume i want to open a window/tab of my webapp for the service
>> thats opened, so the user gets not confused through fully leaving
>> the context of the
>> application.
>>
>> Lets assume i want to block parts of the application till the user has
>> closed the window..
>>
> What is stopping the client from implementing this?

i would be very scared if i could block switching of browser tabs or even the
user interaction within other tabs through a webapp.

and if starting the activity allways launches the stuff in a separate
browser-tab, browser-window or some special dialog, i franky cannot put it in
a (for example) jquery based webapp-tab.


> It sounds as though you are requesting an uber-inlined disposition, where
> the service is loaded directly in the client page (in an iframe perhaps).

i don't exactly see whats 'uber-' about that, its basically what the word
inline means to me.

>  We left this out of the API because it's too easily spoofed.  Once we have
> phishing sites using Web Intents as a vector of attack, the API is no longer
> trustworthy and thus becomes unusable.

WebIntents are a vector for spoofing attacks anyways. You are trading off
usability for the pretense of security. In the end even with new tabs
nothing stops an attacker from creating a website that looks like yours,
where he makes some text to distract you from the fact that the new tab
has a differen url.

If you want to improve a users safety, make users being asked if they want to
'install' an intent when the UA discovers <intent ..>,
and allow black/white listing of provider sources for apps
(which would be a nice feature anyways, but i believe that
should be a different discussion)

>>
>> Either way, besides the two current options not being enough (or me
>> missing something), my point is that the service provider won't know
>> how my application looks like,
>> and my app  should always be able to overwrite the disposition the
>> service provider sets.
> Can you provide a concrete example of a scenario where the *user experience*
> would be better if the client could specify the disposition?

i was under the impression that i gave a good example in my original mail,
but i guess we have different interpretations of what i wrote, maybe
due to looking at it from different perspective,
ill try to write an better example at the end of the mail.

>> > > > of the most common intent actions will actually end up being most
>> > > > naturally to place inline, but launching a new tab is well
>> > > > understood by users and
>> > > > developers.
>> i'd agree with that users know tabs, but i don't think users are used
>> to having several tabs interact with each other.
>> Personally a tab to me means a different website/application or
>> document - without any
>> interaction between the tabs.
> Users don't need to know how the tabs are interacting.  If both the client
> and service provide good UI (e.g., client: Edit, service: Save edited
> image), then the user will not be confused.

the 'how' is not relevant - the user sees a 'save' in one website, and is not
used to that 'save' actually changing something for another website in another
tab.

>> > > >  If that's an option, then it should be up to the service to
>> > > > specify it, for that reason.
>> i don't see why the service should be deciding if it's ok to break the
>> user experience,
>> specifically not since there is no way for me to influence
>> who is providing a service for an intent.
> As above, can you provide a concrete example of how the service choosing
> disposition breaks the user experience?  Our guiding principle when
> designing the API is first and foremost the user experience.

ok, ill try to give a better example here:

If i run my browser, i usually have several webapplications open, each
in one tab,
lets assume its: Facebook, Google+, Google Mail, and the Example
Application (4 Browser-Tabs)
(relevant for what a user is used to using the Browser-Tabs for)

Now the Example Application has an option to add contacts from existing contact
sources (for example other webpages).

if the user clicks on the option, he either gets a picker for the contact
service provider, or his default will be picked.

i believe so far we are on the same track.


-- 1
Now for current webapps (with good usability, there are those that redirect you
(yikes) too) you get an overlay which does all the fancy fading off background
stuff, and allows you to pick that contact you want to add.
Sometimes the content of the overlay is an iframe, in other solutions its
something that got build from data that an rpc service delivered.

this what the user is used to, and a pretty straight forward way which does
not need much explanation to the user. even if the content of the box looks
slightly different for different services, in most cases the user has pretty
much the same workflow.

you can see such features today to pick images, pick contacts, pick your
identity for making a comment and alot of other things.
-- /1

-- 2
Now lets imagine for a moment its not the way webapps do it today,
but the webintent way, with the service deciding if he wants to show it in
a picker, or if he wants to open a new browser tab.

So we are reset to the user has picked a service provider (imagine the block
enclosed by --1 --/1 is gone)

Now after picking a service provider, he *might* get it in the picker window
(which might be an experience similar to the one in --1) OR he might have
another application/website opening in his browser (a new tab).

Now this has several problems:
1) he has a huge difference in the feel of the process with the website if
he picks provider A (who has the inline disposition) or provider B
(who uses the one with the new tab)

2) assuming its provider B with the new tab, he now has 5 tabs:
facebook, google+, google mail, the example application, service provider B.
now everything he does on facebook happens in the facebook tab
everything he does on google+ happens in the google+ tab
everything he does on google mail happens in the google mail tab
now you could argue
that everything in the example app happens in the example app tab
and everything for the service provider happens in the service provider tab
but the workflow of adding a contact is an example app task, moving
the interaction to the new tab (no matter if it gets autofocus and is closed
at the end), breaks the flow, it splits interaction of one process into two
tabs.

3) if you open such functionality in an additional tab, you also might be forced
to override a users settings. For example i have my browsers set to open a
tab in background, rather than switching directly to it - which for this
workflow would be a total breaker. Now, is it the right thing todo to override
a users settings, totally breaking the way he usually works with all other
websites?

-- /2

i hope this example gives you a better picture of the user experience problem
that i see.


best regards,
Peter Petermann

Greg Billock

unread,
Sep 26, 2011, 2:05:59 PM9/26/11
to web-i...@googlegroups.com
(I've been out on vacation. Will try to clarify a couple things inline.)

On Wed, Sep 21, 2011 at 6:55 AM, Sean Eagan <seane...@gmail.com> wrote:
> We envision the 'inline' display replacing the service selection components
> of the picker UI.

If all of the service selection UI is replaced, what useful remaining
picker UI will exist to distinguish it from any arbitrary bubble,
dialog, panel, etc. ?  If none, then why would the service care to be
displayed there ?

The idea is that being displayed inline will be a more seamless user experience -- they haven't really navigated away from the page, so they can enter descriptions, copy-paste text, etc. from the context page. The "window" disposition feels more like a navigation. Sometimes that's probably appropriate, but for many actions, it's a bit abrupt.

 
> For some intents, though, it might be
> better to basically layer on top of the existing (client) page context, so
> the user can maintain a better mental image of what's going on with the
> intent work flow, and perhaps interact with the client page (i.e. copy-paste
> a title or something).

We agree on the use case of keeping the service UI in context with the
client UI.  I believe that allowing the client to embed the service
directly within the page accomplishes this best.  Regarding your
phishing concerns with embedded content, iframes fall into this
category, do you believe iframes should be deprecated because of this
?  The component model [1] also enables embedded content, do you
believe it should not ?


There are definitely clickjacking and phishing concerns with iframes. Developers have to pay a lot of attention to them. For this context, there's no way an intent service could know that it is being deployed in an iframe "involuntarily" and hence clickjacked. Since the services are likely to be ones that require login, that's a huge problem.
 

I agree the next best way to preserve context is to display the
service within the same tab or window as the client, as with an
"inline" disposition.  However, I don't think the service should load
"within the picker".  There should be a clear distinction between the
picker and a given service.  For one thing, a service could
potentially spoof the picker UI.  Also, consider a service loading
within the picker and then subsequently kicking off a "nested" intent,
where should the picker for the nested intent load ?


In our prototypes, we're using a "spoof-proof" bubble which is displayed in a way that web content can't copy -- the surface overlaps with browser chrome, which content cannot do. Whether this is a sufficient guard against phishing remains to be seen, but browsers are using this mechanism to defeat phishing, so users at least in theory are aware of the UI.

 

Also, it ought to be clear to the user from which context a given
intent was launched.  Thus, the picker for a given intent should have
some way to visually link itself to the browsing context which
initiated the intent.  Having multiple browsing contexts within the
same tab or window, as with "inline" and embedding, may make this
difficult.  One thing which may help is requiring browsing contexts to
have focus in order to initiate intents, and possibly making the
picker "modal" so that users do not switch browsing contexts and
forget which one initiated the intent.  I believe the android intents
picker is modal.

So far we have mostly been discussing regular browsing contexts as
being the clients, however, there are many use cases for the UA itself
to be a client.  For example, the UA may initiate an intent based on
something typed into the location bar, or a context menu click.  I'm
not sure how "inline" will make sense when there is no client browsing
context.

These are all great questions, and we don't have final answers for pretty much any of them. :-) The question of intent picker modality is open, as is that of simultaneous and nested intents. The mental model guiding us is that intents are only triggered by direct intentional user action. That is, some control they click or tap on. (Of course, that can be subject to exploitation, as pop-unders on clicking on text areas shows. We don't have a final answer for things like that.) The idea, then, is that when the user makes that action, they are presented with a UI within the current browsing context. The trade-off there is spoof-proofing the UI surface and anchoring it to the element of content which originated the action. But as you say, sometimes the UA itself may originate the action (i.e. a context menu). In trading off these various concerns, we've settled on a prototype that uses the spoof-proof bubble.

Good summary. The kinds of concerns we have for this are definitely not unique (iframes, content spoofing, monolithic namespace among components on a page). The idea that services may want to vary their disposition based on platform is interesting, although presumably they can count on the registration platform not changing character when they register. (That is, they can adjust their disposition requests based on whether they see themselves on a mobile vs. desktop UA.) I definitely agree that the UA has veto power over the disposition, and the service can't dictate display constraints very strongly without degrading the user experience.

-Greg

Reply all
Reply to author
Forward
0 new messages