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!"
Windowws XP has an option to turn the faggish appearance off.
God damn, this is like the 3rd Apple story this morning. Can Slashdot PLEASE remove its lips from Steve (Blow)Jobs dick?
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.
Because Apple's HCI guides work very well, no matter which OS you apply them to. Yes, some things will be specific to the Mac. On the other hand, I still stick by many of the principles outlined in the "Apple Human Interface Guidelines" book published circa System 6.
Oh, and that's for Java, C/C++ apps and even web pages to a small extent. Haven't had a Mac since the original LC.
Cheers,
Ian
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
If you really hate the 'XP Look', but setting it to classsic seems too boring, try Windowblinds or Hoverdesk, two great apps that will skin your entire interface and hardly use any system resources, if you have the time you can make your own skins, or you can get one of thousands at sites like deskmod.com or lotsofskins.com, i change my windowblinds skin about biweekly just to keep things fresh, the great thing about windowblinds is you can have lots of extra buttons, i have some skins that have lock on top buttons, buttons to launch notepad or the screen saver and some even have winamp controls built in, another cool feature of all windowblinds skins is that you can roll the entire window up into just the top bar, saving some space without minimizing, i've never taken the time to configure hoverdesk, but its interesting, easily customizable, and makes your desktop nearly incomprehensible to anyone else, but if you love that aqua mac interface so much, theres a windowblinds skin called OSXP, http://deskmod.com/?state=view&skin_id=2643
"Sic Semper Tyrannosaurus Rex."
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.
There are many books on UI design that are worth looking into, two of the more useful ones I have used:
n es/HIGuidelines-2.html) is great for its sections on design principles like modelessness and user control. The Mac-specific stuff like where to put buttons is less relevant and can be skipped.
GUI Bloopers
The Design of Everyday Things
Also, the Macintosh Human Interface Guidelines (downloadable here: http://developer.apple.com/techpubs/mac/HIGuideli
I'd recommend focusing on the principles of good design that can be used on Swing, Windows, Mac or KDE and Gnome. Good UI principles will still be valid 10 years from now, when neither XP or Aqua will be around anyway.
"I don't mind the swelling, it's the itching I could do without."
I have MAC OS 10.2 and instead of using Apple's useless 1 bouton mouse thingy I opted for a Logitech cordless optical 3 button wheelmouse.
Guess what? It all works, the buttons, the wheelmouse, etc.. The right mouse button works just like a PC user would expect.. context menus.
People should look into an issue before just spewing crack out of their mouths.
Nick Powers
Encryption: I may not agree with what you say, but I will defend your right to encrypt it...
MacOS has had context menus since MacOS 9 (or possibly MacOS 8 - I'm only a part-time Mac user).
You control-click (e.g. on a file in the finder) to get them - or if you have an MS mouse, the driver converts* a right-click to a control-click, so it works pretty much like Windows/X.
Tim
* Although MacOS may actually just support the right-click natively now - I don't know.
Really nice idea I never thought of. Too bad I won't be writeing any OS X apps anytime soon. Are there more documents like this on UI design that arent' just about OS X, but more general?
Try the Interface hall of fame and hall of shame at Isys Information Architects
As a long time MacOS X user (since the public beta... no the first beta, before 10.0), a longer time Mac user (since the Mac Plus), and a sometime Cocoa developer, I think you made a few mistakes too (see, nobody's perfect... I'll probably make a few right now).
1) Gray/White/Aqua - While I agree that having White all over the screen can be annoying, gray is worse. Consider two situations: the desktop, and the laptop. If you're using a desktop, you're probably someplace where you can control the amount of ambient light in the room and keep it somewhat consistent. This means you can set the brightness of your monitor so that the white doesn't hurt your eyes. If you're using a laptop, and you're inside, you can do this also. But have you ever tried to use your Powerbook outside, in the sun? There's just no way to get the screen bright enough. Even with the brightness all the way up, I had to squint to see the black on white of the dialogs and windows. If it had been black on gray, I would have packed up and gone home.
2) Big, pretty, photorealistic icons - Most users want to know they're using a program designed by a professional. Even if it wasn't, they should feel like it was. Cartoon-like icons may be perfect for children's titles, or even some games, but for a real program, the icon for TextEdit is about as cartoon-like as I would want to get. Since the icons all auto-size to either user-preferences or available space, your point about on-screen space is mostly moot. And I'm sorry, but a 128X128 pixel icon, with 24 bits per pixel takes the same amount of time to render to the screen no matter how it was drawn - photorealistically or by hand.
3) QuickTime and iTunes - All the controls in both of these programs are standard buttons, and sliders, except for the faux-LCD like display that they have in common. The other major difference is the brushed-metal background. I'm sure part of the reason for this is history (both programs existed in MacOS 9, or earlier) and Apple Carbonized them to run on MacOS X and MacOS 9. But you're right, these two programs do kind of fly in the face of the Aqua guidelines.
4) Drop Down Dialogs - I'm assuming by "drop down dialogs out of captions" you mean "drop down sheets out of dialog windows". If such a dialog ever existed where the sheet and the dialog were the exact same width, and the sheet just happened to cover up everything but the "Cancel" and "OK" button on the dialog below, I haven't seen it yet. But even if it did, only the drop down sheet on top would have a colored and pulsing default button, and there is still the border of the sheet (a 2 or 3 pixel black line with a drop shadow behind it) to differentiate between the two.
5) "No happenings" - First, huh??? I guess you mean "when a program is busy, there's no progress bar". This is actually a common design flaw in many programs (Windows, UNIX, and MacOS X). I've seen the problem much more often in Widows than the other two though. Apple's Finder uses progress bars for copying and moving files. I agree with you that programs should make better use of progress monitors, but this is an Application design problem, not an overall UI problem. The Aqua guidelines do talk about their use.
6) Big controls - Consider the fact that both Apple and Microsoft increased the size of their controls in the latest versions of their OS. I can't imagine they would have done this unless there was some research behind it that said "Larger controls gives the user and easier time". But, from my own experience, I know many people who didn't set their display as large as it could go because they would have a hard time reading the menus. If increasing the size of the controls by 10% lets the user add 25% more pixels (1600X1200 instead of 1280X1024), they've just gained usable space, not lost it.
7) Skinning - While this is a neat option, it is exactly what the Aqua guidelines are trying to minimize: differences in applications. It's maybe not so bad if Photoshop and MS Word have some differences... but if I know how to use MS Word on my Mac, I don't want to have to relearn it just so I can use it on your Mac with a different skin. In my opinion, skinning is the ultimate eye-candy, and generally doesn't add any value to a program. Besides, how could Apple possibly provide support for their programs if custom skins were allowed? When's it a bug in the program? When's it a bug in the skin?
8) MDI - Windows is the only OS I know of that uses MDI. UNIX doesn't. MacOS doesn't. Java has the option, but I can't think of a program that I've ever seen using it. I recall seeing some research that described how bad it is... maybe Jef Raskin's book "The Humane Interface" would have it? I forget where I saw it though. Basically, MDI limits where you can put your document windows, and can make looking at a document in one application while working in another into a huge headache. MDI promotes wasted screen space, and hides open documents from the user when one document is maximized in the application's window (you have to click on the app, then use the Window menu to bring the document forward). In the end, MDI is probably like the "goto" statement. Sometimes it is useful, but 95% of the time, or more, it's a really bad idea.
I ran long... sorry folks. I'm not going to say that Aqua is the best interface possible... I hope it isn't, or I won't have much chance of getting a Ph.D. in HCI (I'm starting work on it this fall). All I'm trying to get at is that some smart people, one or two very smart people, and probably a couple of morons too, put a lot of time and energy into figuring out how they could improve the usability of the MacOS. While they're decisions may not be the perfect choices for you, you may not be the common case... and that's who they were trying to design for.
Under the section 'Use Clean Layout', the Mac OS X guidelines state:
In a book called "The Non-Designer's Design Book", author Robin Williams explains some of the principles of visual layout from the field of graphic design. On the topic of alignment, Williams states that items aligned on a page create a strong cohesive unit. An "invisible line" gives order and organization to the elements on the page. She goes on to add that a centred alignment is the most common alignment that beginners use, and often creates a sedate, ordinary, and frankly quite dull appearance.
The book contains many before-and-after designs where the alignment of elements is modified. Most of the improvements arise from moving elements with a centred alignment to a flush-left or flush-right alignment. Williams doesn't say you should avoid a centred alignment altogether, but does add "...please try very hard to break away from a centered alignment unless you are consciously tring to create a more formal, sedate (often dull?) presentation."
In fairness to Apple, some of the examples they show in their guidelines demonstrate that their recommendation for a center alignment works by making elements next to each other (such as labels and their controls) flush with the "invisible line" that separates them (as in the sample application preferences dialog). Perhaps the best way of looking at Apple's recommendation is to appreciate that non-centred alignments are not an inferior alternative to centred layouts, and may in fact offer an improvement in dialog design.
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.
Yeah. As a million people have said before:
Any two button USB mouse is automatically supported by MacOS X, and right clicks work like control-clicks (that is, they invoke contextual menus).
There are no trails. There are no trees out here.
i'm sure they're just reminding everyone that windows copied apple, not the other way around. hopefully they hide that information about the XEROX GUI
Jesus saves souls and redeems them for valuable cash prizes
How old is your Linux box? I've been able to just hit the key I want for whatever menu shortcut I want for several years now, out of the box.
Humor me, try this:
See? You can assign and remove any meny accellerator you wish, in any application (that supports it of course, like stock gtk+ applications, XUL code (i.e. Mozilla, Galeon), and so on.
Your FUD doesn't help the cause.
With those options turned on you can do everything you want without needing a mouse.
-braxton
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.