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

Re:Some things are misleading

[Jonathan]

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.

Re:It is quite interesting, but...

[ChrisJones]

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.

Re:Nothing new

[banky]

>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.

Re:Nothing new

[thatguywhoiam]

Of course, if you go to MacKiDo's main page, you'll also notice an introduction note; in summary, it says that OS X was a mistake, as Apple's primary focus is no longer on the UI. And you know what? I couldn't agree more. Say all you want about OS X bringing Unix to the masses, but the fact is, the masses would have been better off without Unix. OS 9, despite having less eye candy than OS X, was architecturally better for the home user in just about every way than OS X - the only significant development X had was Cocoa, and that could easily have been ported into an OS 9 upgrade instead.

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.

.r

Doesn't acknowlege Windows' keyboard superiority

[Paul Carver]

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.

Re:Best suggestion

[Sax Maniac]

It's ironic how MDI gets trashed and praised, often by the same people.

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 .fvwmrc file).

Re:Doesn't acknowlege Windows' keyboard superiorit

[Sax Maniac]

It's small, boring things like that that really piss me off about all almost open-source UIs. The reason why is this: keyboard navigation is hard to get right. Most developers seem to want to spend all their time play with time-wasting, usability-destroying "themes" than actually improve the usability of their app.

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.