Re: Non-visible intents

Offhand, I'd say "no. Notifications almost certainly doesn't cover that case".

* Windows 7 uses a notification to tell you that the wifi network to
which you've connected seems to require additional credentials.
* I've had notifications from Windows and Outlook that my credentials
are bad/expired/expiring.
* Technically, when my credit card is misused, I get a "notification"
from my credit card company.

That said, the notifications I get from each of these are more
persistent than I expect a notification api would be, and yet the
concern is fairly equivalent.

Let's consider a simple case:
1. I /think/ I'm @eBay.
2. I want to make a purchase.
3. It triggers a "transfer-money" action.
4. UA offers me PayPal and Discover as choices.
5. I select Discover.
6. Somehow Discover is configured to automatically dispense simple transactions.
7. Unfortunately, there's something wrong with this transaction.
A. Perhaps eBay wants more money than my preapproved per transaction limit.
B. Perhaps I've hit my monthly limit.
C. Perhaps my card was suspended.
D. Perhaps the merchant is suspect.
8. Discover wants to tell this to me.

Let's make some changes to this scenario:
1a. I'm not buying from eBay, instead it's eBay market place.
1b. I'm actually at eBoy.

I haven't had time to look over the Intents proposal. And I haven't
spent any time reviewing the display bits. I'm hoping to play with a
demo build next week....

On the topic of Notifications... Generally, I believe that we do *not*
want Notifications to outlive the sites which trigger them. It's too
easy for an evil site to do a hit and run notification asking you for
something.

If the site I'm visiting is evil and is trying to con me out of money,
then a system where it can make a request and then navigate away to
prevent me from seeing my wallet provider's complaint/warning would be
bad. Now ideally, Discover would contact me by Phone, and the same
should be said for PayPal, but I don't think all intent providers
would have that provision and some will probably have a reasonable
requirement to express a message that the user will actually see.

Sure, we could require users to allow Intent Providers to have access
to persistent Notifications, but I don't think that's a good
requirement. Some Intent Providers will be truly trusted and
trustworthy, some will just be convenient, transient, hacks, or
hackable/unreliable, but all of them will probably be used by users
without much consideration -- just like the rest of the web.

--
I won't have time this week to reply to other messages on the list
(short vacation starting Wednesday night and I generally send my
replies after work).

On 12/6/11, Charles Pritchard <chuck@jumis.com> wrote:
> 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
>>>
>>>
>>>
>>
>
>

-- 
Sent from my mobile device

Received on Wednesday, 7 December 2011 04:25:54 UTC