View modes: more precision on fullscreen

[Robin Berjon-2]

Hi,

it seems to me that there's a missing distinction in our list of view  
modes: the difference between maximised and fullscreen (or perhaps  
fullscreen and all-screen).

Maximised is the case in which the application takes up the entire  
available screen space minus a little bit of chrome either for itself  
(a window bar with a title and perhaps some buttons) or for the system  
(task bar, menu clock, etc.); whereas fullscreen is when the viewport  
is the same size as the screen (e.g. for video playback).

Both desktops and phones tend to have this distinction in one way or  
another, so it sounds to me as something that we should expose as well.

WDYT?

--
Robin Berjon - http://berjon.com/

[Marcin Hanclik]

Hi Robin,

+1.
The mode in VMMF could be added, are we going to change P&C as well?
The "all" value from P&C is a catch-all value.

Thanks,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: [phone]  |  Fax: [phone]
Mobile: [phone]
E-Mail: marcin.hanclik@...

-----Original Message-----
From: public-webapps-request@... [mailto:public-webapps-request@...] On Behalf Of Robin Berjon
Sent: Monday, October 05, 2009 12:03 PM
To: public-webapps WG
Subject: View modes: more precision on fullscreen

Hi,

it seems to me that there's a missing distinction in our list of view
modes: the difference between maximised and fullscreen (or perhaps
fullscreen and all-screen).

Maximised is the case in which the application takes up the entire
available screen space minus a little bit of chrome either for itself
(a window bar with a title and perhaps some buttons) or for the system
(task bar, menu clock, etc.); whereas fullscreen is when the viewport
is the same size as the screen (e.g. for video playback).

Both desktops and phones tend to have this distinction in one way or
another, so it sounds to me as something that we should expose as well.

WDYT?

--
Robin Berjon - http://berjon.com/





________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

[Robin Berjon-2]

Hi Marcin,

On Oct 5, 2009, at 12:12 , Marcin Hanclik wrote:
> The mode in VMMF could be added, are we going to change P&C as well?
> The "all" value from P&C is a catch-all value.

I'd rather avoid changing P+C unless we need to — VMMF should be the  
superseding document on this topic.

--
Robin Berjon - http://berjon.com/

[Marcin Hanclik]

Hi Robin,

OK.
E.g. "all" is currently not in VMMF, I am adding it now.
What do you mean by "superseding" in this context?
Shall we assume that VMMF will change (invalidate or possibly only add) P&C in this matter?

Thanks,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: [phone]  |  Fax: [phone]
Mobile: [phone]
E-Mail: marcin.hanclik@...

-----Original Message-----
From: Robin Berjon [mailto:robin@...]
Sent: Monday, October 05, 2009 12:59 PM
To: Marcin Hanclik
Cc: public-webapps WG
Subject: Re: View modes: more precision on fullscreen

Hi Marcin,

On Oct 5, 2009, at 12:12 , Marcin Hanclik wrote:
> The mode in VMMF could be added, are we going to change P&C as well?
> The "all" value from P&C is a catch-all value.

I'd rather avoid changing P+C unless we need to - VMMF should be the
superseding document on this topic.

--
Robin Berjon - http://berjon.com/




________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

[Marcos Caceres-3]

2009/10/5 Robin Berjon <robin@...>:

> Hi,
>
> it seems to me that there's a missing distinction in our list of view modes: the difference between maximised and fullscreen (or perhaps fullscreen and all-screen).
>
> Maximised is the case in which the application takes up the entire available screen space minus a little bit of chrome either for itself (a window bar with a title and perhaps some buttons) or for the system (task bar, menu clock, etc.); whereas fullscreen is when the viewport is the same size as the screen (e.g. for video playback).
>
> Both desktops and phones tend to have this distinction in one way or another, so it sounds to me as something that we should expose as well.
>
> WDYT?
>

I think application mode already covers this if the application is
maximized as you defined it.



--
Marcos Caceres
http://datadriven.com.au

[Marcos Caceres-3]

2009/10/5 Robin Berjon <robin@...>:
> Hi Marcin,
>
> On Oct 5, 2009, at 12:12 , Marcin Hanclik wrote:
>>
>> The mode in VMMF could be added, are we going to change P&C as well?
>> The "all" value from P&C is a catch-all value.
>
> I'd rather avoid changing P+C unless we need to — VMMF should be the superseding document on this topic.
>

I'd prefer to drop the keywords relating to view modes from P&C and
just reference VMMF. I don't know if "all" belongs is VMMF or not. I
guess it does, but it's really a default hint for the user agent.
Also, I'm wondering if "all" should really just be "any". I guess that
is a bike shed, however.

