Re: Non-visible intents

James, Paul, and I have spent quite a bit of time discussing this. We
have always come back to the question of how do you let the user deal
with exceptional circumstances and status updates. There has to be
some UI surface for a background disposition service, so that the user
can get to it to shut it down if need be. So then we've always ended
up thinking that that UI surface ought to be where the service can
display status messages or perform error handling. But at that point,
it basically looks like an inline disposition.

We've discussed various permutations of Web Workers, invisible tabs,
and so forth, but so far at least, the above line of thinking has
always seemed more compelling.

For an example, think about a 'login' intent. This might often run to
completion with no problems whatsoever. But suppose even in the case
of a success, the service wishes to display a warning: "someone from
this unusual IP address has tried to access your account", or
something more functional: "You enabled two-factor auth, and you need
to enter your credential again." Or even something mechanical, like a
503 error from the login service. That needs to be displayed
somewhere. Leaving a temporary UI surface for the service to display
an in-process throbber or progress bar is even useful -- it lets the
user know something is happening, and it doesn't look like the client
page is being unresponsive -- so that it's possible for the user to
know to attribute the slowness to the service provider.


On Tue, Dec 6, 2011 at 2:57 PM, Charles Pritchard <chuck@jumis.com> wrote:
> There are now two disposition types: inline and window, I'm considering a
> non-visible type, which would essentially be a zero-height/width inline.
>
> Consider a backup service, the user merely means to backup, or "copy" their
> file, to a service like dropbox, but has no interest in a window popping up,
> nor seeing an <iframe> confirmation.
>
> Is that a consideration worth extending, or should <iframe> be used
> regardless?
>
>
> This is a case most often handled, in the present web, by using OAuth and
> creating a new window when authentication fails (or has not taken place).
>
> In intents, it might be two-fold, having a "login" intent, and a "backup"
> intent.
>
> I've found that OAuth logins are sufficient for checking credentials: I've
> not needed OpenID.
>
> Though sites haven't standardized on an end-point, most APIs have a callback
> that return a user name and associated information.
>
>
> Let me point out that an OAuth login intent is always useful. Even if a user
> has logged in, there's every reason to think they may want to "switch
> users".
> As for this backup concept, again, I don't need to see a popup window every
> single time I choose to backup a file.
>
> While the <iframe> concept works, it's a bit of a kludge. I'd prefer that
> the author check for confirmation from the target intent and display it in a
> more integrated manner, such as saying "All files have been backed up".
> That's not something an end-point has enough information to state.
>
>
> -Charles
>
>
>

Received on Tuesday, 6 December 2011 23:47:34 UTC