- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 12 May 2011 14:34:45 -0400
On 5/12/11 1:43 PM, Aryeh Gregor wrote:
> On Thu, May 12, 2011 at 2:25 AM, Robert O'Callahan<robert at ocallahan.org> wrote:
>> It seems rational to me: click on fullscreen, the video fills the entire
>> window (but not the screen), and some browser UI appears to suggest going
>> the rest of the way.
>
> This sounds really bad to me. The user shouldn't have to be prompted.
> Just make sure that you only do it in response to user action (like
> with window.open()), and hitting most keys will leave fullscreen mode,
> and you display a message like "Fullscreen mode, hit ESC to exit" for
> a couple of seconds at the top. That's basically what Flash does,
> right? Does that cause problems? I'm pretty sure we all agree that
> prompting the user is horrible UI and should be avoided wherever
> possible.
To be clear, we are NOT designing the UI for this thing here. I'm not a
UI designer. Robert is not a UI designer. As far as I know, you are
not a UI designer.
We are trying to design an API that could then have a variety of UIs
built on top of it as needed. The key is to design an API that does not
overconstrain those UIs and does not generate mistaken web developer
expectations due to them observing (or theorizing) some particular
subset of possible UIs.
Discussion of possible UIs is only useful here insofar as it informs our
decisions about what assumptions the API should allow web developers to
make.
So let's try attacking the problem from that angle. I posit that for
web developers the following are bad assumptions and that the API should
make it clear that they are bad assumptions:
1) Your page will automatically go into fullscreen when you ask it to
2) After you ask your page to go into fullscreen, you are guaranteed a
response within time T (for some finite T) indicating whether this
has happened.
3) You can figure out whether the user has decided that your site
should never be able to go into fullscreen (exposing that
information increases the fingerprintability of the browser, so
I suspect at least some browsers would not want to expose it).
Are there any other such assumptions we need to steer clear of? Are
there assumptions in the list above that people think are reasonable
assumptions for web developers to make? If so, please speak up; I think
we'll have a better chance at getting somewhere in this discussion if we
can at least agree on our premises!
-Boris
Received on Thursday, 12 May 2011 11:34:45 UTC