Re: FAMIUM Implementations of the Presentation API

Hi Louay,

On 02 Sep 2014, at 14:28, Bassbouss, Louay <louay.bassbouss@fokus.fraunhofer.de> wrote:

[...]

> The only difficulty was in the Display Selection Dialog. We don't want to touch the DOM and create a custom dialog using HTML/CSS. This is why we use the native JavaScript dialogues confirm() and prompt() for display selection.

I believe this is something that can be improved in a native implementation. confirm(), prompt() are interesting artefacts that have been around since 90s, but have known usability issues (e.g. they’re modal, blocking). The UI aspects are out of scope for the spec, and thus we do not mandate a specific UI style. However, what we must do is to make sure the API does not limit the UI/UX options.

It’d be interesting to see more innovation in terms of the UI aspects as well, and this is actually a discussion that the wider web community is having currently. Without going into details, here’s an example of a UI problem (without pointing fingers at any browser vendor, I could have taken a similar screenshot from any other browser):

https://raw.githubusercontent.com/dontcallmedom/web-permissions-req/gh-pages/screenshots/all-chromium.png

> For other platforms/protocols where native implementation is required we developed connectors that allow the JavaScript Code to speak with the native/ platform-dependent components. The development of Demo applications was straightforward. From the experience gained in the development of the Presentation API and Demo Applications we can confirm that the most features discussed in the Mail thread "Google/Mozilla Presentation API update" will improve the Presentation API from Developer and End-user (Usability) perspectives especially reconnecting or joining existing sessions.

Good to get validation that the proposed changes improve the API.

Thanks for the feedback!

-Anssi

Received on Friday, 5 September 2014 08:26:42 UTC