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 

 * 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 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 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 

 - Maybe use a different icon

 - Reserve a space for minimized windows in the overview - perhaps something 

    +--------+ +-------+  
    |        | |       |
    +--------+ +-------+
        |         +
      +---+ +---+ +--+
      |   | |   | |  |
      +---- +---+ +--+
   So then the other windows would smoothly animate to their overview positions 
   the minimized windows would just "be there" in the overview.

 - Animate minimized windows toward the reserved space instead of towards the 

   (we could even show the minimized windows on the background of the root 
   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.


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

Reply via email to