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!"

Comments

Best suggestion

[Jeremy Erwin]

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.

Re:#5 Menu Bar is enough reason to not change

[big.ears]

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.

Also...

[billbaggins]

They seem to have taken some pains to make sure it Does The Right Thing. At least, check out this part about file extensions from here...

Any file with the hide extension flag set and a known extension has that extension hidden in the Finder. When users edit the name of such a file, they edit only the user-visible portion. If they explicitly type in a known file name extension for the file, either the Finder warns them that what they're doing may change the type of the file (if they enter a different file name extension), or the Finder changes the state of the hide extension flag to show the extension (if they enter a new file name with the proper, currently hidden extension for the file). In all cases, the Finder allows users to make the changes if they wish. What users see in the Finder is what they typed when renaming the file, whether or not they included an extension.

In other words, if you want to see a file extension, you'll see a file extension. If you don't see a file extension, and you type one, you'll see the new one, and it will be used, and the old discarded if necessary. Contranst Windows, where if extension-hiding is on, and you type the name "index.html" for a file currently named "index.htm", the result is a file named "index.html.htm"... that is to say, the Wrong Thing.

I wish Apple would follow their own guidelines

[Tim Browse]

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.

Re:A bit hypocritical...

[DavidRavenMoon]

...for an Apple Dev site to chide "poor" UI designs when their own site needs dome fixin'. For starters, the tips menu items hang over the boundaries of the box beneath them.

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.