Disposition documentation added
James Hawkins
Sean Eagan
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
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan
Sean Eagan
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
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
Sean Eagan
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
Thanks, responses below...
I don't think anything should be assumed about the picker UI, such as
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.
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.
Thanks,
Sean Eagan
Sean Eagan
> 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
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.
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.
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.
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
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.
i'd agree with that users know tabs, but i don't think users are used
> > > 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.
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.
i don't see why the service should be deciding if it's ok to break the
> > > If that's an option, then it should be up to the service to
> > > specify it, for that reason.
user experience,
specifically not since there is no way for me to influence
who is providing a service for an intent.
Peter Petermann
>> 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
> We envision the 'inline' display replacing the service selection componentsIf all of the service selection UI is replaced, what useful remaining
> of the picker UI.
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 beWe agree on the use case of keeping the service UI in context with the
> 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).
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.