RE: Pick Media Intent Review

Hi Jungkee,

Please find some additional comments inline.

Regards,
	Youenn

> > 1. Media Type Filtering
> > One important filtering case may be based on media types.
> > Requesting images or mp3 may be different. This may lead a user to
> > select
> different providers.
> If a provider supports several media types, the provider may use a different
> initial UI depending on the suggested type: initial view could show 'Music'
> or 'Pictures' folder...
> How would happen that kind of filtering?
> 
> A specific intent is identified with action/type pair and it has a designated URL.
> My intention on the flat style type definition is to keep it simple since service
> providers still can provide intuitive media services shown in the picker.
> 
> For instance, a media service provider, SP-PMI.com, can provide,
>   "PMI Music Repo", at http://SP-PMI.com/audio/
>   "PMI Video Repo", at http://SP-PMI.com/video/
>   "PMI Media Repo", at http://SP-PMI.com/media/ (Providing all three)
> 
> The picker shows all the possible "http://intents.w3.org/type/media" type
> services, and it is a user's choice which specific service (type) she will go for.
> 
> It can be an option to introduce hierarchy in type definition such as,
> http://intents.w3.org/type/media/audio
> but I think it has only a small advantage like reducing the list of services in the
> picker while adding complexity.
 
Fewer choices, especially if relevant, seems nicer to the end-user.
Defaulting rules may be easier to define for user-agents as well, like pick images on flickr, pick music on play.

Also, it seems good design to enable provider or user agent to detect whether a media selected by a user matches the web intent client requirements, before actually sharing that data to the intent client.
If a web intent client only processes mp3 and a user selects an ogg file (or worse, jpeg), the web intent provider may be able to warn the user before sharing the media.

If not passed through the type parameter, which has its own semantics and constraints, that kind of information can fit in the extras dictionary.

> > One straightforward option would be to use the MIME matching type
> parameter filtering capacity.
> > A user agent would be able to filter the number of potential pickers
> > based
> on that parameter.
> 
> I think MIME does not give enough information to distinguish the PMI services
> from other intent services.

Can you elaborate on that?

Received on Tuesday, 31 July 2012 13:03:23 UTC