RE: Updated Presentation API WebIDL - call for review

Hi Anssi,

The File picker dialog on iPads will be displayed in the place where you touch the screen (inside the input element boundaries) --> See screenshots. In my point of view, I don't think it is a good idea to touch the HTML stuff otherwise we need to speak with HTML Group and then we will lost the focus on our original work. One possible option from my side (if we agree that the location of the screen piker dialog is important for better user experience)  is to add optional input parameter for  requestSession indicating the preferred position of the dialog. Browsers may ignore this parameter. 

Best regards,
Louay

> -----Original Message-----
> From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com]
> Sent: Freitag, 21. März 2014 14:04
> To: Mark Watson
> Cc: Mark Finkle; Rottsches, Dominik; public-webscreens@w3.org
> Subject: Re: Updated Presentation API WebIDL - call for review
> 
> Hi Mark, All,
> 
> On 14 Mar 2014, at 16:12, Mark Watson <watsonm@netflix.com> wrote:
> 
> [...]
> 
> >> MarkW - do you think this addresses your concern?
> >
> > Almost. The file picker is a good example, because here the UA knows
> > which page element triggers the dialog (the <input> element) and so it
> > can do the right thing for the platform, as you say.
> 
> None of the platforms I actively interact with seem to correlate the file picker's
> location on the screen with that of the <input> element that triggered it. The
> picker is always located in the same platform-defined location regardless of the
> location of the <input> element. Actually, I'm surprised to say that, because I'd
> guess it might improve the usability if they'd be correlated somehow.
> 
> Or is that what you meant by "do the right thing"?
> 
> > But in the present Presentation API there is nothing that tells the UA
> > which page element the user clicked to trigger the selection dialog:
> > the site just uses a button and the dialog is triggered by calling a
> > platform method from script. So the UI context is not known to the UA
> > and it cannot 'do the right thing'.
> 
> Given the above observation, do you think the requirement for spatially
> correlating the element which triggered the operation is a must? (This assumes
> there is an element similar to HTMLInputElement, which we don't have
> currently. Or alternatively, do something like [1] -- replace click() with
> requestSession() and you'll get the idea.)
> 
> > If we had <button type='screens'> then the UA would know.
> 
> To sum this up, I think we're discussing two things we should address
> separately:
> 
> 1) Spatial correlation: correlating the location of the picker UI and the element
> that triggered it.
> 2) Temporal correlation: programmatic vs. user-initiated invocation to bring up
> the picker UI.
> 
> My take on the first one given the evidence of the <input type="file"> is that we
> do not need to be able to correlate the two. If you feel otherwise, I'd like to
> hear use cases that are compatible with the established interaction models of
> the Web.
> 
> For the second, I'd say the app should be able to programmatically request a
> session (invoke requestSession()) which in turn will bring up the picker UI (if the
> user does not have a prearranged trust relationship with the screen. that is).
> This is aligned with the way how many other Web APIs behave that interact
> with devices (I'm not saying this is a perfect patterns), cuts down the required
> number of clicks the user must make. It'd be interested to get some usability
> data on the alternative, anyone?
> 
> All - WDYT?
> 
> To not to lose the context, the WebIDL we're reviewing is at [2].
> 
> Thanks,
> 
> -Anssi
> 
> [1] https://developer.mozilla.org/en-
> US/docs/Using_files_from_web_applications#Using_hidden_file_input_element
> s_using_the_click()_method
> 
> [2] https://www.w3.org/community/webscreens/wiki/API_Discussion#WebIDL