-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 john.r.mo...@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----- -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
