Re: Window controls for GNOME 3
- From: William Jon McCann <william jon mccann gmail com>
- To: Sandy Armstrong <sanfordarmstrong gmail com>
- Cc: Owen Taylor <otaylor redhat com>, gnome-shell-list gnome org
- Subject: Re: Window controls for GNOME 3
- Date: Tue, 1 Mar 2011 16:36:53 -0500
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. Context
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. 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. 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.
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. And
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. 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. 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.
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
settings.
Hope that helps a bit.
Jon
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]