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!"
Look at the screenshot of the power settings in Windows. The reason it looks like that is because the computer that Apple happened to use for the screen shot did not have the "turn off disk", "standby", and "hibernate" features and as such those things were missing from the screenshot. Had those things been there, then the screenshot would have looked full. Just a little misleading
Well, why didn't the size of the dialog shrink if those features weren't there? That's Apple's point.
Most application interfaces are just a little more complex than a toaster.
Consistency is the most important part of a UI - a user will get used to the behaviour of certain controls/widgets, if your app comes along and uses it's own that behave differently, you just broke consistency and the user will have to waste time deducing the behaviour rules of your control.
Windows has become a hive of confusing and inconsistent interfaces, not only because people like Adobe write their own tab controls, but people like Creative and whoever wrote BlackIce discard the standard interface entirely and use their own hideous bitmap based monstrosities.
Not to mention the fact that using standard controls saves a hell of a lot of time developing custom ones. Obviously some controls simply won't exist and you'll have to make them yourself, but with a reasonable set of standard ones and a good canvas control you have most things covered.
Chris "Ng" Jones
cmsj@tenshu.net
www.tenshu.net
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.
>By switching to OS X, Apple threw out 15 years of hard work, just to release an OS with an inferior UI on an inferior kernel.
Yes, a kernel that rarely crashes is indeed inferior. Likewise, a kernel that allows developers to build applications based on standards is a poor choice.
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
"We" don't. (If be "we" you mean "clueful programmers".) This article wasn't written for "any Mac developer worth his salt." It was written for very smart developers of other platforms that want to be aware of what the need to know to succeed on the Mac platform.
The article is interesting reading to see what Apple is currently telling coders who are new to doing a Mac port. Many companies have ported apps to the Macintosh without paying attention to Apple's UI guidelines, and were stunned to discover that the entire Mac community thought their app, which was a modest success in the Windows market, was universally dismissed as utter crap by Mac users. This info can help companies avoid repeating that mistake. It's not about conforming to what Apple wants it to look like nearly as much as what Apple users have come to expect from their apps.
One of my favorite differences is that I almost never see a dialog box with a button that only says "Yes" or "No" on it when I'm using the Mac. (Mozilla is one of the exeptions. The Mac 1.0 version is still lacking a lot of Mac-ness, but it pulls up /. pages a lot faster than IE, and doesn't break on as many sites or nag me for money the way OmniWeb does, so I'm not going to bitch too much about a "capitol-F" Free software product.) There are far too many Windows apps that pop up dialog boxes saying stuff like "You are launching proceedure $FOO without condition $BAR being properly set. Do you no longer wish to avoid autocorrecting the object status and reimplementing the enterprise settings? [Yes] [No] [Cancel]"
Information wants to be anthropomorphized.
No, actually he does not say that. What I read there is that he doesn't necessarily agree with Apple's "new direction", and has decided that the difference between PC and Mac interfaces is now negligible. Obviously, a lot of people disagree.
Cocoa could not, no-way-no-how, have been ported to OS 9. While I miss my old spacial Finder too, I realize that it does not scale at all for the large numbers of files UNIX - and indeed, things like digital photography/music collections - requires.
By switching to OS X, Apple threw out 15 years of hard work, just to release an OS with an inferior UI on an inferior kernel. And their interface in many ways no longer follows the principles that Apple themselves set out so brilliantly back in 1984, and others tried to emulate with varying degrees of success (don't even get me started on the Dock).
Inferior kernal? Smoke another one, buddy.
I've heard these arguments over and over about the Dock. No one has a problem with the dock unless they are already thoroughly entrenched in some other mechanism. I'm convinced that it is the pain of un-learning something else that makes people hate the Dock. Try this - put some newbies in front of Mac OS 9 and tell them to launch the browser. They won't be able to do it. Where is the browser? 4 levels down, inside the Apps folder, with no visible way to get there. OS X solves this. The dock may have some significant limitations, but it's hardly the disaster some make it out to be.
As for throwing out 15 years of work, if you'll check the aforementioned Aqua UI guidelines, you'll see that it's not true. They have built upon that foundation. It's practically identical. I still have the original 10-book set of UI guidelines, and it really hasn't budged. If anything they've added to it - such as the new mode for dialogs (status, reason, action). Things like 'verb' button-labels remain.
But there's absolutely no point in buying a closed platform when the software, specially designed for that platform, sucks. At least with PCs, I can run BeOS on a laptop; with Macs, such is no longer an option.
You know, that is an opinion.
If Jesus wants me it knows where to find me.
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.
They mentioned keyboard shortcuts, but the left out the most important thing that Windows gets right.
I haven't used a Mac in five years, but I have used Linux and keyboard support sucks. Sure, if you never run X at all you can do anything from the keyboard, but type "startx" and you're screwed.
In Windows you can do everything except specific drawing tasks without having a mouse. (Using Autocad I can actually do some drawing tasks without a mouse using keyboard coordinate entry.) And dialog boxes, I never reach for the mouse to answer a Windows dialog box.
The very first version of Windows I used was 3.0 and it got this right. I've never seen a non-Windows GUI OS that matched the keyboard support of any Windows OS.
Why can't Gnome and KDE developers adopt the simple standard of requiring a "hot-letter" for every menu item and every dialog box item including buttons and selection widgets.
"The best argument against democracy is a five minute chat with the average voter."
--Winston Churchill
It's hard, typically, because the second you change the wording of a menu or dialog dox, all the keyboard navigation letters have to change.
The single best way to fix this stupid problem is for keyboard shortcuts to be automated but overrideable in GUI toolkits. When I write a menu item, it should scan the entire list of menu items, and generate keyboard mnemonics for everything. It's not a terribly complicated algorithm, but it is tedious to do by hand. Sometimes, it will come up with lousy results, and some menmonics can't be deduced from the text, but it would solve the problem of developers completely forgetting about them.
We've put a ton of work on making nedit keyboard accessible. Almost everything you can do with the mouse, you can do with the keyboard. It's a huge amount of work, but we wouldn't have it any other way. Alomst every GUI item can be hit with the keyboard, and vice-versa.
Want to know why I won't use Mozilla on Windows? When a yes/no dialog pops up, I can't type 'Y' or 'N' to dismiss it. Stupid things like this, problems that were solved 15 years ago, still plague us.
I can explanate how to administrate your network. You must configurate and segmentate it, so it can computate.
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