- From: Josh Soref <jsoref@rim.com>
- Date: Mon, 16 Apr 2012 16:00:30 +0000
- To: "public-web-intents@w3.org" <public-web-intents@w3.org>
Greg Billock wrote:
>That's next on my list of things to send. :-)
>Glenn, does the ability to use defaults satisfy your concerns? I agree
>that sending users to an empty picker is a non-starter. We're pretty
>hesitant about any kind of isRegistered due to the super-cookie
>implications. For use cases we've thought about, the transformation is
>something like this:
>if (isRegistered(my intent)) {
> // do intents!
>} else {
> // do something;
>}
>to
>my intent.setDefault(whatever the fallback would have been);
>do Intents!
Glenn wrote:
> So Greg/Josh correct if I am wrong, the intent.setDefault is fired after the
> window.navigator.startActivity function is called, but only if no registered
> matching verb/data type is found.
No no no.
The web page calls intent.setDefault before it tries to trigger an Intent.
When it triggers an Intent, the user sees a list of choices or whatever of which its default/fallback thing is listed.
Thus the user can trigger the fallback. If the user selects the fallback, the fallback intent is triggered just as any other intent would be triggered.
Consider this use case:
User visits your site on Monday and wants to take an action. They will visit your site again on Tuesday and want to take a similar action. We do not want the UX to change significantly between Monday and Tuesday.
So...
User visits your site on Monday.
A1. You call setDefaults -- with a list of intent providers (intent tags, urls to intent provider pages, not really decided, Greg hasn't formalized the proposal).
A2. You call startActivity
A3. The UA shows the user the Intent provider picker, which since they've never visited any provider would have been rather empty without your setDefaults call (the UA may auto search or something, but).
A3i. The UA uses your setDefaults call to identify providers and populates the list based on them
A4. The user picks a provider
A5. The UA loads the intent from that Provider
A6. The user completes the activity
A7. The useragent formally learns the intent provider (maybe, maybe after a few visits to that provider)
User visits your site again on Tuesday
B1. You call setDefaults -- with a list of intent providers (presumably you haven't changed the list, but maybe you have, your previous suggestions aren't generally preserved)
B2. You call startActivity
B3. The UA shows the user the Intent provider picker, which has the one provider the user picked (A4) and learned (A7) it would be rather empty without your setDefaults call.
B3i. The UA uses your setDefaults call to identify providers and adds to the list based on them
B4. The user picks a provider
B5. The UA loads the intent from that Provider
B6. The user completes the activity
B7. The useragent formally learns the intent provider (maybe, maybe after a few visits to that provider)
Eventually the UA for this user will probably decide that it doesn't need to include your Defaults suggestions because the user has found providers the user likes. This may happen by Friday, or not. The UA won't tell you that it's ignoring your suggestions, you don't need to know that, all you care is that the user has the ability to choose something, and you've helped the UA ensure that.
A fancy UA may even give users a hint about things it's going to stop showing (fading the items out for the last n times before it hides them). But this is all QoI/differentiation/experimentation.
Most importantly, we do not want the UX to change significantly between the day when the user first visits the site and the day when the user picks their favorite Intent provider. If we do that, it'd be a shock to the user, which would be bad.
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Received on Monday, 16 April 2012 16:01:15 UTC