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!"
Aqua et al have been DESIGNED by professionals. Gnome was thrown together as a hack job by retards too stupid to comprehend how a real GUI should work.
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
Many of the points brought up in the article are good points, that could be applied to any program not just one for Mac OSX. One of the complaints I have with a lot of open source software is that it has a sometimes cluttered, non-intuitive, and unprofessional/unpolished feel. If developers in general followed general guidelines like this: use informative error messages and debug messages, or dont cluter the application with lots of small undescriptive icons, but instead make panels grouped together then this would make, I think, the entire computer experience a lot more enjoyable. You wouldn't have to spend as much time learning a particular applications layout and interface just to be able to do something useful.
...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. 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. 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).
I'm not even going to get into some of the innacuracies used to make the Mac UI look better or the complete lack of professional advice being utilized. Much of these arguments are based on the premise that "Mac users like it this way" and assuming that the typical Mac user is a UI expert.
>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
Apple is just trying to ensure that their OS's reputation of being user-friendly isn't damaged by overzealous developers. New users don't know enough to distinguish between the OS and the applications that run on it, so an app that's hard to use reflects negatively on their OS.
This space intentionally left blank.
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.
I can't agree with some of them. For example :"Don't use non-standard controls".
Please remember this:
People are stupid.
Programmers are people.
On the other hand, if you just let yourself get used to the idea that everything you need to do is on the top of your screen (and always in the same order: Apple, Application, Edit, View, App-specific stuff, Window, Help) you might find that Mac users worship the top menu concept for a reason. It makes your life easier, in the long run.
Information wants to be anthropomorphized.
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.
Actually there were two very valid reasons for doing this back when the original Mac UI was being developed.
... not neccisarily bad but still very confusing to those of us (myself inculded) coming from a[n] [X]windows background.
The cheesy reason: It saves screen space, on a 3 or 4 inch low res monitor screen space is very valuable.
The good reason: 'targetability' With the menu always at the top of the screen it has an effectivly infinite height making it easier for the user to get to the menu (ie a quick flick upwards of the wrist always gets the mouse over the menu).
Clearly the first reason is no longer valid on todays systems, but the second still has some merit. But on the other hand if I wish to 'target' a menu item in a different document window things get much more cumbersome... I guess they just optimized for the common case at the expense of the uncommon one
Thoughts on tech, Software Engineering, and stuff
UI research is precisely the kind of thing Microsoft thought was a waste of money until a couple years ago. Apple did alot of the basic research on usability throughout the 80's and 90's. Microsoft did not. They have turned that around and are spending on research in a big way now, but to say that a UI is tested and usable simply because it is running under Windows is a bit of a stretch. Some Windows apps are great, but the Windows universe of apps sorely lacks consistency.
"I don't mind the swelling, it's the itching I could do without."
It's ironic how MDI gets trashed and praised, often by the same people.
.fvwmrc file).
Tabbed browsing in Mozilla? Quicken's tabbed windows? That's MDI, too. And lots of people like it. It's MDI done right.
The problem with old-style MDI apps (e.g., icons in a big empty window) that it was a one-size-fits-none policy that all apps could use. The in-app window management was usually horrible: icons that could be overlapped.
The only different is that apps are using MDI nowadays and are customizing the in-app window management to the application. Most people love it; other control freaks don't (e.g., if you have a custom 9000-line
I can explanate how to administrate your network. You must configurate and segmentate it, so it can computate.
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.
Because Apple provides focus and direction for developers, Mac applications (generally) behave in expected and "natural" ways. Consistency and simplcity make users happy. Windows sufferes from verbosity, backward compatability, and mixed metaphors. What works in one Windows application may not work in another -- even if the two applications were developed as parts of a single package, like Microsoft Office. There are too many ways to do things: different menu commands, keystrokes, and GUI components lead to confusion. Linux GUIs are, sad to say, even worse than Windows. No one imposed a look-and-ffel guideline on Linux, so apps run an behave differently depending on the whims of individual developers and teams. Even worse, Linux GUIs tend to focus on cloning Windows, instead of boldly trying to be better. What we get are incredibly inconsistent applications that have no consistency or common thread of operation. Put The Gimp, Abiword, and Evolution on the desktop simultaneously, and you can see very divergent philosophies in operation. This isn't a knock against the developers of these fine application -- it is a recognition that the chaotic Linux community lacks the cohesion that Apple can bring to Aqua. Give users a clean, clear, easy operating system, and they'll drop Windows like a rock. So why hasn't Apple conquered the world? Because their product is too damned expensive. Windows could be "defeated" if the Linux community were to produce a high-quality, consistent GUI with a quality set of application -- for free. The question is, are we too individualistic to work together as a community?
All about me
I never have worked out why Mac users are so insistent that palettes are superior to Toolbars.
Because since 1989 when the Mac II was released, we've been able to easily plug a second video card and a cheap (or not so cheap, depending on your budget) second monitor into our Macs and use it exclusively to hold the palettes. Windows multiple-monitor capabilities didn't achieve parity with that of the Mac until Win98, IIRC.
Personally, I've used dual monitors on every desktop Mac I've owned since 1994, and have no intention of giving them up. Once you get used to that extra screen real estate, working on a single monitor feels very confining.
~Philly
The point of this document isn't to say "our interface is right and Windoze blowez". Notice that the url for the page includes the words "developer" and "switch". That means: THIS IS FOR DEVELOPERS WHO ARE STARTING TO DEVELOP FOR MAC.
Its a set of guidelines to make the porting of a windows application smoother and better received on Mac OS X. Its not an easy thing. The fact is that most ports of Windows software to macs are quite annoying because they flatly refuse to follow the "standard" interface (okay yeah, the iApps don't really follow it either - and I find them annoying too).
Yes, Apple does somewhat ignore it. But that's not the point at all. Have you seen Matlab 6.5 for OS X? Developers who are thinking about porting their apps to OS X need to realize that Mac users will not be infinitely grateful to them just for doing it. We want our apps to look nice, and feel responsive and familiar when we use them. If you aren't interested in taking the time to put a decent interface on your app, then you should consider letting your competitor "have" the mac platform for your field.
I'm not saying its easy. But I don't think porting an application is easy at all. And interfaces are SOOOOO easy to build in OS X. Just drag and drop with the available buttons/widgets in Interface Builder. It needs to be done. Mac users have just enough choice in software that they can pick a competitor's product over yours given the same price range and feature set...just because one doesn't look as nice as the other.
It's not a question of being "unfriendly at first glance"--most new interfaces are (that's what makes them "new"). It's a question of being unfriendly throughout the lifetime of your interactions with it, due to bad design decisions made at a deep level. Your statement gives developers permission to punish end-users for needing to use the app. This is good news if you're a monopoly, but bad news if you have competitors.
Any sufficiently well-organized community is indistinguishable from Government.
I don't know what you mean by it being a pain. I use 1600x1200 displays and have no problems. It is only confusing to people who have been brainwashed by windows to expect that running 10 applications means that the menu bar options are spread around in 10 different places.
Packaging applications in a single directory is good, but drag-and-drop installation is not. When I download the latest version of Mozilla, I don't want to have to hunt down the old version and delete it by hand. Nor do I want to have to hunt down the shortcuts to the old version and replace them with new ones. Upgrading application software should be automatic and centralized. The answer is a real packaging system, not Windows installers, and not drag-and-drop installation.
That is why there is an Applications folder. If you put your applications there you won't lose them. If you put them in some other obscure corner of your hard drive, then it's your own fault if you can't find them.
I don't know what your talking about with shortcuts. If you put the new version in the same place as the old version then your aliases and your links will still work. Plus, you can keep multiple versions around if you need to without conflicts. I'd like to see you do that with IE on Windows.
Oh, and it would be terrible to be able to install applications with one simple drag and drop action. Much better to have to click Next fifteen times.
In 10.2 command-oprion-H is "hide all other apps"; don't want to see other apps? Use it.
Prior to 10.2 the "hide all other apps" didn't have a consistant short cut, but it was always in the same place in the application menu (second manu on the bar, between the apple and the file menus).
Personally I like having, oh, say, my IRC client up, and pushing the minimised iTunes controls between the IRC connect/notify windoes and the users window. Or maybe closing the users window and having a DVD play there. Or sticking the compile window from Project Builder below the chat area, or Backup's progress bar close to the...
No, never. That's not to say from time to time I don't click the wrong thing and get the app I don't expect, but I have found it trivally easy to "get back". Command-H always hids the current app in OS X, so if you didn't want the app up at all (say the pesky finder that unhides if you miss a window and click the desktop) Command-H hides it and switches you back to the last app. If you wanted that app un-hidden, you can return to the last app by doing Command-Tab in 10.2, or prior to 10.2 the shareware HotApp program let you use Opt-tab for that.
Sure, if you spend zero time learning how to use them they are bad at stuff. Much like spending no time learning how to drive a car makes them bad transportation devices, and great devices for crushing expensave stuff, or spending zero time learning to interact with people in a bar makes it hard to get a date, but easy to wear a drink. Most stuff does require a little effor to learn! Sometimes the very tiny effort of finding someone who likes the thing and saying "er, why do you like it?", or "how do I do this?". Sometimes - the horror - the supreime effort of reading a book!
I'm not a big windows fan, but I do admit their GUI lets you madly rush about and has defaults that don't suck too hard. Linux seems about like all the other (non-Mac) Unixes and has random GUIs on top of it that conflict a bit, have defaults that suck hard, and after tons of effort in getting them tuned to how you like to operate, tend to work better then the out of the box configurations of Windows or MacOS. Or corse I expect if you spent the same effort to customise the other two you would get the same effect.
Well, they sure aren't cheap (except maybe the iBook, and maybe the DVD-writer iMac up agianst name brand PCs....definitly not as cheap as white box PCs though!).
On the other hand they sure don't seem slow. I was happally writing CD-Rs for backups watchign an IRC channel and DVD, running iTunes and nothing seemed the least bit slow. Ripping CDs seems way way faster (and simpler) then Intel-ish PCs with 2x to 4x the clock speed! Compiles seem to go by just as fast as any other IDE system (laptop, so no SCSI option). Maybe for most tasks the slowest thing is not the CPU, but the memory wall, or the disk wall, or just plain the person sitting there doing work.
Of corse I don't think I would go out and buy rack after rack of Xserve boxes for a render farm, then again, it would be one of the platforms I would evaluate. I kind of susspect the Intel-ish systems would win out there though.
Actually as a Windows user who loathes the Mac look and feel it was one of the few pieces of advice I agreed with as a general matter.
When Mosaic first came out the most noticable thing about it was that it was the first browser for X-Windows that did not have an amateur DIY look and feel, it was plain Motif with the standard SGI fonts.
I don't much like using Adobe products because they insist on inventing their own UI techniques rather than providing the user with something consistent. At one point I used photoshop on a daily basis, then I stopped using it for a couple of months and found that I had forgotten how to use most of the commands. These days I just can't be bothered with it.
My pet peeve is MP3 players. For some reason these programs seem to be insist on morphing into the most unusable shape possible. Skins are cute as an option but just why does nobody - including Microsoft make an MP3 player with standard Windows look and feel?
The other point that is quite noticable in the document is that the Apple designers appear to be making most of their comparisons to the Windows 95 look and feel rather than XP.
It is also quite noticable that the example they give of an application with 'only one' menubar on Aqua actually has at least four visible command bars. The IE window has its own menu and shows a page with yet another menu.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
HTML was originally designed to work this way. Unfortunately, it's hard to convince peopel that this is a better system -- legions of hard-copy print era designers swarmed the Web design scene and pretty much decimated any hope of client-side UI control.
Now, HTML is pretty much an inefficient, hard to parse Postscript variant.
May we never see th
The Windows dialog box in #9 looks perfectly normal to me. It asks a question and lets you enter a response. But in the back of my mind, something always bugged me about it, and not just because it gives you three ways to answer a Yes/No question. Now that I see the comparison with the Mac version, I realize what's wrong with it. The Mac version makes more sense and is guininely easier to use. It's not a coincidence that these are also two phrases that describe a Mac (compared to a PC).
One of the things the Mac dialog box does that the Windows box doesn't is converge everything about the action into the dialog box itself. In other words, it gives you enough information so that you can focus on the immediate issue (saving the file) without having to think how you got there.
As the text says, dialog boxes interrupt the user. When the user is interrupted, his train of thought is interrupted, and that usually forces him to think unnecessarily harder about what he's doing.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
...Which works great until you need to open a file with an application that doesn't think it can open the file. Then you're stuck messing around with altering the type and creator codes. Or you receive a file over email, it's lost its type and creator codes, and you're stuck trying to figure out what it is and recreate them.
At least for me, while the original Mac OS scheme worked well when it worked, the addition of file extensions is a welcome one because it's easy to tweak when it doesn't work. (I agree with the earlier poster who pointed out that the extension-handling is more elegant than that in Windows.) Beyond that, it makes sense in a world where files are routinely exchanged among platforms.