On Wed, Sep 21, 2011 at 6:55 AM, Sean Eagan <seaneag...@gmail.com> wrote:The idea is that being displayed inline will be a more seamless user
> > We envision the 'inline' display replacing the service selection
> > of the picker UI.
> If all of the service selection UI is replaced, what useful remaining
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 beThere are definitely clickjacking and phishing concerns with iframes.
> > better to basically layer on top of the existing (client) page context,
> > 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.
> > a title or something).
> We agree on the use case of keeping the service UI in context with the
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.
In our prototypes, we're using a "spoof-proof" bubble which is displayed in
> I agree the next best way to preserve context is to display the
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.
These are all great questions, and we don't have final answers for pretty
> Also, it ought to be clear to the user from which context a given
> So far we have mostly been discussing regular browsing contexts as
much any of them. :-) The question of intent picker modality is open, as is
that of simultaneous and nested intents. The mental model guiding us is that
intents are only triggered by direct intentional user action. That is, some
control they click or tap on. (Of course, that can be subject to
exploitation, as pop-unders on clicking on text areas shows. We don't have a
final answer for things like that.) The idea, then, is that when the user
makes that action, they are presented with a UI within the current browsing
context. The trade-off there is spoof-proofing the UI surface and anchoring
it to the element of content which originated the action. But as you say,
sometimes the UA itself may originate the action (i.e. a context menu). In
trading off these various concerns, we've settled on a prototype that uses
the spoof-proof bubble.
Good summary. The kinds of concerns we have for this are definitely not
> > Perhaps we'll conquer the problem of managing
> Assuming the picker consists of a UI component which has not
> > This is a great discussion. We've pretty much talked ourselves out of
> My core arguments against the disposition concept as is are:
> * It is a problem which all web content faces, not just
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.
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.