7:49 p.m.
---------- Forwarded message ----------
From: Owen Taylor <otaylor(a)redhat.com>
Date: 2011/2/23
Subject: Window controls for GNOME 3
To: gnome-shell-list(a)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(a)gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list
--
Yu
11:46 p.m.
New subject: [FZH] Window controls for GNOME 3
今天的gnome-shell已经把窗体标题栏上最大最小化按钮去掉了，看样子又开始打口水仗了。
2011/2/23 Yu Chen <jcomee(a)gmail.com>:
---------- Forwarded message ----------
From: Owen Taylor <otaylor(a)redhat.com>
Date: 2011/2/23
Subject: Window controls for GNOME 3
To: gnome-shell-list(a)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(a)gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list
--
Yu
--
Yu
5:23 a.m.
New subject: [FZH] Window controls for GNOME 3
我用的就是 git 版本的 gnome-shell , 怎么没发现变了？
2011/2/23 Yu Chen <jcomee(a)gmail.com>:
今天的gnome-shell已经把窗体标题栏上最大最小化按钮去掉了，看样子又开始打口水仗了。
2011/2/23 Yu Chen <jcomee(a)gmail.com>:
> ---------- Forwarded message ----------
> From: Owen Taylor <otaylor(a)redhat.com>
> Date: 2011/2/23
> Subject: Window controls for GNOME 3
> To: gnome-shell-list(a)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(a)gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>
>
>
> --
> Yu
>
--
Yu
_______________________________________________
Chinese mailing list
Chinese at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/chinese
7:37 a.m.
New subject: [FZH] Window controls for GNOME 3
最小化按钮……如果不提我都快忘记它的存在了……
最大化按钮？所有窗口都是最大化的……
如果 GNOME Shell 实现了多窗口自动平铺（看样子的确是的），那么最大化最小化的确是无用的东西，去掉吧！
On Wed, Feb 23, 2011 at 7:23 PM, microcai <microcai(a)fedoraproject.org> wrote:
我用的就是 git 版本的 gnome-shell , 怎么没发现变了？
2011/2/23 Yu Chen <jcomee(a)gmail.com>:
> 今天的gnome-shell已经把窗体标题栏上最大最小化按钮去掉了，看样子又开始打口水仗了。
>
> 2011/2/23 Yu Chen <jcomee(a)gmail.com>:
>> ---------- Forwarded message ----------
>> From: Owen Taylor <otaylor(a)redhat.com>
>> Date: 2011/2/23
>> Subject: Window controls for GNOME 3
>> To: gnome-shell-list(a)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(a)gnome.org
>> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>>
>>
>>
>> --
>> Yu
>>
>
>
>
> --
> Yu
> _______________________________________________
> Chinese mailing list
> Chinese at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/chinese
>
_______________________________________________
Chinese mailing list
Chinese at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/chinese
--
Take a Deep Breath out of Windows
https://fedoraproject.org/wiki/User:Lovenemesis
6:48 a.m.
New subject: [FZH] Window controls for GNOME 3
1。为什么菜单栏还依旧保留着？应该如windows7那样隐藏多好
2。在左上角的任务按钮一直弄的人不明白，尤其是为什么他是把一个图标显示某一部分？
2011/2/23 Tommy He <lovenemesis(a)fedoraproject.org>
最小化按钮……如果不提我都快忘记它的存在了……
最大化按钮？所有窗口都是最大化的……
如果 GNOME Shell 实现了多窗口自动平铺（看样子的确是的），那么最大化最小化的确是无用的东西，去掉吧！
On Wed, Feb 23, 2011 at 7:23 PM, microcai <microcai(a)fedoraproject.org>
wrote:
> 我用的就是 git 版本的 gnome-shell , 怎么没发现变了？
>
> 2011/2/23 Yu Chen <jcomee(a)gmail.com>:
>> 今天的gnome-shell已经把窗体标题栏上最大最小化按钮去掉了，看样子又开始打口水仗了。
>>
>> 2011/2/23 Yu Chen <jcomee(a)gmail.com>:
>>> ---------- Forwarded message ----------
>>> From: Owen Taylor <otaylor(a)redhat.com>
>>> Date: 2011/2/23
>>> Subject: Window controls for GNOME 3
>>> To: gnome-shell-list(a)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(a)gnome.org
>>> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>>>
>>>
>>>
>>> --
>>> Yu
>>>
>>
>>
>>
>> --
>> Yu
>> _______________________________________________
>> Chinese mailing list
>> Chinese at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/chinese
>>
> _______________________________________________
> Chinese mailing list
> Chinese at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/chinese
>
--
Take a Deep Breath out of Windows
https://fedoraproject.org/wiki/User:Lovenemesis
_______________________________________________
Chinese mailing list
Chinese at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/chinese
4808
days inactive
4811
days old
chinese@lists.fedoraproject.org
4 comments
4 participants
participants (4)
-
Dee.H.Y -
microcai -
Tommy He -
Yu Chen