Re: Window controls for GNOME 3

On Wednesday, 02 March, 2011 05:36 AM, William Jon McCann wrote:
Hey Sandy,

On Tue, Mar 1, 2011 at 10:54 AM, Sandy Armstrong
<sanfordarmstrong gmail com> wrote:
(What happened to your mail client line-wrapping settings?)

On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor <otaylor redhat com> wrote:
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 generally applaud the bold changes happening in the shell, but I
disagree with removing the maximize/restore button.  I'll paste here a
comment I wrote on Allan's blog:

1) Drag-and-drop is very difficult on touchpads, and most people these
days are buying laptops. Drag-and-drop is also undiscoverable.
That depends a lot on the quality of the touchpad too... With a crappy
touchpad (and there are a lot of them) it is arguably harder to aim
precisely to hit a small button than dragging a large object
(titlebar) to a Fittsian infinite edge (top of screen).  This is made
worse when the maximize button is immediately adjacent to a button
that is as opposite in effect as you can get.  Two bits of badness
converge here.

The first is that the cost of a slip in aiming and clicking is
unreasonably large.  There is no undo for window close.  It is
definitely not what you wanted to happen.  It is relatively difficult
to recover from.  And in some cases may result in data loss.  In every
case it results in intense frustration (argh-ing).  We don't want the
user to ever feel that.

The second is the stress involved in aiming at a small target which is
intensified by a known cost of a slip.  It makes you think.  The
interface ideally should not interrupt you and draw that kind of
attention to itself.

These issues were always present in classic window management but
become highly problematic with many touch interfaces and especially so
with low precision pointing devices.

There are three other things that should help in these cases:

 * using the entire titlebar as a double click target to maximize
 * using keyboard shortcuts for maximization
 * in some cases maximizing certain sovereign apps by default
(particularly on smaller screens)

2) Double-clicking the title-bar is undiscoverable.
Honestly, I think "discoverability" is one of the more misused
critiques of user interface design.  There are a lot of reasons for
this and I won't cover them.  I don't think that discoverability is a
prerequisite for a successful interface.  Surely, in many cases it
helps.  But it is just one factor.  Gestures (especially touch) aren't
discoverable and yet they are extremely useful and powerful.  
Gestures, even me a power user, do not use them. I have to focus on the task, rather than to discover a gesture which may very difficult to do first time. The shortcut method and the easiest thing is to click on the symbolic icon.
menus aren't discoverable and yet they provide a way to access lots of
functionality that couldn't otherwise be presented in the visible and
discoverable interface. 
*menus are presented because they will present you _tons_ of options that cannot be implemented using symbols, maybe the reason is the lack of space, but I doubt, the MS Office folks will argue you against that.
 Keyboard shortcuts obviously aren't
discoverable most of the time.  As you mention above, drag and drop of
any kind is not discoverable and yet it has formed the basis of many
very successful designs. 
Drag and drop is a special kind of event, that may or can never be presented using symbols. Like drag an object to X, Y coordinates, how can you do that using symbols?
 Discoverability almost always involves
learning.  You are not born knowing what the "_" icon in every window
means.  Nor do you intrinsically know what "maximize" means.  You
learned it at some point.
And we are born that way, generally presented by _ [] X buttons. Other operating systems presented these symbols where the current design in GS is with only a close symbol.
Another trend you are seeing is a bit of a drift away from symbolic
representation and indirect action to more tactile direct
manipulation.  I think this is natural.  It feels better somehow.  
Care to have examples?
if it just does that thing I don't need to know the name for that
thing.  When I throw a window at the top of the screen it gets bigger.
 I wanted it to get bigger.  Cool. 
Yes, the current GS of maximizing/restoring a window is exactly the same in Windows 7 yet they still present those traditional buttons. You know the reason _why_.
 I don't have to even know the word
for it in tech speak is maximize or know that it is symbolically
represented by a square.

I don't have any plans to drop the symbolic close button but some
successful designs have done this already.  WebOS uses a close gesture
and no on screen explicit controls.
That's the beauty of Smart Phones, some things need to be copied from smart phones to the desktop and vice versa, just like what OSX was currently doing with their Lion preview, but did they abolish those trad. buttons?
  iOS on iPad mostly does away will
all forms of window management but in some cases (secondary windows)
uses a "Done" button instead of the symbolic version.
Done is the same to Close in terms of understanding what they means. I'm done with this window(click done!) =  I will close this window because I am done with it (click close). Pointless!
To summarize, discoverability is only one of the considerations in
designing a successful interface.  In this case, it wasn't the most
important factor.  But if you simply cannot get used to life without
the maximize button, despite the benefits, or using one of the other
approaches mentioned above, feel free to add the button back using the
Default should be the default.
Hope that helps a bit.
In my opinion, you do not present a stronger argument why _ [] X symbols needs to go away. These symbols, my suggestion, needs to stay, at least []X symbols.  Someone posted this at Mageia list:
The Linux community spends too much of its energy on things 
such as nomenclature (like the name GNU/Linux versus Linux).
                                           -- John C. Dvorak

Wonder why Linux wasn't as successful on the desktop like other OSes?

gnome-shell-list mailing list
gnome-shell-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]