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