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_elements_using_the_click()_method

[2] https://www.w3.org/community/webscreens/wiki/API_Discussion#WebIDL

Received on Friday, 21 March 2014 13:06:40 UTC