Re: Non-visible intents

Does the notifications mechanism work for this?



On Dec 6, 2011, at 3:46 PM, Greg Billock <gbillock@google.com> wrote:

> 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 Wednesday, 7 December 2011 01:27:23 UTC