From: Owen Taylor < otaylor redhat com>
To: gnome-shell-list gnome org
Subject: Window controls for GNOME 3
Date: Tue, 22 Feb 2011 19:21:08 -0500 (EST)
OK, I promised Jon McCann to write a mail here giving information on my thoughts on
removing the minimize and maximize buttons since I've been resisting the request of the
designers to remove these buttons.
My main objection to removing them has been that I didn't think we really understood the
use case for minimization, or how we would satisfy that use case. The pattern of use for
minimization is that a lot of people don't use minimization at all, and other people use
it extensively.
It didn't make sense to me to remove something that we don't understand with idea that
we'd add it back later if it turned out to be needed. To make people suffer, and have it
be a major focus of the GNOME 3 transition, then go and add it back anyways.
On the other hand, if we do have a reasonable sense that we have workflows that basically
will work for everybody, then I'm more comfortable removing minimization. So, this mail
is reporting on my attempt to come to a better understanding of minimization and how it
fits in with the GNOME 3 workflow.
Why do people minimize windows?
===============================
I think the first thing to realize is that minimization doesn't make sense if you
maximize everything. If you run everything maximized, then it just doesn't enter in ...
switching between windows is switching between windows. (I personally typically maximize
everything, so I don't minimize windows.)
Reasons people minimize:
* Because they like a tidy desktop. I think a lot of people are uncomfortable with
a desktop where the window the are working with is overlapping other windows - where
they are looking at a "gigantic pile of papers". These people like working with a few
windows on a clean desktop. But they still have a larger set of windows open for less
immediate tasks.
* Because maximized windows interact badly with unmaximized windows. If I have a
task that involves looking at multiple unmaximized windows, then I switch to a
maximized web browser, getting back to the other state is hard - I have to select
each window in turn without accidentally selecting the maximized window again.
* To find a window behind other windows - if you generally select windows by
clicking on them, and can't see the window or windows want, minimization can be
a way of getting a big or maximized window out of the way and working with the
windows underneath.
* To "save windows for later" - if you open windows to represent tasks, like
responding to an email or reading a PDF of a paper, you might not want them
directly in your face interfering with the work you are doing first.
Are workspaces a replacement for minimization?
==============================================
Since minimization is basically about wanting to work with a subset of windows,
workspaces are clearly related to them. As compared to minimization they have
advantages and disadvantages. The advantage is that they are stable - that is,
I can have one workspace with a terminal and an editor, and another workspace
with a web browser and my mail program and they will always stay that way - I
won't lose the grouping. The disadvantage is that it isn't flexible - if I need
the editor and web browser open at once then I have to go to the Activities
Overview and move the web browser, and then my web browser and mail program can't
be open at once until I move it back.
Experiences with removing the minimize button
=============================================
I asked the two people on the Red Hat GNOME Shell team who I knew heavily used
the minimize button to try removing it and report back to me about their
experiences. (These obviously are not typical users using typical applications,
but they provide some data about how people actually use the minimize button.)
Marina:
Marina generally used the minimize button when switching between a) coding
on the shell with non-maximized terminal and editor windows b) doing tasks
in a maximized web browser. She would minimize the web browser
to get from a) to b) and then use the overview to get back to the minimized
web browser.
When she turned off the minimize button, she was initially very frustrated
because she kept going to where the minimize button was but finding only
the "useless" close button there. She then turned off the close button as
well and was much happier with the result. [I don't think this is
really an option however - there are going to be too many cases where apps
are designed expecting a close button.]
No problems were reported with:
- Having the maximized web browser window still visible under the coding
windows... this was reported to not be distracting.
- Having to separately activate the editor and terminal windows from
the overview.
Workspaces were found not to be useful because they didn't allow to
easily switch between working with a fullscreen webbrowser, to
using a non-full-screen web browser in conjunction with an editor for
patch review.
Dan:
Dan normally keeps xchat, terminal, and emacs in a fixed layout,
and then uses unminimization and minimization to temporarily switch
from the terminal/emacs task to mail or web browser tasks.
He also uses minimization to save web pages opened for patch reviews
for doing later.
Dan reported that he was able to successfully switch to a setup
where web browser and email were on separate desktops. He didn't feel
it was an improvement, but he also didn't feel a strong urge to
go back to the previous setup. He did report feeling isolated when
on a workspace with only web or only email.
Dan often opens links in separate web browser windows, so to do the
patch review tasks that frustrated Marina's use of workspaces, he would
open the review link from email in a separate window and then move
that window to his coding window.
He found after using it for a while that the most effective way
to save windows for later use was to reserve a desktop for that
and move windows to be saved to that desktop.
Problems with current minimization
==================================
* Many people (most people?) never minimize. So one of the most prominent permanent
controls is something that has no particular function but makes your window vanish if
hit accidentally.
* There is no real mental model for what happens when hiding. The window shrinks off to
the corner, but when you go back to the overview, it's still there and looks the same as
if you hadn't hid it.
* The minimize icon is a remnant of the GNOME 2 taskbar and has nothing to do with the
GNOME 3 experience. (Really, we don't have minimization at all, we have "hiding")
* Having minimize and maximize controls puts "stress" on the concept of the centered
title - the titlebar looks unbalanced.
* If people are using minimization within GNOME Shell as an alternative to things that
could be done with workspaces, then we have to design other components for two different
workflows - the minimization workflow and the workspaces workflow.
* Minimized windows break the illusion of zooming to the overview.
Is removing the button really removing minimization?
====================================================
You can still minimize with:
- Right click on titlebar to get to the window menu
- Alt-right click on window contents to the window menu
- Alt-F9
- Alt-space n
But, no, for all real purposes removing the button is removing minimization.
Could we design an improved "hiding" model
==========================================
I think there are some things we could do that would make minimization less weird.
- Maybe use a different icon
- Reserve a space for minimized windows in the overview - perhaps something like:
+--------+ +-------+
| | | |
+--------+ +-------+
+---------+
| +
+---------+
+---+ +---+ +--+
| | | | | |
+---- +---+ +--+
So then the other windows would smoothly animate to their overview positions and
the minimized windows would just "be there" in the overview.
- Animate minimized windows toward the reserved space instead of towards the corner
(we could even show the minimized windows on the background of the root window
in the main view and return back to the days of twm???)
But at this point, we're out of time to experiment with anything for GNOME 3.0. Also
this doesn't address minimization being unused by many users and having two different
workflows for working with a subset of windows.
The maximize button
===================
The above was about minimization - but the request was also to remove the maximize
button. This is a little different since there are more obvious ways to maximize a
window - the drag to the top gesture or double-clicking on the title bar - we're not
really talking about removing the feature of maximization but just the button.
I don't think it's generally a big deal to remove the maximize button. Trying it
myself, I did find one problematical area - it's pretty hard to distinguish between
a mostly maximized and maximized window but they behave quite differently. I think
there are some adjustments we could make to help with that - one one in particular
is making sure when you unmaximize we actually shrink the window by a significant
amount and don't leave it screen sized.
The way forward
===============
I'm going to openly admit here that I'm a bit uncertain.
Until we got the new workspaces controls, removing the minimize button was impossible;
it took away a workflow, and left only a very hard to use alternative. With a better model
for working with workspaces, there is evidence it might work, but we're working from a
very limited data set and we don't have much runway left to adjust before GNOME 3.0.
Other considerations against removing window controls: no minimize leaves us further
away from Mac and Windows and removing the minimize button in the fallback mode would
work much less well, since the overview isn't available to quickly and conveniently switch
to a hidden window.
On the other hand, if we leave minimization, we have something that is clearly undesigned
and unfinished. And we portray the taskbar as something that is missing rather than
something that is unneeded, because we have a window hiding icon that was designed for
minimizing to the taskbar.
In the end, I think with GNOME 3 we need to emphasize design coherency and slickness -
what is different and better, and that actually is more important than being 100% sure
we perfectly meet everybody's workflow. Having half-designed minimization is going against
the goal of coherency. And doesn't provide testing of alternate workflows. So I'm going to
remove the minimize and maximize buttons for GNOME 3.0, and if it doesn't work out, we'll
eat crow, design window hiding right, and add it back for 3.2.
Feedback?
=========
If people want to give their thoughts here, that's fine, but I don't think a mailing list
debate is the best way to come to a decision, so the decision above should be considered
basically final for the 3.0 release.
The real form of feedback that we need going from GNOME 3.0 to 3.2 is careful observation
of how users are using GNOME 3 - are they figuring out how to use the overview and
workspaces and message tray as we expect them to use them, or are they doing cumbersome
workarounds because we took away essential features.
- Owen
From: Marina Zhurakhinskaya
To: Owen Taylor
Cc: gnome-shell-list gnome org
Subject: Re: Window controls for GNOME 3
Date: Tue, 22 Feb 2011 21:48:50 -0500 (EST)
As Owen described, I found it relatively easy to change my workflow to not use
minimization. It does make more sense to use a positive action for switching to a
different window I want, rather than a negative action of minimizing and then seeing
what I have in front of me.
I found it very useful to remove the close button as well. I originally did that to
wean myself off going for the minimize button and not finding it there, but I'm also
wondering whether we can get rid of this one-of icon completely. We've added two other
ways for closing windows/applications in GNOME 3: a per-window close icon in the
overview and a quit option in the application menu. The only thing that is missing
is the UI ability to close an individual window from the desktop view. I mostly used
the Quit option in the application menu for closing single instance applications, such
as calculator or gconf-editor, but I had to remember to go to the overview if I wanted
to close a Firefox Downloads window or an individual gedit window I no longer needed.
I think having a second option "Close Window" in the application menu if the
application has multiple windows would solve this problem and allow us to get rid of
the visual clutter of a lone close icon in the titlebar.
If anyone wants to try it out without the close icon in the titlebar, just run
' gconftool-2 -s -t string /desktop/gnome/shell/windows/button_layout "" ' and
restart gnome-shell.
Marina
----- Original Message -----
From: "Owen Taylor"
To: gnome-shell-list gnome org
Sent: Tuesday, February 22, 2011 7:21:08 PM
Subject: Window controls for GNOME 3
OK, I promised Jon McCann to write a mail here giving information on my thoughts on
removing the minimize and maximize buttons since I've been resisting the request of
the designers to remove these buttons.
My main objection to removing them has been that I didn't think we really understood the
use case for minimization, or how we would satisfy that use case. The pattern of use for
minimization is that a lot of people don't use minimization at all, and other people use
it extensively.
It didn't make sense to me to remove something that we don't understand with idea that
we'd add it back later if it turned out to be needed. To make people suffer, and have
it be a major focus of the GNOME 3 transition, then go and add it back anyways.
On the other hand, if we do have a reasonable sense that we have workflows that basically
will work for everybody, then I'm more comfortable removing minimization. So, this mail
is reporting on my attempt to come to a better understanding of minimization and how it
fits in with the GNOME 3 workflow.
Why do people minimize windows?
===============================
I think the first thing to realize is that minimization doesn't make sense if you
maximize everything. If you run everything maximized, then it just doesn't enter in ...
switching between windows is switching between windows. (I personally typically maximize
everything, so I don't minimize windows.)
Reasons people minimize:
* Because they like a tidy desktop. I think a lot of people are uncomfortable with a
desktop where the window the are working with is overlapping other windows - where they
are looking at a "gigantic pile of papers". These people like working with a few windows
on a clean desktop. But they still have a larger set of windows open for less immediate
tasks.
* Because maximized windows interact badly with unmaximized windows. If I have a task
that involves looking at multiple unmaximized windows, then I switch to a maximized
web browser, getting back to the other state is hard - I have to select each window in
turn without accidentally selecting the maximized window again.
* To find a window behind other windows - if you generally select windows by clicking
on them, and can't see the window or windows want, minimization can be a way of getting
a big or maximized window out of the way and working with the windows underneath.
* To "save windows for later" - if you open windows to represent tasks, like responding
to an email or reading a PDF of a paper, you might not want them directly in your face
interfering with the work you are doing first.
Are workspaces a replacement for minimization?
==============================================
Since minimization is basically about wanting to work with a subset of windows,
workspaces are clearly related to them. As compared to minimization they have advantages
and disadvantages. The advantage is that they are stable - that is, I can have one
workspace with a terminal and an editor, and another workspace with a web browser and
my mail program and they will always stay that way - I won't lose the grouping. The
disadvantage is that it isn't flexible - if I need the editor and web browser open at
once then I have to go to the Activities Overview and move the web browser, and then my
web browser and mail program can't be open at once until I move it back.
Experiences with removing the minimize button
=============================================
I asked the two people on the Red Hat GNOME Shell team who I knew heavily used
the minimize button to try removing it and report back to me about their experiences.
(These obviously are not typical users using typical applications, but they provide
some data about how people actually use the minimize button.)
Marina:
Marina generally used the minimize button when switching between a) coding
on the shell with non-maximized terminal and editor windows b) doing tasks
in a maximized web browser. She would minimize the web browser
to get from a) to b) and then use the overview to get back to the minimized
web browser.
When she turned off the minimize button, she was initially very frustrated
because she kept going to where the minimize button was but finding only
the "useless" close button there. She then turned off the close button as
well and was much happier with the result. [I don't think this is
really an option however - there are going to be too many cases where apps
are designed expecting a close button.]
No problems were reported with:
- Having the maximized web browser window still visible under the coding
windows... this was reported to not be distracting.
- Having to separately activate the editor and terminal windows from
the overview.
Workspaces were found not to be useful because they didn't allow to
easily switch between working with a fullscreen webbrowser, to
using a non-full-screen web browser in conjunction with an editor for
patch review.
Dan:
Dan normally keeps xchat, terminal, and emacs in a fixed layout,
and then uses unminimization and minimization to temporarily switch
from the terminal/emacs task to mail or web browser tasks.
He also uses minimization to save web pages opened for patch reviews
for doing later.
Dan reported that he was able to successfully switch to a setup
where web browser and email were on separate desktops. He didn't feel
it was an improvement, but he also didn't feel a strong urge to
go back to the previous setup. He did report feeling isolated when
on a workspace with only web or only email.
Dan often opens links in separate web browser windows, so to do the
patch review tasks that frustrated Marina's use of workspaces, he would
open the review link from email in a separate window and then move
that window to his coding window.
He found after using it for a while that the most effective way
to save windows for later use was to reserve a desktop for that
and move windows to be saved to that desktop.
Problems with current minimization
==================================
* Many people (most people?) never minimize. So one of the most prominent permanent
controls is something that has no particular function but makes your window vanish if
hit accidentally.
* There is no real mental model for what happens when hiding. The window shrinks off
to the corner, but when you go back to the overview, it's still there and looks the same
as if you hadn't hid it.
* The minimize icon is a remnant of the GNOME 2 taskbar and has nothing to do with the
GNOME 3 experience. (Really, we don't have minimization at all, we have "hiding")
* Having minimize and maximize controls puts "stress" on the concept of the centered
title - the titlebar looks unbalanced.
* If people are using minimization within GNOME Shell as an alternative to things that
could be done with workspaces, then we have to design other components for two different
workflows - the minimization workflow and the workspaces workflow.
* Minimized windows break the illusion of zooming to the overview.
Is removing the button really removing minimization?
====================================================
You can still minimize with:
- Right click on titlebar to get to the window menu
- Alt-right click on window contents to the window menu
- Alt-F9
- Alt-space n
But, no, for all real purposes removing the button is removing minimization.
Could we design an improved "hiding" model
==========================================
I think there are some things we could do that would make minimization less weird.
- Maybe use a different icon
- Reserve a space for minimized windows in the overview - perhaps something like:
+--------+ +-------+
| | | |
+--------+ +-------+
+---------+
| +
+---------+
+---+ +---+ +--+
| | | | | |
+---- +---+ +--+
So then the other windows would smoothly animate to their overview positions and
the minimized windows would just "be there" in the overview.
- Animate minimized windows toward the reserved space instead of towards the corner
(we could even show the minimized windows on the background of the root window
in the main view and return back to the days of twm???)
But at this point, we're out of time to experiment with anything for GNOME 3.0. Also
this doesn't address minimization being unused by many users and having two different
workflows for working with a subset of windows.
The maximize button
===================
The above was about minimization - but the request was also to remove the maximize
button. This is a little different since there are more obvious ways to maximize a
window - the drag to the top gesture or double-clicking on the title bar - we're not
really talking about removing the feature of maximization but just the button.
I don't think it's generally a big deal to remove the maximize button. Trying it
myself, I did find one problematical area - it's pretty hard to distinguish between
a mostly maximized and maximized window but they behave quite differently. I think
there are some adjustments we could make to help with that - one one in particular
is making sure when you unmaximize we actually shrink the window by a significant
amount and don't leave it screen sized.
The way forward
===============
I'm going to openly admit here that I'm a bit uncertain.
Until we got the new workspaces controls, removing the minimize button was impossible;
it took away a workflow, and left only a very hard to use alternative. With a better
model for working with workspaces, there is evidence it might work, but we're working
from a very limited data set and we don't have much runway left to adjust before
GNOME 3.0.
Other considerations against removing window controls: no minimize leaves us further
away from Mac and Windows and removing the minimize button in the fallback mode would
work much less well, since the overview isn't available to quickly and conveniently
switch to a hidden window.
On the other hand, if we leave minimization, we have something that is clearly
undesigned and unfinished. And we portray the taskbar as something that is missing
rather than something that is unneeded, because we have a window hiding icon that
was designed for minimizing to the taskbar.
In the end, I think with GNOME 3 we need to emphasize design coherency and slickness -
what is different and better, and that actually is more important than being 100% sure
we perfectly meet everybody's workflow. Having half-designed minimization is going
against the goal of coherency. And doesn't provide testing of alternate workflows.
So I'm going to remove the minimize and maximize buttons for GNOME 3.0, and if it
doesn't work out, we'll eat crow, design window hiding right, and add it back for 3.2.
Feedback?
=========
If people want to give their thoughts here, that's fine, but I don't think a mailing
list debate is the best way to come to a decision, so the decision above should be
considered basically final for the 3.0 release.
The real form of feedback that we need going from GNOME 3.0 to 3.2 is careful
observation of how users are using GNOME 3 - are they figuring out how to use the
overview and workspaces and message tray as we expect them to use them, or are they
doing cumbersome workarounds because we took away essential features.
- Owen
_______________________________________________
gnome-shell-list mailing list
gnome-shell-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list
From: Federico Mena Quintero
To: Marina Zhurakhinskaya
Cc: gnome-shell-list gnome org
Subject: Re: Window controls for GNOME 3
Date: Wed, 23 Feb 2011 10:12:41 -0600
On Tue, 2011-02-22 at 21:48 -0500, Marina Zhurakhinskaya wrote:
> We've added two other ways for closing windows/applications in GNOME
> 3: a per-window close icon in the overview and a quit option in the
> application menu. The only thing that is missing is the UI ability to
> close an individual window from the desktop view. I mostly used the
> Quit option in the application menu for closing single instance
> applications, such as calculator or gconf-editor, but I had to
> remember to go to the overview if I wanted to close a Firefox
> Downloads window or an individual gedit window I no longer needed.
Be careful with this line of thinking. You are replacing a one-step,
common operation with a two-step one that is not immediately
discoverable.
It's like saying, "well, we could show the current window's title next
to the Activities button, and since you can already move windows with
Alt-drag, we can remove titlebars altogether" :)
In general, sleek looks just for the sake of sleek looks are not good.
Things have to be comfortable to use. A knife's handle has an awkward
shape, but the bump in the front is so your hand doesn't slip forward
and you get cut; the bump in the back is so you can pull out the knife
easily; the bump in the center is to accomodate the inside of your palm.
A knife with a sleek, cylindrical handle wouldn't be very nice to use.
Federico
From: Marina Zhurakhinskaya
To: Federico Mena Quintero
Cc: gnome-shell-list gnome org
Subject: Re: Window controls for GNOME 3
Date: Wed, 23 Feb 2011 16:34:00 -0500 (EST)
While the close operation is common, it's not frequent, and therefore might not require
visual representation on-screen all the time. Similar reason to why we don't want to
have application launchers on screen all the time.
Both the application menu in the top bar and the close buttons in the overview are well
discoverable. Right now, the application menu has one Quit option, and the user actually
needs to make a decision whether they want to fully quit the application with all its
windows before going for that option. Having both Quit and Close Window (if applicable)
options in that menu would inform the user of the choice they have and allow to use that
feature as the central way of closing a window or an application. It's a menu that is
visible in the desktop view, so it's more of 1.5 step operation with a click - move to
the option you want - release.
So the goal would be removing a full UI concept and centralizing the options related
to the operation in another existing part of UI. That would make the application menu
more functional, inform the user better, reduce redundant options, AND make for a sleeker
look :).
Marina
----- Original Message -----
From: "Federico Mena Quintero"
To: "Marina Zhurakhinskaya"
Cc: gnome-shell-list gnome org
Sent: Wednesday, February 23, 2011 11:12:41 AM
Subject: Re: Window controls for GNOME 3
On Tue, 2011-02-22 at 21:48 -0500, Marina Zhurakhinskaya wrote:
> We've added two other ways for closing windows/applications in GNOME
> 3: a per-window close icon in the overview and a quit option in the
> application menu. The only thing that is missing is the UI ability to
> close an individual window from the desktop view. I mostly used the
> Quit option in the application menu for closing single instance
> applications, such as calculator or gconf-editor, but I had to
> remember to go to the overview if I wanted to close a Firefox
> Downloads window or an individual gedit window I no longer needed.
Be careful with this line of thinking. You are replacing a one-step,
common operation with a two-step one that is not immediately
discoverable.
It's like saying, "well, we could show the current window's title next
to the Activities button, and since you can already move windows with
Alt-drag, we can remove titlebars altogether" :)
In general, sleek looks just for the sake of sleek looks are not good.
Things have to be comfortable to use. A knife's handle has an awkward
shape, but the bump in the front is so your hand doesn't slip forward
and you get cut; the bump in the back is so you can pull out the knife
easily; the bump in the center is to accomodate the inside of your palm.
A knife with a sleek, cylindrical handle wouldn't be very nice to use.
Federico
From: Federico Mena Quintero
To: Marina Zhurakhinskaya
Cc: gnome-shell-list gnome org
Subject: Re: Window controls for GNOME 3
Date: Thu, 24 Feb 2011 13:31:36 -0600
On Wed, 2011-02-23 at 16:34 -0500, Marina Zhurakhinskaya wrote:
> While the close operation is common, it's not frequent, and therefore
> might not require visual representation on-screen all the time.
Huh, I use the Close button pretty frequently. I guess I'm still
scarred from when Esc didn't work in every dialog by default.
> Both the application menu in the top bar and the close buttons in the
> overview are well discoverable. Right now, the application menu has
> one Quit option, and the user actually needs to make a decision
> whether they want to fully quit the application with all its windows
> before going for that option. Having both Quit and Close Window (if
> applicable) options in that menu would inform the user of the choice
> they have and allow to use that feature as the central way of closing
> a window or an application.
My main problem with removing the Close button is a combination of
things:
- The Close button is relevant to a single window. It's nicely *in* the
window right now. Your proposal would put it far away from the window
(thus losing context), and would make it not immediately visible (you'd
need to open the app menu first - probably discoverable, as you say, but
far from obvious). My experience with non-technical users (say, my
wife) is that if they don't see something on the screen, they won't know
that that something is actually available.
- The Close button is the "get me out of here" safety exit. You
wouldn't remove the Back button on a browser just because you can also
access it from the menus.
Federico