From kde-look Sun Apr 30 01:58:04 2000 From: Dave Leigh Date: Sun, 30 Apr 2000 01:58:04 +0000 To: kde-look Subject: Re: PROPOSAL: "Mac" menubar as default X-MARC-Message: https://marc.info/?l=kde-look&m=95705988431395 Steven, you've done an admirable job of trying to make a convincing point, but in my case at least, it simply doesn't work. I'm not intending to be argumentative here, so forgive me if it seems that way. But you did ask for sensible objections elsewhere, and I'm assuming that such objections would be welcome here as well. You say quite a lot to undermine your own argument; for instance, "What's one more thing to learn?" applies equally well to the minority of Mac users that need to learn that the menu is attached to the window. And, "If you want Windows, you know where to find it," is simply unrealistic. If they want Windows chances are will find it already installed on the machine. And hopefully, a large percentage of future users ARE going to be ex-Windows users, well into the future. Windows currently enjoys 82% of the world PC operating systems market, according to the data reported in this morning's newspaper. They are not all going to defect next year or the year after. It is suicide to ignore that. If these users continue to hear about inconsistencies and "this application doesn't work well with KDE because" FUD, then they will have just that much less incentive to switch. As a piece of strategic advice, the proper procedure for capturing such a market is to offer something similar, but with advantages. Offer more advantages (but less similarity) as an option. When more users prefer the more advantageous option, THEN make it the default. KDE is on the right track for long-term dominance, and I think you're being too impatient. At this time, users should be offered an OS that is both best AND familiar, but there is still debate as to whether the menubar at the top is actually "best," as you've no doubt noticed by now. Nor are usability studies conclusive. For example: > And its a matter of record, proven by usability studies, that top of > screen menus are up to five times faster than window menus. Even > Microsoft has acknowledged this, in their Office applications in > full-screen mode, by having the menubar move up into the top of screen > position. An Office application in full-screen mode (a single-application interface) is WORLDS apart from a situation where you've got a half-dozen or more applications scattered about the screen sharing a menubar that is physically divorced from the windows. Note that in a full-screen Office app, the menubar is at the top in full-screen mode by virtue of the fact that there is no need for window widgets, border, or titlebar. And you'll find that it's still firmly and physically connected to the app to which it belongs. In other words, you're reading WAY too much into that menu position, and the comparison is totally inappropriate. Something that IS demonstrably appropriate is the new positioning of the dialog boxes in OS X. They are firmly attached to the application to which they belong. Why? According to Apple, "Mac OS X introduces new panels that attach themselves to documents and make their relationship clear (you can even have multiple interleaved documents, each with its own print or save panel open simultaneously)." Obviously, if this visual connection is important for dialogs, you have to ask yourself why it is not important for menus? Obviously Apple is not immune to inconsistencies of either thought or design. Look at the picture, http://www.apple.com/macosx/desktop.html. Three applications are show, each having a different colored titlebar. Now imagine this on a desktop in which "focus follows mouse" is active. Which application is current? Without looking for subtle clues like the color of the tiny aqua buttons, it's not clear. Given attached menus, it doesn't matter, because you'd immediately know what menu function affected what app. Fitt's Law is not a sufficient reason for having the menu at the top of the screen, and the appeal to this authority is being invoked far too often, IMHO. In the current context, it is not a Law, merely an Observation (reasons enumerated below). As has been stated numerous times over the months, there are some real disadvantages to Mac-style menus, presented here in no particular order: 1. Travel-time back to the application is not considered. In most applications, it's desirable to keep your attention focused on the task at hand... in otherwords, on the window. If you're using large amounts of real estate and have multiple windows open, Mac-style menus FORCE the users' attention away from the application, which is a Bad Thing. 2. Productivity is not a speed-clicking contest; speed is not the be-all and end-all of a desirable UI. Users do not typically race to the corner to see how fast they can get to this or that particular option. They carefully consider their actions and work at a reasonable, not breakneck, pace. The phrase "UP TO five times faster" is important: it's not an average, and I can toss my mouse in the corner of the screen with the best of 'em. Unfortunately, most application functionality is NOT accessed from the corner menu, and while those on the edge of the screen can be accessed somewhat faster than a randomly placed target, the difference is much less than the "five times" figure commonly advertised. 3. It is far more important that the options be arranged logically, and that the user be aware of their location. You indicate that it doesn't take much practice for the user to learn that the menu is always at the top of the screen. It takes just as little practice to learn that the menu's RIGHT HERE, attached to the window on which his attention is already focused. I can tell you from many years of experience in training users that it doesn't take anywhere near "a couple of days of solid use" for even the most green computer user. 4. As I've already mentioned, Apple's own work with regard to dialog boxes (or "panels") indicates that it is important to the users that the functionality of an application be associated with the application itself. There is a strong suggestion in these results, as well as from practical experience with every GUI environment other than the Mac, that similar benefits (non-speed related benefits of comprehensibility and usability) are obtained from associating the menubar with the application. No evidence has been offered to contradict this. 5. Non-KDE applications can't use them. This enables inconsistent behavior *by default*, and we hear too many of those very legitimate complaints from Unix/Linux detractors to purposely add to them. 6. Most operating environments place the menus with the application window, and that's where most of the users expect it. It's not a "Windows vs. Mac" thing, nor can it be argued that menus at the top are better because Mac does it, or better because Microsoft doesn't. The BEST that can be argued is that it's a personal preference. Given that it's a minority preference (5% of the existing market or so) in a market that at the present time needs to insinuate itself into heterogeneous computing environments it seems counter-productive to make the preference of such a small minority the default. > The opposite suggestion was also made by some. KDE should try to stand > out. Its not a clone of Windows. It stands for what's best, not what > Microsoft does. The only criticism of KDE I have come across is that > "its a clone of Windows, and not a very good one at that". This is > bunk, of course, and especially odious considering that Windows' look > and feel is a poor clone of MacOS. This view wasn't from some Windows > newbie, but from a very technically minded cross platform developer, > who uses all three major platforms (Unix, Windows, Mac). It's important to recognize the difference between valid criticism and FUD. When don't change a good design on the basis of FUD. And since you've noticed that the statement is bunk, there's no need to react emotionally to it. > Top of screen menus would allow KDE to answer this by saying "we take > what's best, from any platform", while still reassuring nervous IT > managers "of course KDE has menus just like Windows". Just that you > have to click a checkbox to enable them. KDE already answers this by offering alternatives and options. The minority that wants them can have them. But it makes far more sense to dispell the nervousness of the IT managers you mention by showing that the default behaviour is already what they want. The remainder of your arguments don't really add a lot to what's already been discussed and they smack more than a little bit of callousness ("They just have to learn to live with a certain amount of difference." is callous, just as is, "If you want Windows, you know where to find it."). I can certainly appreciate the sentiment Torsten expressed earlier with regard to this. The point is, when you stop thinking about the users, you lose credibility. This is clearly more about your preferences than the users' benefit. I'm sorry to put it that bluntly, but I've been long-winded enough already. Summing it all up, to foist a great deal of inconsistency and callous behaviour on the users by defaulting to a minority preference of disputed value is just plain wrong. -- mailto:dave.leigh@cratchit.org http://www.cratchit.org/dleigh