Window Controls on the Right Side

[Matthew Paul Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

john.r.moser at gmail.com wrote on 14/05/15 04:06:
> 
> On 05/01/2015 10:52 AM, Matthew Paul Thomas wrote:
> 
> ...
>> There have been dozens of desktop computer OS manufacturers less 
>> successful than Apple -- for example, Acorn, Be, Commodore, 
>> Google, IBM, Sun, and every company that has ever released an OS 
>> based on Gnome or KDE. "Broadly marketed" is assuming the 
>> question -- the
> 
> For decades? Standing side-by-side with Dell in Best Buy and 
> CompUSA? With their own stores?  All over the news, pervasive 
> throughout culture?

You are assuming exactly the same question again. That they were less
successful is precisely why they weren't broadly marketed for decades.
And that has pretty much nothing to do with window controls.

> ...
> 
>>> Back in 10.04, Ubuntu tried moving the controls to the left. 
>>> This met with huge resistance, largely in the form of 
>>> complaining, whining, and people putting the controls back 
>>> where they belong.
>> 
>> That is similarly assuming the question. The only reason you 
>> think "the controls ... belong" on the right is that around
>> 1993, someone at
> 
> I have given the ergonomic definition.

Which makes several unfounded assumptions. Most notably, that more
users of Ubuntu -- which was originally focused on notebooks, and has
always been preinstalled most often on notebooks -- use mice (where
rotating to the right may indeed be easier) rather than touchpads,
trackballs, and pointing sticks combined (where extending a bent
pointing finger to the left is probably easier). And that window state
changes are more frequent and/or hurried than other functions that
could occupy the same area.

>> In both Windows and OS X, putting the controls all on one side 
>> (a) increases the risk that you'll close a window when you mean 
>> to minimize or maximize it,
> 
> The argument is about putting all the controls on the left instead 
> of the right.  In that context, you risk closing the window when 
> you operate the locally-integrated menu.

You are still assuming that "all the controls" belong on one side at
all. I was demonstrating that that assumption, too, is unfounded.

>> (b) makes centered titles look imbalanced in the title bar,
> 
> No different if all controls are on the left; and, generally, the 
> least-important thing anyone could say on the topic.

Again, you are wrongly assuming that "all controls are on" one side or
the other.

>> and (c) causes ugliness when a window doesn't have maximize 
>> and/or close functions, because you end up with buttons that are 
>> either permanently insensitive (as in Windows and OS X) or 
>> inconsistently-placed (as in Ubuntu).
> 
> This is not solved by moving buttons around.

Yes it is, if there is one subtle extra rule: an unminimizable window
can't be maximizable either. Then if you have minimize and close at
opposite ends, and maximize next to minimize, all the possible
combinations of those three controls avoid all three problems I described.

> ...
>> 
>> Apart from the Fitts's-Law-derived conclusions that the easiest 
>> pixels to hit are (a) the one you're at right now and (b) the 
>> four corners, I'm not aware of any research on this. Do you know 
>> of any?
> 
> Hold your right arm out straight in front of you, with the fingers 
> extended in line with the forearm.
> 
> Now, tilt your wrist thirty degrees to the right.  That's easy, 
> yes? It's a wide range of motion.

Again, you're assuming that most Ubuntu users use mice.

> ...
> 
>>> A year later, in 11.04, Ubuntu released the Global Menu. Three 
>>> days before 15.04, Ubuntu reversed a decision to disable the 
>>> Global Menu by default, after preening themselves with talk 
>>> about the new Locally Integrated Menus--i.e. pre-11.04, 
>>> non-Apple menus.
>> 
>> As far as I know, there was no "decision" to disable global
>> menus by default in 15.04, it was just a mistake.
> 
> They accidentally set bug #1412297 as "Fix Released" as well.

As is clear from the bug report, it was supposed to be Kylin-only.

>> Locally Integrated Menus are a red herring: they don't solve the 
>> primary problem of menus being invisible by default.
> 
> Long ago, I went on some long rant about multiple mouse clicks 
> required to access a visible window's menus when using global 
> menus. Nobody believed me.

Maybe it was something to do with it being a rant.

> You suggest the intellectually disjoint argument that every 
> window's menu should be visible by default, but that putting the 
> menu in the window is the wrong solution.  This is a generous 
> assumption on my part:  all other things you could possibly
> suggest would be ridiculous, and indicate a deluded mind afflicted
> with some form of mental illness.

Then this is the single most important thing for you to learn from
this exchange: If it seems that someone is either "intellectually
disjoint" or mentally ill, your first hypothesis should be that you
misunderstood them. Because if you suggest either of the other two --
or even worse, both -- and you're wrong, you'll look like a churl.

When I said "menus being invisible by default" I was referring to them
being invisible except when you hover over them.

> I cannot believe you would suggest having a separate window 
> floating on the screen, eating screen real estate, with a list of 
> menus arbitrarily put together somewhere away from their respective
> windows; or that you would suggest a global menu that drops down a
> list of windows, which you can follow through as a menu tree to
> access all menus; or some other form of bizarre distortion.  This
> must simply be a comment put forth without sufficient
> consideration.

Similarly, either politeness or a quick Web search could have saved
you from the embarrassment of suggesting that it was "put forth
without sufficient consideration". I gave it extensive consideration
five years ago. <http://design.canonical.com/2010/05/menu-bar/>

(In retrospect, the funny part of that was the thought that it would
be just for netbooks. We're pretty sure that it would work for
displays of all sizes, because it does in OS X; but as I said at the
time, "the Ambiance and Radiance themes will need to do a much better
job of distinguishing between focused and unfocused windows". Little
did I know how long that would take.)

>> Last month's SRU introducing the com.canonical.Unity 
>> always-show-menus setting is a first step toward solving it, but 
>> long-term, having a setting for something like that would 
>> demonstrate indecision.
>> 
> My boy, did your old granddad ever tell you about the day we used 
> to have something called "Customizability"?  Why, they even let us 
> set our own desktop background on the old computers.

Ah yes, the days when much design was done by engineers and managers
who shrugged and communicated in their settings dialogs, "We don't
know how to design software. Why don't you have a go?" And when, as a
result, people were often -- justifiably! -- afraid of breaking their
computer by accidentally changing settings that shouldn't have existed
in the first place. People are willing to pay for the privilege of not
making decisions like those.

Unlike menu bar positioning, the background picture is an example of
something that people are likely to have an informed opinion about,
and something that gives many of them a greater sense of ownership.
(But to reinforce the point of this having scant relationship to
success in the market, the iPhone didn't have a customizable home
screen background for its first three years, and managed to be a wild
success anyway.)

>>> ...
>> 
>>> First, if the window is maximized, the menu is obviously in the
>>> same place on the screen.  If not, you have multiple windows,
>>> and it takes *two* *mouse* *clicks* to click a menu.
>> 
>> That isn't correct. It takes 1 + n clicks, where n = the 
>> probability that the menu item you want is for a window
>> different from the focused one. So, probably about 1.1 clicks on
>> average, varying depending on the kind of work you're doing.
> 
> I should have specified that I was referencing an unfocused 
> window.

Which would make the question irrelevant. Most of the time people use
menus, they are using menus belonging to the focused window.

> ...
>> 
>>> Canonical has been backpedaling on Global Menus for several 
>>> releases, giving configuration options, then heavily 
>>> considering just turning that crap off.  They have not come
>>> out and claimed anything about good UI design; they've just 
>>> shuffled around uncomfortably.
>> 
>> Yes, we're in an Uncanny Valley between in-window and global 
>> menus. In-window menus are horrendously slow.
> 
> So fix your rendering system.

It's nothing to do with the "rendering system", it's a consequence of
Fitts's Law.

> ...
>> 
>> I doubt the "File" menu is the most important universal element, 
>> but yes, putting window controls right next to menus is an 
>> unnecessary risk.
> 
> At least we clearly agree on something.

Hurrah!

> Also:  File->Open.  There's a reason the most familiar buttons in 
> toolbars are Open and Save:  everyone is constantly hitting 
> File->Save, and then we invented toolbars, and we put a floppy disk
> on a button, and people stopped using the File menu.  Mostly.
> 
> ...

On the Mac, the Microsoft Office apps -- copying their Windows
counterparts -- are pretty much the only popular apps that have Open
and Save buttons in their toolbar. It isn't because OS X now has
auto-save built in to the toolkit; that happened only a few years
ago. It's because on the Mac, menus are much easier to use. So
toolbars can concentrate on functions that are distinctive to
individual apps, rather than on functions like Open and Save that are
in the same place in the menus in most apps.

- -- 
mpt

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlVV4zUACgkQ6PUxNfU6ecqfAQCdGIDYy+QDczdD97nJwMuXpX09
nu0An3OVYvJtop62BBjIPCVPgOweCuRO
=3oet
-----END PGP SIGNATURE-----