- From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
- Date: Mon, 1 Sep 2014 13:57:40 +0000
- To: Anton Vayvod <avayvod@google.com>
- CC: Francois Daoust <fd@w3.org>, "public-webscreens@w3.org" <public-webscreens@w3.org>
Hi Anton, All, On 22 Aug 2014, at 17:32, Anton Vayvod <avayvod@google.com> wrote: > 2) define more states for the presentation session, e.g. add "connecting" state that means the communication channel is being (re)established > > Given that we rely on the page to show some relevant UI (e.g. some "connecting" animation between the time user selected the screen and the presentation has started) and should probably avoid queuing messages by the UA, I'd prefer the latter option as long as we keep it simple enough. That’d bring us on par with the Web Sockets’ .readyState states. Are we able to map the “connecting” (and possibly “disconnecting”) states to all the underlying protocols? As usual, without strong use cases, we should defer extra features for later. Is the “connecting animation” a must use case that the UA couldn’t implement in its chrome instead? Would that be bad UX? I’m trying to draw parallels to the loading indicator browsers have (different for each), but perhaps that’s a bad analogy. Thanks, -Anssi
Received on Monday, 1 September 2014 13:58:33 UTC