[FZH] Window controls for GNOME 3

[Yu Chen]

今天的gnome-shell已经把窗体标题栏上最大最小化按钮去掉了，看样子又开始打口水仗了。

2011/2/23 Yu Chen <jcomee在gmail.com>:
> ---------- Forwarded message ----------
> From: Owen Taylor <otaylor在redhat.com>
> Date: 2011/2/23
> Subject: Window controls for GNOME 3
> To: gnome-shell-list在gnome.org
>
>
> 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
>
>
>
> --
> Yu
>



-- 
Yu