Slashdot Mirror
Apple Explains Interface Differences
WCityMike writes "This switch document for developers details the interface differences between Microsoft Windows and the Aqua interface used in Mac OS X. Written on a layman's level, it actually makes for pretty interesting reading!"
was to kill off the windows MDI-- with it's horrendous, ugly grey root window. My ability to use a third party editor with a third party hex editor with my compiler shouldn't be hampered by one designers misguided attempt to use MDI.
Apple has found that using one menu at the very top increases productivity. "What? You're crazy!" you say. No seriously, the theory is (and it is not Apple's theory, they just adhere to it) is that in order to get to a menu item a user can simply throw their cursor to the top of the screen and 'overshoot' the menu because it is at the very top, in this sense the menu is located at a place of infinite height and is very easy to get to. Now think about a Windows setup where the menu is at the top of any respective window, a user must provide a bit of care/control to get to the menu item because it is possible to overshoot the menu. It doesn't take EXTREME care, it is a minor point, but even with distance and proximity involved (menu at top of screen vs. menu at top of window), you'd have to agree that it is easier to simply 'throw' your mouse to the top of the screena and not worry about overshooting it.
I can't agree with some of them. For example :"Don't use non-standard controls".
I agree with you, however... I suspect the reason Apple makes this suggestion is that most developers over estimate their expertise in designing user interfaces. They think, "it makes sense to me" and they write a control that makes no sense at all. Their intimate familiarity with the product and it's intended use makes it difficult for them to imagine the thought process of a new user.
Designing user interfaces is pretty complicated, and requires a lot of thought. Even with this time investment, you still need to do user testing etc on your new control to see if it gets used the way you had hoped. This is true of any new interface, but especially true if that interface is full of non-standard controls. Most software products don't have the resources to devote to this aspect of development.
So yes, an intelligent design with non-standard control *can* work. But you won't go far wrong with the ones that have been carefully thought out and provided for you. As soon as the article say something like "most developers will do better with the standard controls", every developers suddenly feels like he is part of the group that doesn't fall into that category. (Everyone overestimates their own ability.)
The decision was made because of considerations about aimed movement, which was originally codified as a mathematical relationship by Paul Fitts, who stated that times for aimed movements were related to the distance and size of the target in a logarithmic fashion. "Fitts's Law" is not about infinite height, however. It is about the mathematical relationship, and for any new application of the law, the coefficients of the formula need to be estimated. These coefficients will depend on many things, including the acceleration and rate settings on the mouse, the experience of the user, and probably things like how bright things are, the color scheme, how big the monitor is, and how far they are away from the monitor. Thus, it may be possible that in the days of black-and-white ten-inch monitors with big clunky mice, the parameters of Fitts's Law worked out so that you would get an advantage for edge menus. In todays world, with optical mice, 21" LCD displays, multiple monitors, and mouse acceleration, the parameters would be different, and there may no longer be an advantage for edge menus. And if you change your mouse rate, you might just negate any benefit for these menus as well. Of course, the formula is also affected by target size, meaning that the larger icons probably do more for 'productivity' than anything else.
The point is that the research and user testing this design decision was based on is from a different age and time. To believe that it is still a good decision, one would have to show that today's users with today's technology have an advantage. This must be done empirically, because without such testing, we are all just speculating.
"The best argument against democracy is a five minute chat with the average voter."
--Winston Churchill
Well, apart from this document being for developers, and not for the 'layman', I have a couple of issues with it, and they're mainly due to Apple's "Don't do as I do, do as I say" attitude.
For example: #4 Avoid Custom Controls, and #7 Aqua Is In, Grey Is Out.
Go try out iTunes, QuickTime, etc to see how much Apple thinks "Grey is out" (the window background is non-standard, and grey). iTunes and Quicktime also have custom title bars, and custom resizing gadgets. All of these things are already implemented perfectly well by the standard GUI, so why doesn't Apple use them? It's like when Bill Gates exhorted developers to use the common dialogs to keep the user experience consistent, while MS Office didn't use them.
And #5 - Use A Single Menubar is particularly ironic - I doubt very much that anyone porting a Windows app to MacOS would add a menu to their main window (mainly because it's probably quite hard), while Apple should really read and inwardly digest the main points of this article - i.e. when in Rome, do as the Romans do. Anyone remember QuickTime 4? It had a single menu bar on MacOS - and on Windows too! Of course, Windows doesn't have a 'menu bar', so in one of the most impressive displays of pigheadedness and 'not getting it', Apple decided that QuickTime for Windows should create a floating window whose sole purpose was the have a menu on it. Genius - they managed to get all the disadvantages of both systems, and none of the advantages (the menu wasn't attached to the player window).
And #10 - Reconsider Toolbars still has me puzzled. I never have worked out why Mac users are so insistent that palettes are superior to Toolbars. I always find floating palettes to be a pain in the neck to maintain (as a user) and they're always getting in the way of what I'm trying to do. However, I appreciate that both forms of UI are useful, and wouldn't really be able to honestly state that one is better than the other. Besides, run MS Word, drag a toolbar into the middle of the screen, resize it - looks kinda like a floating palette doesn't it? That said, I can understand why they say not to use toolbars - they're not really a part of the MacOS feel, so they tend to stick out. On the other hand, it is interesting the way half the windows in OSX/Finder use toolbars all over the place. I guess if you make the toolbar icons R-E-A-L-L-Y B-I-G then it's ok for some reason.
Don't get me wrong - this is a useful document, if a little preachy and arrogant ("well, clearly, our UI is better than the crap you poor Windows developers have had to put up with, you sad losers..."), but I just wish Apple would follow their own edicts a bit more closely.
However, the best thing to come out of this slashdot article is that I found out that Mr MacKido (the master of reasoned and unbiased argument) doesn't like MacOS X. The thought of him gnashing his teeth about OSX had me chuckling away for ages :)
Tim
PS. For the record, and to pre-empt some formulaic replies to this posting, I mostly use Windows, but also use a Mac, and I don't always have good things to say about Windows.
Not on my system it isn't. I'm viewing it in Mozilla, and the text is inside the boxes.
Also the text is forced to a smaller size than is comfortable to read on screen and by using this size text the bold headline sbecome blurry and even more difficult to read.
Assuming you are using Windows, I find text is far more legible on Macs.
To be fair, I'm guessing they designed their site to be viewed on Apple systems and there is a difference in screen metrics because Macs are basedon a 72dpi resolution while PCS use 96dpi (though they can be changed to anything from 72dpi-144dpi).
That's not the problem. Mac monitors are no longer 72 dpi if you run them at high resolutions. I'm using a 19" Sylvania monitor set at 1280 X 1024. Mozilla's display resolution is 96 dpi, same as on PCs. IE also defaults to 96 dpi.
The real issue is not screen resolution, but the size of fonts on Windows.
A 10 pt font is expected to be 10 points. There are 72 points to an inch (or 2.54 cm). Windows fonts are too large, with 10 points closer to 12 points. I know this because I work in pre-press. This is why the text on websites made on PCs often looks too small on Macs, and vice versa.
-- if it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic - Lewis Carrol
Here are just three observations that come to mind:
There are other problems with the Aqua UI. But the most basic one is perhaps that it is just another toolkit-based GUI--a system in which people produce the same kind of inflexible applications that people produce in the other major toolkits on the other major platforms. The fact that Aqua looks a little prettier and crashes a little less does not get around this basic fact.
Overall, I think what makes Aqua most useful is a desire to keep applications simple. Unlike Windows, Gnome, or KDE, it comes with useful applications are not overburdened with zillions of options; developers of those desktops should take notice.
Actually, to be precise, (and we slashdotters like precise, no?) all previous versions of the Mac OS have recognized both a Creator code and a Filetype code for every single data file. Thus, a file can identify itself as a jpeg, and additionally identifies which application was used to create the file.
This allows for a fascinating and brilliant user interface device, which is so intuitive that most people will never even realize it exists. When you drag a data file icon to an application icon, the application icon only highlights if that particular application believes it can open that particular file type. (If you're lucky enough to be sitting in front of a Mac right now, give it a try by dragging a data file icon to the wrong application.)
Mike van Lammeren
It will challenge your head, your brain, and your mind.