--
Marcos Caceres
http://datadriven.com.au

[Robin Berjon-2]

On Nov 1, 2009, at 18:06 , Marcos Caceres wrote:

> 2009/10/5 Robin Berjon <robin@...>:
>> it seems to me that there's a missing distinction in our list of  
>> view modes: the difference between maximised and fullscreen (or  
>> perhaps fullscreen and all-screen).
>>
>> Maximised is the case in which the application takes up the entire  
>> available screen space minus a little bit of chrome either for  
>> itself (a window bar with a title and perhaps some buttons) or for  
>> the system (task bar, menu clock, etc.); whereas fullscreen is when  
>> the viewport is the same size as the screen (e.g. for video  
>> playback).
>>
>> Both desktops and phones tend to have this distinction in one way  
>> or another, so it sounds to me as something that we should expose  
>> as well.
>
> I think application mode already covers this if the application is
> maximized as you defined it.

If application is maximised, then what is the keyword that describes a  
window that has chrome but isn't occupying the entirety of the space  
that windows can?

--
Robin Berjon - http://berjon.com/

[Marcos Caceres-3]

On Mon, Nov 9, 2009 at 12:26 PM, Robin Berjon <robin@...> wrote:

> On Nov 1, 2009, at 18:06 , Marcos Caceres wrote:
>>
>> 2009/10/5 Robin Berjon <robin@...>:
>>>
>>> it seems to me that there's a missing distinction in our list of view
>>> modes: the difference between maximised and fullscreen (or perhaps
>>> fullscreen and all-screen).
>>>
>>> Maximised is the case in which the application takes up the entire
>>> available screen space minus a little bit of chrome either for itself (a
>>> window bar with a title and perhaps some buttons) or for the system (task
>>> bar, menu clock, etc.); whereas fullscreen is when the viewport is the same
>>> size as the screen (e.g. for video playback).
>>>
>>> Both desktops and phones tend to have this distinction in one way or
>>> another, so it sounds to me as something that we should expose as well.
>>
>> I think application mode already covers this if the application is
>> maximized as you defined it.
>
> If application is maximised, then what is the keyword that describes a
> window that has chrome but isn't occupying the entirety of the space that
> windows can?

That would be 'application', but not maximized.



--
Marcos Caceres
http://datadriven.com.au

[Robin Berjon-2]

On Nov 9, 2009, at 13:05 , Marcos Caceres wrote:

> On Mon, Nov 9, 2009 at 12:26 PM, Robin Berjon <robin@...>  
> wrote:
>> On Nov 1, 2009, at 18:06 , Marcos Caceres wrote:
>>> 2009/10/5 Robin Berjon <robin@...>:
>>>> it seems to me that there's a missing distinction in our list of  
>>>> view
>>>> modes: the difference between maximised and fullscreen (or perhaps
>>>> fullscreen and all-screen).
>>>>
>>>> Maximised is the case in which the application takes up the entire
>>>> available screen space minus a little bit of chrome either for  
>>>> itself (a
>>>> window bar with a title and perhaps some buttons) or for the  
>>>> system (task
>>>> bar, menu clock, etc.); whereas fullscreen is when the viewport  
>>>> is the same
>>>> size as the screen (e.g. for video playback).
>>>>
>>>> Both desktops and phones tend to have this distinction in one way  
>>>> or
>>>> another, so it sounds to me as something that we should expose as  
>>>> well.
>>>
>>> I think application mode already covers this if the application is
>>> maximized as you defined it.
>>
>> If application is maximised, then what is the keyword that  
>> describes a
>> window that has chrome but isn't occupying the entirety of the  
>> space that
>> windows can?
>
> That would be 'application', but not maximized.

Uh, but those can be two different windowing modes, with the chrome  
subtly different and different behaviour (e.g. the window can't be  
dragged if maximised).

Or are you thinking about this in terms of the broken OSX UI that  
can't tell the difference? If so, I strongly object — it's a usability  
nightmare.

--
Robin Berjon - http://berjon.com/

[Marcos Caceres-3]

Robin Berjon wrote:

