RE: Is discovery good enough for wider use cases

 
>On Thu, Apr 12, 2012 at 1:15 PM, Josh Soref <jsoref@rim.com> wrote:
>> Glenn wrote:
>>> This week I reviewed the roadmap for the 200 sites my company manages and I
>>> wrote-off implementing Web Intents for the share buttons. The reason being if
>>> there is no isRegistered type functionality we don't believe we can deliver the
>>> right level of UX. We don't want to invoke the Web Intents UI unless we know
>>> the user already has a service registered that supports the verb/data type we
>>> are requesting.
>>
>> Suppose that you could provide a fallback handler so that when you triggered the intent (e.g. share), if the user hadn't been to any share providers they would see your share option, would that assuage your concern?
>>
>> I believe that's already in the API as drafted today, it was certainly a point we discussed at the DAP meeting.

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!

>Any other insights into your thinking about intents would be great to
>hear, too!

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. If so that's an interesting approach, it 
would suit a single button pop-up that either invoked the Web Intents UI 
or an alternative JavaScript overlay created in the DOM. 
intent.setDefault(function(){
                    ... Create popup with share options for user
})
 
So the use case we would really want is something like this: We add a number 

of URL share buttons i.e. Twitter, Facebook, Google+ and Linkedin within the 

page as it renders. On page ready we test for web intents and then test to see 

if there is a service registered for the verb/data type. Only then do we use 

JavaScript to remove the proprietary URL share buttons and replace it with 

a single button which can invoke the Web Intents UI.    

 

The main difference seems to be that you have moved the point where you test 

to the first point of user interaction. This resolves the security problems, but does 

not cover the use case above in the way we would like.

If I understand intent.setDefault correctly it's a halfway house. I may be able to 

design something like the idea on slides 6-8 

http://www.slideshare.net/glennjones/web-intentsactions-ux-challenges <http://www.slideshare.net/glennjones/web-intentsactions-ux-challenges> . When 

you click on it the default is called and an overlay is created in the DOM with 

the proprietary share buttons. A bit like the AddThis overlay.

 

For other verb/data type combinations the intent.setDefault may not be as useful. 

It still feels like the security issue has removed the full power of discovery. 

The intent.setDefault helps but only so far. 

 

Thanks

Glenn Jones