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.
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.
On Tue, Sep 13, 2011 at 12:26 PM, James Hawkins <jhawk...@chromium.org> wrote: > 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, > James
*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?
On Tue, Sep 13, 2011 at 12:23 PM, Sean Eagan <seaneag...@gmail.com> wrote: > 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.
> On Tue, Sep 13, 2011 at 12:26 PM, James Hawkins <jhawk...@chromium.org> > wrote: > > 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, > > James
On Tue, Sep 13, 2011 at 3:07 PM, Paul Kinlan <paulkin...@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:
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:
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
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:
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.
> On Tue, Sep 13, 2011 at 12:23 PM, Sean Eagan <seaneag...@gmail.com> wrote:
>> 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.
>> On Tue, Sep 13, 2011 at 12:26 PM, James Hawkins <jhawk...@chromium.org> >> wrote: >> > 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, >> > James
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.
On Wed, Sep 14, 2011 at 2:45 PM, Sean Eagan <seaneag...@gmail.com> wrote: > Thanks Paul! Responses below...
> On Tue, Sep 13, 2011 at 3:07 PM, Paul Kinlan <paulkin...@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:
> 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:
> 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
>> 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:
> 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.
>> P
>> On Tue, Sep 13, 2011 at 12:23 PM, Sean Eagan <seaneag...@gmail.com> wrote:
>>> 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.
>>> On Tue, Sep 13, 2011 at 12:26 PM, James Hawkins <jhawk...@chromium.org> >>> wrote: >>> > 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, >>> > James
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 <seaneag...@gmail.com> wrote: > 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.
> On Tue, Sep 13, 2011 at 12:26 PM, James Hawkins <jhawk...@chromium.org> > wrote: > > 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, > > James
On Fri, Sep 16, 2011 at 11:50 AM, Greg Billock <gbill...@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.
On Mon, Sep 19, 2011 at 8:52 AM, Sean Eagan <seaneag...@gmail.com> wrote: > Thanks, responses below...
> On Fri, Sep 16, 2011 at 11:50 AM, Greg Billock <gbill...@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.
> > 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.
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.
> 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
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.
> 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.
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.
>> 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.
(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 <seaneag...@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.
> > 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
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.