> On Nov 9, 2009, at 13:05 , Marcos Caceres wrote:
>> On Mon, Nov 9, 2009 at 12:26 PM, Robin Berjon <robin@...> wrote:
>>> On Nov 1, 2009, at 18:06 , Marcos Caceres wrote:
>>>> 2009/10/5 Robin Berjon <robin@...>:
>>>>> it seems to me that there's a missing distinction in our list of view
>>>>> modes: the difference between maximised and fullscreen (or perhaps
>>>>> fullscreen and all-screen).
>>>>>
>>>>> Maximised is the case in which the application takes up the entire
>>>>> available screen space minus a little bit of chrome either for
>>>>> itself (a
>>>>> window bar with a title and perhaps some buttons) or for the system
>>>>> (task
>>>>> bar, menu clock, etc.); whereas fullscreen is when the viewport is
>>>>> the same
>>>>> size as the screen (e.g. for video playback).
>>>>>
>>>>> Both desktops and phones tend to have this distinction in one way or
>>>>> another, so it sounds to me as something that we should expose as
>>>>> well.
>>>>
>>>> I think application mode already covers this if the application is
>>>> maximized as you defined it.
>>>
>>> If application is maximised, then what is the keyword that describes a
>>> window that has chrome but isn't occupying the entirety of the space
>>> that
>>> windows can?
>>
>> That would be 'application', but not maximized.
>
> Uh, but those can be two different windowing modes, with the chrome
> subtly different and different behaviour (e.g. the window can't be
> dragged if maximised).

That's UA/OS dependent.

> Or are you thinking about this in terms of the broken OSX UI that can't
> tell the difference? If so, I strongly object — it's a usability nightmare.

Exactly, so stop imposing your dirty Vi command-line view of the world
on the rest of us, Robin! :)

But seriously, I don't think we need to get to the level where we are
specifying behavior. It should just be enough to say chrome off, chrome
on. If chrome on, do as you do in your OS. If chrome off and fullscreen,
then you _may_ do as we say - fullscreen is bla bla.

[Robin Berjon-2]

On Nov 9, 2009, at 16:41 , Marcos Caceres wrote:
>>> That would be 'application', but not maximized.
>>
>> Uh, but those can be two different windowing modes, with the chrome
>> subtly different and different behaviour (e.g. the window can't be
>> dragged if maximised).
>
> That's UA/OS dependent.

How it is implemented is UA/OS/UI dependent, but it doesn't mean that  
there isn't a semantic difference. The differences are:

   - show me alongside other apps (windowed mode)
   - show me, no other app, but keep the OS UI (maximised)
   - show me, and nothing else (fullscreen)

I'm happy for implementers to map the values we list to whatever makes  
sense on their platform, but we need to at least have a vocabulary  
that covers the more common modes. All versions of Windows in recent  
memory as well as most Linux windowing managers support the three  
levels above, only OSX believes that it's a good idea to annoy people  
who are two pixels off in clicking on the scrollbar. Without the three  
levels above, we can't capture the most usual windowing semantics.

>> Or are you thinking about this in terms of the broken OSX UI that  
>> can't
>> tell the difference? If so, I strongly object — it's a usability  
>> nightmare.
>
> Exactly, so stop imposing your dirty Vi command-line view of the  
> world on the rest of us, Robin! :)

Actually, I'm thinking of usable click-and-drool UIs as my primary use  
case.

> But seriously, I don't think we need to get to the level where we  
> are specifying behavior.

No, but we do need a level of semantic description that matches  
typical UIs.

--
Robin Berjon - http://berjon.com/

[Marcos Caceres-3]

Robin Berjon wrote:

> On Nov 9, 2009, at 16:41 , Marcos Caceres wrote:
>>>> That would be 'application', but not maximized.
>>>
>>> Uh, but those can be two different windowing modes, with the chrome
>>> subtly different and different behaviour (e.g. the window can't be
>>> dragged if maximised).
>>
>> That's UA/OS dependent.
>
> How it is implemented is UA/OS/UI dependent, but it doesn't mean that
> there isn't a semantic difference. The differences are:
>
> - show me alongside other apps (windowed mode)
> - show me, no other app, but keep the OS UI (maximised)
> - show me, and nothing else (fullscreen)

Right.

> I'm happy for implementers to map the values we list to whatever makes
> sense on their platform, but we need to at least have a vocabulary that
> covers the more common modes. All versions of Windows in recent memory
> as well as most Linux windowing managers support the three levels above,
> only OSX believes that it's a good idea to annoy people who are two
> pixels off in clicking on the scrollbar. Without the three levels above,
> we can't capture the most usual windowing semantics.

I agree. I wonder if we can leverage some text from CSS. However, it
should not be too hard to specify this.

>>> Or are you thinking about this in terms of the broken OSX UI that can't
>>> tell the difference? If so, I strongly object — it's a usability
>>> nightmare.
>>
>> Exactly, so stop imposing your dirty Vi command-line view of the world
>> on the rest of us, Robin! :)
>
> Actually, I'm thinking of usable click-and-drool UIs as my primary use
> case.
>
>> But seriously, I don't think we need to get to the level where we are
>> specifying behavior.
>
> No, but we do need a level of semantic description that matches typical
> UIs.

Agreed.