Why Militant Mac Zealots Piss Me Off Redux

I thought the number of Mac apps being ported to Windows was miniscule-the prevailing opinion from all pundits seems to be that all software gets written first for the PC and is then ported over to the Mac. If it is a cross-platform application, the behavior should remain quite similar, in my opinion, for those folk who like to use both Windows and Mac in their work. It would be quite disconcerting in such a situation, if all the keyboard shortcuts turned out to be different on the different platforms.

@Coombs -- I disagree with you about the shortcuts on the basis that most of your customers are going to be buying for one platform only (not both), unless you make a very specialized app. For example, how many people own Photoshop on both Mac and Windows compared to how many people own it on one platform only?

As for Mac ports being an after-thought... yes, I think that may be the case. But it still doesn't let any developer off the hook. If you write software for any platform, you should try to make it behave like other applications on that platform.

Heh ... what a day to start reading your blog! I had no idea you were such a controversial figure. Will just told me to read this to get dirt on RB 6 stuff :)

I think the rant preceding your original point did a disservice to the true message, which is not only right on target but a pretty brave thing to see coming from someone who works for a cross-platform tools developer. I absolutely agree - there is *far* more to porting an app from one platform to another than just moving the menu to the top of the screen or turning on MDI. Mac and Windows (I won't even go into LINUX, BeOS, etc), though superficially similar, have very different approaches to the same constructs. A "window" to a Mac user is very different than a "window" to a Windows user. How you expect different windows to interact, what happens when you close a window, what a program is, etc - they carry very different connotations on each platform. It's very hard to make a single interface that accurately reflects both attitudes. For small, simple apps you might be able to get away with swapping the order of "OK" and "Cancel", but it's much harder with a larger project. Every large cross-platform project I have worked on has eventually split their interface code out and been re-implemented for the appropriate target. Sure, some code is exchanged, especially the core functionality, but the GUI almost always needs to be custom designed for each platform. Not a popular sentiment for managers looking to flip a switch and churn out another platform.

And don't even get me started on the myth of the dual-user (a single user running the app on both Mac and Windows) ...

And why is this comment box so dang small? I bet it's conditionally sized so Mac users have less space :)

Aaron,

I understand your rant much more clearly now, and will even say that I agree with you. I have experience where the same can be said about Mac users complaining about apps being ported over that look/behave too much like "Windows". A fine example is OpenOffice.org. I know Mac users who do not want to use it because it doesn't feel like a Mac program. Going back even further, Word 6.0 for Mac was criticised because it didn't feel like a Mac program (which, doing a search for Word brought up the comment by Peter - Guy deserves a free round of beers from your virtual bar! :)

LoL@Brady -- yeah, it's been an entertaining day or so. ;-) I admit I was being an ass previously, but I figured I was an ass amongst friends. Then the stones came out. :-P

And I agree with you about how difficult it is to make a cross-platform application that makes users warm and fuzzy on all platforms. We're going thru those growing pains right now with designing RB6 (and making improvments to the runtime to make it easier where we can).

As for the small comment box... it's small because most comments I get are usually short and sweet. Like some of the flames from yesterday. :-P

Hah! Brady, I was wondering the same thing. I noticed it yesterday when I was replying.

I think you're right though.. I think Aaron specifically targeted Safari users with a non-scrolling, teeeeeny comment box!
(checked FireFox and its the same size, but at least has a scroll bar!!!)

:)

@Jack -- I totally agree. I use Mail/BBEdit on the Mac, but I've always wondered how users handle things like Entorage (probably spelling that wrong, too lazy to check) and Office. And those come from the Mac Business Unit of Microsoft even!

And I think everyone who managed to respond intelligently to that rant yesterday deserves a free beer simply for putting up with my bitchiness. :-P

Aaron wrote: "I take issue with Mac apps coming over to Windows, but still feeling like Mac apps, and being told by the developers that I should like it because the Mac UI is simply superior to the Windows UI."

Well, here's the real dilemma. If you're primarily used to the Windows way of doing things, then a Mac app that tries to behave like a Mac app on Windows (e.g. iTunes) might feel, well, a bit alien. It's like using your left hand when you've used your right hand all your life. I agree that the same disorientation occurs when a Windows app is ported to the Mac and retains the behaviour of a Windows app. But as someone who has used PCs for longer than I've used Macs, I have to concur with the assertion that "the Mac UI is simply superior to the Windows UI" -- and I use Aqua and Luna every single day. A good empirical demonstration of this is iTunes -- a Mac app ported to Windows that looks, feels, and behaves almost identically on both platforms -- some people hate the brushed metal look, but ignoring that particular aesthetic gripe for the moment, the underlying functionality is pretty much the same. And what has the user base decided? The overwhelming majority of iPod users (on PCs) do not seem to mind using an app that behaves like a Mac app -- on Windows. The iPod market has decided that iTunes on Windows, like iTunes on the Mac, is "good enough" for organizing their digital music collections, else they would look for another program to manage their music and integrate with the iPod. Another case in point: web apps -- http://www.panic.com/goods is a recent example -- the storefront behaves the same way on Windows and on the Mac, and it evinces a great deal of thoughtful design. That it mimics some of the Mac UI behaviours (e.g. drag and drop done right, puff-of-smoke animation, etc.) is no accident, since Panic is a Mac software developer. Let me say it for the umpteenth time: most software developers are not good UI designers, but if you look at some of the easiest, most intuitive web apps out there, a lot of them are designed by Mac-centric folks. This should be hardly surprising. Tim Berners-Lee invented the web on NeXTStep, the software ancestor of MacOS X, and in his book Weaving the Web he makes much of the fact that the superiority of the NeXT environment played a part in making his creation possible. No one has to like the Mac UI way of doing things. But this doesn't change the fact that the Mac UI, for all its quirks and shortcomings, is still superior to the Windows UI, and I say this as someone who has almost 20 years of comparative experience with both -- as far back as Windows 1.0 on an IBM PC, in 1985. I didn't start using Macs until 1987. I'll sum up with a simple comparison between XP and OS X when it comes to dealing with USB memory keys -- to unmount the file system in OS X, click on the eject triangle in the Finder, or drag-eject to the Dock (one step). To unmount the file system in XP, click Safely Remove Hardware in the system tray, click-select the device component in the dialog, click on Stop, click to dimiss the dialog (four steps). Which approach is superior? I think the answer is glaringly obvious.

@Victor -- You're welcome to your opinions on which OS has a superior UI experience (just like I am entitled to my opinion that Apple should have bough Be because it's superior to NeXT :: grins ::).

As for iTunes on Windows, most of the Windows users I know hate the interface. The few people I know who do use it have said "it's ugly and it behaves weird" (but can't clarify what they mean by behaves weird), but they use it because it's the only way for them to get legal music on the PC that they know of.

If you put iTunes as it stands next to an imaginary iTunes with a Windows UI, more Windows users will pick the latter because it's what they're comfortable with. And *that* is why you should design interfaces based on the platform. Users thrive on comfort.

Personally, I will only use a Mac port like iTunes on Windows if there's no other way possible. I don't want the Mac experience on Windows because my brain has to switch from Windows mode to Mac mode. And the entire reason for my rant yesterday is that I don't want Mac developers to continue with the idea that their UI is superior *on Windows*. It's not. It's foreign on a Windows box, and thus is less usable because it's not consistent with everything else on the platform.

There will always be exceptions and examples that "disproves" every rule, and I'd rather not continue with the theoretical debate who whose platform has the better UI. My point isn't about which UI is prettier, better or easier to use in terms of the OS. My point is that each OS has laid out rules to make all apps behave the same. If you break those rules, then I claim you're writing poor software (unless you have valid reasons to break those rules) for that platform (regardless of whether it's cross platform or not).

I hate Windows looking apps on my Macs. Microsoft did this once with a version of Word and no one would upgrade to it. I don't mind Mac looking apps on my Windows laptops.

In defense of the iTunes interface on the Windows side, that was done on purpose. First it was done in conjunction with the interface for the Music store so that Apple needed only one store for both Mac and Windows users. Second it was done to familiarize Windows users with the Mac interface so that if Apple could ever get a percentage of iPod users to switch they would feel right at home with Mac programs.

It has been very effective in winning the hearts and minds of a growing percentage of iPod users. The people the iTunes interface has pissed off will never switch anyway.

I've read both your rant from yesterday and your rant from today, and I'm afraid I remain confused. I understand your main point - that Mac apps put on Windows should conform to the Windows UI - but I can't figure out what things you actually dislike about Mac apps on Windows except for these points:

- Brushed aluminum is ugly
- Macs should ship with a two-button mouse
- Windows users think iTunes feels 'weird' without being able to explain why

You're a cross-platform developer, with plenty of experience working in many OSes. Can you provide some more concrete examples of what iTunes or other Mac apps actually do that make their Windows ports clunky or less useful from a Windows perspective? As both an example and something for you to poke holes in if you so choose, I'll provide a peeve of my own:

One of the things that royally pisses me off about Windows apps that get ported to the Mac is when key pieces of functionality are simply not included in the Mac port, for whatever reason, and are left entirely unmentioned. The best example I can think of is Yahoo Messenger for Mac - I was attempting to set up a voice conference with some of my PC-using friends, who use the voice-conferencing feature between their own machines all the time. The problem was, I couldn't find anything relating to voice conferencing anywhere in my app. 'Invite' simply invited people into a larger chat-room like conference with no voice options. 'Webcam' simply crapped out on my entirely, as I don't have a webcam attached to my Mac. When one of my PC using friends started explaining the process he used, with the commands he selects to set up a voice conference, it finally struck me that the feature simply wasn't implemented for the Mac version of Yahoo Messenger. However, there's nothing in the help documentation, in the online FAQ, or anything that suggests that there's a feature of the Windows client that simply doesn't exist on the Mac client. I can understand why they'd leave that tidbit of information out from a business standpoint - the last thing you want to do is tell your customers 'oh, by the way, there's this feature on our Windows client that you can't use, and we have no idea if or when we'll implement it in the Mac client', but from a usability standpoint, in a product which otherwise seamlessly communicates between Mac and Windows clients, the absense of voice conferencing is jarring and frustrating.

So what specific problems/violations do Mac apps do that upset you so much?

Aaron protested: "You’re welcome to your opinions on which OS has a superior UI experience (just like I am entitled to my opinion that Apple should have bough Be because it’s superior to NeXT... I’d rather not continue with the theoretical debate who whose platform has the better UI. My point isn’t about which UI is prettier, better or easier to use in terms of the OS"

This is the logical fallacy that allows moral relativism to flourish in our distempered era: the notion that there is no such thing as truth, only opinions. Well, I have just empirically demonstrated (using the USB key example) that on one platform, it takes four discrete steps to unmount a file system, whereas on another platform, the same task can be accomplished in one step. I said it before, and I'll say it again -- one approach is glaringly superior to another, and it doesn't take a software developer to guess which one. To bring this back to the discussion at hand, suppose a hardware device, be it a music player, digital camera, whatever, designed to work with both Windows XP and MacOS X required four steps to disconnect on XP and one step on a MacOS X using the vendor-bundled software, and some enterprising third party developer provided an alternative program that allowed the device to be disconnected in ONE step on WinXP, is that still writing poor software just because it doesn't conform to the default UI conventions of XP? Your dogmatic insistence on usability conventions specific to a platform would be funny if they weren't so glaringly illogical, which is ironic, considering you're a cross-platform software developer. I guess it just serves to underline the point that most software developers aren't good user interface designers. Case in point: the plethora of "wizards" or "assistants" that have appeared to accompish what should be simple tasks on any UI. It is one thing to design powerful, feature-rich software. Making it easy to use is something else again. Software developers who dogmatically insist on implementing demonstrably inferior usability paradigms tied to a specific platform for the sake of user "familiarity" are perpetuating poor design instead of innovating to enhance overall usability. An example of the latter: Google's Picasa 2, which does not follow the typical UI behaviour of a Windows app -- on the contrary, it resembles iPhoto in many ways. A good UI should be easily discoverable, and discovery should lead to quick mastery of the app interface. How many Aqua skins are there for XP, anyway?

@David -- Sorry about the lack of examples. Coming from Windows, I tend to feel "it's just obvious what's wrong". Oops! So here's the main issues I run into with Mac ports gone bad (in no particular order):

1) OK/Cancel buttons are swapped (on Windows, it goes OK/Cancel/Apply, but on the Mac, they go Apply/Cancel/OK).

2) Utter lack of buttons in dialogs. On the Mac, it's acceptable to present a dialog which have side effects with no OK/Cancel buttons. On Windows, this is just never done. A good example would be the Get Info dialog from Finder. Because you can change the permissions, there's a side effect.

3) Lack of keyboard mmenonics (the underlined characters you see in menus and on controls in Windows).

4) Keyboard focus issues where the tab ordering is completely messed up.

5) Lack of proper contextual menu support (you can display a contextual menu via the keyboard only on Windows, and many ports seem to forget this).

6) Aqua/Brushed metal look -- it's no less disruptive than you seeing a Win32 bubbly nasty looking XP theme on the Mac. Anything that startles users is a bad thing (unless there's damn good reason for it). An example of an interface that is confusing and horrible on Window: Windows Media Player (or just about any skinnable window). Ug (and yes, it's not a Mac app).

7)Incorrect use of toolbars/menus. Win32 toolbars correspond to menu commands, but on the Mac, they don't always (like in the Control Panels application). Also, menus (and toolbar items) should never disappear on Windows unless in direct response to customizing them. Always disable/enable the menus instead of removing them. Also, menus do not change their text based on what modifier keys are held down (goes back to the same reasoning behind hiding the menus -- menus should never be hidden, just disabled).

I could go on with what I've seen poor ports do, but this should give you a fairly good idea of the major issues developers tend to overlook when bringing their application from Mac to Windows.

Also, I want to make it very clear that I don't consider these to be examples of bad UI on the Mac. These are all quite valid things to do on the Mac, and I'm cool with that.

@Victor -- you seem to think that the USB example is a conclusion that all UI decisions on Windows are poor. See previous rant comments about what a cockneyed idea dragging volumes to the trash is (as well as *why* it's bad UI, even today). We can both sit and pick examples of stupid decisions by both Microsoft and Apple, but you're still completely missing the point.

Aaron revealed: "I don’t want the Mac experience on Windows because my brain has to switch from Windows mode to Mac mode"

And in that statement, you've revealed the source of your frustration -- you're more accustomed to the Windows way of doing things, period. Even if the Mac way might be demonstrably better (and I'm not talking about brushed metal interfaces here), you refuse to have the "Windows experience" sullied by the "Mac way" -- even if takes four steps to unmount a USB key on XP vs. one step on OS X. Hey, if you like to make your own life more complicated...

You also asserted: "If you put iTunes as it stands next to an imaginary iTunes with a Windows UI, more Windows users will pick the latter because it’s what they’re comfortable with. And *that* is why you should design interfaces based on the platform. Users thrive on comfort."

Do you have empirical evidence to support your sweeping statements? Russell Beattie, for one, commented favorably on the iTunes UI -- on Windows. The other day, I showed someone how to format her spreadsheet in OpenOffice; she'd been using MS Office for years before. She was complaining about how OpenOffice was a pile of crap, etc. After I showed her how to do the same task in OO, she promptly shut up. I see the same thing all the time when I show someone how to do something on MacOS X vs WinXP -- most people who aren't too set in their ways recognize the (frequent) superiority of the Mac approach. When you say "users thrive on comfort" you don't go far enough -- users will, if shown a demonstrably superior, easier to use way to accomplish the tasks thay want or have to do, choose the superior way. Unless they're irrational, narrowminded people. But that's a whole 'nuther discussion. ;-)

I love it when developers write reams about focus, tab order, etc. In almost twenty years of helping people use PCs and Macs, I've collected a few gems comparing real-world use of the two platforms, often in the same physical setting. Here's one: Secretary A, using a PC: Can I have a computer like hers? (pointing to secretary B nearby, who uses a Mac for the same tasks Secretary A is doing)

I also find it interesting that in GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers, many more of the examples of poor UI come from Windows than from the Mac. Coincidence? I don't think so.

@Victor -- it isn't my source of frustration alone. It's a well-documented fact. Do some resarch, and you'll see companies stating things like "The value in UI consistency lies in effective learning, by making it easy to transfer knowledge from another product.", which makes complete sense.

You've managed to miss the entire point again, but it is appearant to me that you're not a cross-platform developer, and so you really aren't faced with these things on a daily basis. I'd suggest reading platform-agnostic sources about user interface design. And when you're done with that, read the interface guidelines for Apple and Windows (You can start here). Finally, after all that, we'll have a discussion that doesn't involve trite examples of flaws in our nemisis OSes. ;-)

Hi, again, Aaron.
To hopefully clarify... I am a Mac user. "Tog" the infamous 'I know everything that's correct for GUI's" who helped/led original Mac UI development, feels much of the Mac (and Windows and anything not Tog-ish) is seriously flawed. In some things he might be right. However as a Mac user - or a Windows user - would I want someone to design an app with all these 'correct' and 'superior' features and sell it to me as a Mac - or Windows - app? If I complained that I could not use it efficiently because it did not behave like all my other apps- the behavior of which I understood even if it was not the "perfect" UI, would they tell me to get over it because their UI was better? The issue for 'users' of a platform is 'usability' and that means that it behaves like what they know. One of the things Mac users were always proud of was Apples UI guidelines that developers were required to adhere to. (even though they might not have been perfect for each specific app.) All the UI elements were consistent from app to app. It made for better usability. (and it's still one of the big things I hate about Windows. Sometimes an element is here, sometimes there - depending on the developer'd whim.)
So - why - as a Mac user - should I think it is a good thing to foist off our "better" way of doing things on someone who is working in a Windows context? It doesn't! It would be "kind of" like baking with a recipe in cups and teaspoons but finding one ingredient measured in grams!
Verbose - as usual - but I think/hope this was what you were saying.

Aaron: "you’re not a cross-platform developer, and so you really aren’t faced with these things on a daily basis"

I work for a web applications developer, in technical support, so believe me, I am faced with these things on a daily basis. The web is supposed to present the same UI behaviours regardless of what client platforms are being used. That's why I cited the example of http://www.panic.com/goods -- which works identically whether you're on a Mac or on Windows. We are greatly inspired by what the guys at Panic have managed to accomplish. :-)

As for nemesis OSes -- I also spend a lot of my time defending corporate Windows networks from malware, so it may be safe to say that I'm still amazed by how much effort is required to secure Windows vs. MacOS X. We have clients who run multiplatform networks, and the PCs are all higher-maintenance from a security standpoint, what with all the spyware, etc. that comes roaring down the pipes trying to turn them into spam/porn relays. Oh well.

Aaron -- in spite of my nay-saying, I do in fact understand the point you're trying to make, i.e. that a Windows app ought to look, feel, and behave like a Windows app -- IF the primary goal is to help the app user stay within his or her comfort zone. Muscle memory and all that. We need to help users accomplish tasks as efficiently as possible. In cross-platform apps (e.g. Photoshop), one hopes that the app interface manages to do this IN SPITE OF UI quirks in the underlying platform. This is perhaps even more important with web apps, which should behave identically no matter what browser is used. The tricky part is balancing useful innovation (brushed metal is not, IMO :-) with a real concern for helping users get on with their work -- and if possible, even making pleasant-to-use software! :-)

@Victor -- While I agree that innovation and moving forward is a good thing (on all platforms), I don't think that's the job of the software developer. Otherwise eveveryone writing a piece of software can feel that they're being innovative by doing something different and then you have no consistency across applications. While you may get the occasional jewel of innovation, you'll be too frustrated to care. Those innovations need to come from the OS vendors since they're the gating factor in terms of the UI.

If you can take a Mac concept that makes users lives easier and port it to Windows, then that's awesome! But if it's vastly different from what I'm used to, it'll annoy me. Here's a platform-agnostic example:

Let's say that you decide to change Copy and Cut's menu shortcut to be Ctrl+C and Ctrl+Shift+C (or Cmd+C and Cmd+Opt+C if you prefer) because you understand that cut is just a specialized form of copy (copies, then deletes) and the shortcut makes more sense than Ctrl+X does. Now... distribute your application and see what user's reactions are going to be. I can promise you that you'll bar tarred and feathered. Logically, the idea makes sense -- but it's not what users expect.

Now, let's turn this into a platform nitpick. Imagine finding a Windows application on your computer which would skip giving keyboard focus to push buttons because the default setting on a Mac is to not allow them to have keyboard access. This would shock you, and you'd figure it for a bug. Not because you don't like the idea (that thought probably never even crosses your mind) -- but because it's *different*.

I think you and I agree on the general principle (that users should be able to work efficiently and pleasantly regardless of platform). Where I think we don't see eye-to-eye is at which level of software development the user experience changes should occur. Personally, I'm fine with agreeing to disagree on this one as I doubt we're going to change one another's mind. ;-)

@Steve -- thanks for the comment! That's exactly the point I've been trying to make. :-)

I must admit that I am quite happy with the fact that we're all able to sit and have a decent discussion about this stuff. Thanks to everyone for posting their thoughts! This is much more pleasant than the previous post. ;-)

Aaron wrote: "Those innovations need to come from the OS vendors since they’re the gating factor in terms of the UI"

Personally, I think that we have to start thinking more frequently beyond the geek paradigm of operating systems, application programs, devices, and so on, and focus on the user task, period. The best UI is transparent, it just "gets out of the way" so that the user is able to do what they need to do, as simply and as easily as possible. Make it as simple as it needs to be, but no simpler. This is also innovation. Device UI is a good case in point -- and the iPod is one of the best examples of a discoverable interface that leads to quick and easy mastery of UI functionality. In an earlier era, the Newton interface was an example of UI innovation leading to a (mostly) modeless paradigm of user interaction. To schedule an appointment, you don't have to click-tap on an appointment book, you scribble "Lunch Dennis" on the notepad and tap "Assist" -- the NewtonOS parses your handwriting, finds your next free lunch hour, pulls all the "Dennises" from your address book, and populates a pop-up list, so the only thing you had to fill in was the location and whether or not it repeats, and then it got added to your calendar. Today, in a wireless web services world, the location could be a pick list from your favorites, stored online and cached locally, or a subscribed feed to places you frequent. Web apps force developers to think about tasks that can be done easily whether the user is on a desktop or portable computer, a web enabled PDA, a smartphone, etc. and focus on the task itself. The purpose of the UI is to enable the user to accomplish the task in as few steps as possible, because the frustration threshold for web app usability is extremely low. It doesn't matter what the underlying platform or browser GUI is, if the user experience is not comparable to the best there is out there, people will flee. This is why, even if the brushed metal UI in iTunes is IMO totally unnecessary, as a web app it succeeds, because it allows the user to accomplish the task of searching for and buying legal music downloads, as easily as possible. When you're competing against free, you have to give the users a better end-to-end experience, and the iPod-iTunes-ITMS combo is, without a doubt, the best there is right now -- even on the Microsoft campus, most of the portable music players are iPods. :-)

Aaron wrote: Let’s say that you decide to change Copy and Cut’s menu shortcut to be Ctrl+C and Ctrl+Shift+C (or Cmd+C and Cmd+Opt+C if you prefer) because you understand that cut is just a specialized form of copy (copies, then deletes) and the shortcut makes more sense than Ctrl+X does. Now… distribute your application and see what user’s reactions are going to be. I can promise you that you’ll bar tarred and feathered. Logically, the idea makes sense – but it’s not what users expect.

Uh, Ctrl-X makes far more sense for cut. Why? X is a universally (well, almost) identifiable mark for a cutting point (because of the physical resemblance to open scissors), and I've never heard of C-Acto knives, either, have you? :-)

@Victor -- are you always so pendantic? ;-) I fully comprehend *why* Cut is the way it is today. I was just making an example of changing a standard shortcut that everyone uses to something that's not standard for the hypothetical sake of "being innovative". After all, even though X is the universal mark for a cutting point, it's just as easy to think of Cmd+Option+C as being an alternative form of copy.

Aaron wrote: it’s just as easy to think of Cmd+Option+C as being an alternative form of copy

Maybe for you, Aaron, with your Windows-warped ;-) mind, but I don't have too many neurons left, and Cmd+Option+C is just way too complicated for me. Ctrl-drag (Win) or Option+drag (Mac) does it for this old geezer.

LoL, that's kinda funny because the one thing I learned when I came over to the Mac is that Cmd+Option is always used to specify the alternate action for menus. So Cmd+H is hide, and Cmd+Opt+H is hide others for example. So I figured that I picked a somewhat realistic alternative for Cut based on a concept most Mac users would recognize. :-P

Aaron observed: "Where I think we don’t see eye-to-eye is at which level of software development the user experience changes should occur"

Probably. Because I support web and non-web apps, I place a great deal of importance on UI discoverability, especially for functions that will be used only occasionally. A close friend who is an interaction designer is currently working on a web UI for a smart home control center; he prototypes on MacOS X and tests on WinIE, Firefox, and Safari. Everything -- icon design, typography, widget behaviour, visible feedback, navigation/wayfinding -- is identical across browsers and platforms. If you've set up a Linksys broadband router, you'd remember that between the firmware revisions there've been major changes in the device configuration UI, and of course the UI on a D-Link or Netgear is different again. The GMail interface is a good example of simple design that works well across all supported platforms, and for B2C ecommerce, the Panic online store cited above is an outstanding design. Why? User goal: buy T-shirt in as few steps as possible. Drag image of shirt to shopping cart "region" (whoa, look at the target sizes!). Change your mind? Drag the shirt out of the shopping cart. Does it correspond to the physical act of purchasing a shirt? No, it IMPROVES on it, by making it easy to quickly evaluate appearance, choose a size and quantity, then add to a "basket". If only all web apps were so easy to use!

Aaron wrote: I picked a somewhat realistic alternative for Cut based on a concept most Mac users would recognize

Well, maybe I'm not as much of a "Mac" user as I like to think. Even though I use MacOS X and WinXP side-by-side every single day (I have both in front of me as I type this on my WinXP box), I'm mostly interacting with web apps. I love the term "discoverable" because -- especially on the web -- there's a certain amount of UI divergence that can be overcome with discoverability (although common UI metaphors are still important) and allow developers to push innovation. A good illustration of the almost infinite malleability of web interfaces is http://www.csszengarden.com

Aaron, I'm not sure that I agree that Apple (or Microsoft or whoever) should be the only ones doing the UI innovation. Apple has no idea what interface items developers are going to need.

Consider the "floating window." That was done, originally, by Aldus and was against Apple's UI Guidelines. But it worked--people understood what the window was doing and why it floated above all others. And it forced Apple into providing a consistent way of doing these tasks.

Tog has a great example--I remember using this program, but I can't remember it's name--of a paint/drawing program. You were in one of two modes--painting or drawing. When you were in paint mode, one of the menus at the top changed to "Paint" and it had a bunch of options which made sense for painting. When you were in draw mode, the menu changed to "Draw" and had a bunch of options which made sense for drawing. Nobody really got confused because the user had changed the mode from painting to drawing, so the menu change made sense. But this is expressly forbidden by Apple's Human Interface Guidelines. So should they have had a Paint and a Draw menu and have the inappropriate menu dim?

Again, the guidelines are called "guidelines" for a reason (versus "standards", "requirements", etc.). There will be times when it might be a better idea to color outside the lines. But you need to know when to do it and when not to do it. In your example, above, of command-option-C for Copy, I would shoot any developer who came to me and suggested this because, to me, I can think of no reason to do it that is worth the confusion it could cause (ESPECIALLY if the argument was "Then we could use command-C for something useful, like 'Collate'"). But if you can SHOW that there would be no confusion (like the paint program above), or that any initial confusion would be offset by the improved productivity (like the Aldus example), I don't think you need to wait for Apple's blessing. And when I say show it, that means user testing--not a bunch of programmers sitting around in a conference room imagining what users will do.

By the way, I'm sort of curious: You talk about how Windows programs shouldn't work like Mac programs, and vice-versa. Yet you develop a programming language which, if I can read between the lines, creates just such an environment. How do you reconcile those two things?

I have one question from your original post. First, I use both systems at work and at home. I have come to prefer the Mac at home solely because I don't have to worry about Ad-Ware (of course all my family and friends constantly need me to clean their system for them). I'm also a Realbasic developer (mostly hobbyist, but I have written a few for work) and I use the Mac UI. I bought the RB for Windows first, and after struggling for a few months with GUI issues (mostly container controls) I paid the extra money to switch to the Mac GUI.

Here's my question (I'm only asking for clarification). I felt that you said Windows MDI apps, in an attempt to mimic the Apple Menu bar, was wrong. If this is what you meant please explain to me what you consider the proper use of windows/menus.

I ask because the first app I wrote for work (my co-workers are Mac Zealots) was widely disregarded as unusable. 99% of my computer use experience was on Windows and I designed the application like I'm accustomed. All features were in one window controlled by deep tab and page panel options. So I redesigned the interface and seperated all those tabs and pages into their own little windows. Now they love it and use it all the time. They think it's an entirely new application when it's really only a redesign. However, taking this application to the Windows side now requires MDI unless I build a toolbar window that acts as the Apple Menu bar. So how would I be able to compile that application to Windows without MDI? The only answer I see is what you've already mentioned...A completely seperate interface for each platform. If the MDI works just fine and is usable why wouldn't MDI be the right answer?

I look forward to your answer. I've actually just finished an application that I'm going to post for free use on the web. The several people who are beta testing this for me (All windows users) love it. It's a MDI. Now I'm worried that public scrutiny will reign upon me like ash from a volcano. I'm too sensitive to handle that. ;)

@Steve -- I'm not Aaron, but oh well :P MDI fits for some programs, but as you probably felt with REALbasic 5.5, it doesn't fit for all of them. That's one of the reasons we're rewriting REALbasic from the ground up using REALbasic.

The alternative to MDI is to try to have a main window that contains most of your core functionality and your main menubar. Try to limit floating windows, and if you have to bring up another window, make it a movable modal dialog. The difference between the Mac and Windows/Linux is that on the Mac, individual windows aren't their own application, while on Windows, they are treated like their own application. This is, IMHO, one of the hardest obstacles in cross-platform development, since it's the core UI of the application at stake.

REALbasic 6 is moving to a more all-in-one UI, which works well on all platforms. Most things are modeless, and in-line in the main window, and very few dialogs are used.

However, the bottom line isn't what Aaron or I or anyone else tells you, it's what your target audience wants. It's great to do usability testing. It's the best tool to evaluate your UI, because in the end, the UI guidelines are only guidelines, and your users are what matter the most.

@Aaron -- I agree with Brady and Jack, edit your template to increase the size of this text box by a few rows :)

Steve wrote: "They think it’s an entirely new application when it’s really only a redesign"

Steve, to the end user, the design IS the application -- and by design, I don't mean only the visible appearance and also the interaction behaviours, but indeed the whole 'gestalt' of the app. I caution against approaching UI design only from the perspective of "What are the basic UI guidelines for platform X vs platform Y" -- it's necessary to do one's homework, but don't stop there; this constrains thinking about the best way to accomplish the task. First, approach it from the end-user's point of view: What do I want to do? How often will I use this feature? Etc.

I'll illustrate using a web app for buying clothing. Most online stores present a photo of the item, then you click on a button (usually) to add it to a shopping cart, and so on. First observation: the user usually has to toggle between browsing and adding to the cart because most B2C store interfaces require you to go back to product detail pages after first repainting the browser window with the shopping cart status. So the interaction is mode-constrained. Contrast this with the UI of the Panic store (http://www.panic.com/goods), which is modeless while browsing and adding to the shopping cart -- you DRAG the items to a VERY LARGE target area that represents the shopping cart. To remove items from the cart, you DRAG the items out of the target area. Is this very different from MOST online store interfaces? Absolutely. It also happens to be a HUGE improvement on the prevailing UI model for online store interfaces. THAT is useful innovation. It also happens to mimic some of the UI behaviours of MacOS X, which as I've already pointed out, is unsurprising, since Panic is a Mac software developer. As another data point, PC Magazine recently singled out iWork (Pages and Keynote) as innovations in "office suite" application design, i.e. other software developers can learn from Apple how to make end-user's tasks easier. Coming from PC Magazine, that is high praise indeed, and it should give us a clue about why "Mac zealots" are so wedded to the "Mac way" of doing things.

@Victor -- iWork is great, but if you put that UI on a Windows box as-is, you wouldn't steal many users from PowerPoint or Word. On the Mac, it works great because it's what Mac users are used to. However, on Windows, the users are not used to it, and in the end, what feels familiar will prevail. I realize that there are exceptions, but in general, whatever makes the user feel at home and productive is what they will use.

@Jonathan

I know who you are. I visit NilObject frequently. Based on your response the answer then is "You must design two completely different UI's". In the situation I am in at work it doesn't matter because it's all Mac people (Graphic Designers). At I'm only working with databases, which of course means lots of screen real estate, and therefore lots of tabs and page panels for the Window UI. Back in 4 they just didn't work very well. They'd lose their parent control and I'd lose my patience. LOL

BTW, I'd love someone's opinion of my application. Primarily my use of classes and such. I'm only book learned and books never really tie the entire application design together very well. They're great for specific functions and such. So if either of you would ever be kind enough to look my source over I'd b e most appreciative.

Jonathan, I agree that an app UI has to build on the UI behaviours that the underlying platform supports. But I've also noted how the platform neutrality of web app design tends to make moot the established UI conventions of client platforms. On startup, MS Office presents a plethora of toolbar options. We've gotten used to this clutter, and in fact we mentally tune it out. I've used Word (since the DOS days -- heck, I go all the way back to WordStar, though not Electric Pencil), and I've used Pages. Let's go back to why a word processor exists: to write and edit words and then format some documents for output. For 1-2 page letters, WordPad should suffice, and it may very well be that most office workers need only that. But now they're stuck with Word; it's like driving a Hummer where a SmartCar is what's needed. My point: a Hummer may be a more imposing and impressive vehicle than a SmartCar, but does this make it the most appropriate means of transport? Pages brings back some of the simplicity of earlier GUI word processors (e.g. MacWrite, WriteNow, Word 5.1), and yet it scales to make adding rich media drag-and-drop simple. As a former PageMaker user, I'm amazed at what the Pages UI lets the user do easily. If users feel at home and "productive" in the bloated UI swamp that is MS Office today, that's also because they're so used to it and can't imagine anything better (e.g. powerful yet simple). Powerful, feature-rich software is one thing; a feature set that is easy to discover as you gain mastery is another. And for people who just want to make a snapshot look better without tweaking levels, curves, and adjustment layers, Picasa's one-click "I'm Feeling Lucky" is sometimes all that's needed to "Make it so." :-)

Peter wrote: I remember using this program, but I can’t remember it’s name–of a paint/drawing program. You were in one of two modes–painting or drawing.

It was called SuperPaint, and it was eventually acquired by Aldus. Conceptually, Deneba Canvas built on the paint and draw model, and Canvas 9 is still published today, for both WinXP and MacOS X -- http://www.deneba.com/

I mentioned that SuperPaint was acquired by Aldus. I forgot to mention that its original publisher was Silicon Beach Software -- for history and trivia buffs, see http://www.webstudio.com/site/about.asp?Page_Id=100

Sheesh, I'm gettin' old. :-)

Usability trivia bit: A couple of years back, I was in a software open house held at a local technical institute, and one of the factoids bandied about was that, in my city, about 30% of all help desk calls have to do with Outlook. Now if an app as widely used as Outlook causes 30% of all help desk calls, we may very well conclude that (a) users are dumb or (b) the Outlook UI and feature set is overly complex and intimidating for the functions/tasks supported. Same with MS Entourage -- I've actually seen people switch to Mail.app precisely because Entourage had TOO MANY features that they weren't using, and they said to heck with it. It's the old dilemma of how to expose functionality to the user in such a way that they'll use what they need for daily work, and if they're curious enough and inclined to explore, a discoverable, non-intimidating UI will scale with their increasing mastery of the app's feature set. When I show folks that Outlook has a Notes feature (equivalent to Stickies in OS X), most of them get this "Why didn't I use that before?" look on their faces. Usually the same people whose monitor bezels are plastered with paper sticky notes. :-)

Aaron, if you had posted the above first, a lot of misunderstandings could have been avoided. If it was an attempt to lure for the purpose of staging an intellgent debate, well, count me as a sucker.

First, I just want to talk about the only Windows UI feature to have been copied by by the Mac. I'm sure there is another name for it but I prefer to call it "sticky menus". On the original Mac OS, to select a menu item, you had to mouse over the menu title, hold the mouse button down and drag to the item and release to activate. If you wanted to cancel just move the mouse off the menu and it would disappear. Simple enough. System 6 introduced hierarchical menus (i.e. flyout menus). As programmers tend to do, they took this idea to sometimes ridiculous extremes, creating two or even three levels of menus. The problem was that you had to hold the mouse down while navigating this hierarchy and if you inadvertently moved off the any of the menus, the whole thing would roll up and you had to start over. Windows came with the idea of: Click to make the menu appear; Click again to make the flyout appear; Click on the selected menu item to activate. To cancel, click off the menu to collapse. More mouse actions but less chance of error. Apple threw in the towel and switched over to this method with System 8 and still uses it. Now I don't think this shows any particular insight by Windows UI designers. They just came to the party later when the problem was obvious and they didn't have to worry about old baggage. Have to split my time between platforms (Windows by day, Mac by night) I didn't have a problem adjusting although I wish Apple had made this behavior user selectable via control panel.

As for the single-menu-bar versus menu-on-each-window difference. I definitely prefer the Mac way. Why? Because I think a menu bar on each window increases screen clutter and single bar avoids a major inconsistency. Here is an real world example of a UI annoyance on this with Windows courtesy of Microsoft Outlook. When you start Outlook, you get the main window with all the mainboxes, calender, contacts, etc. Compose a new email message and a new window with an identical menu bar appears although this window has an entirely different purpose. Now, suppose you close the main application window by mistake. How do you get it back? Outlook is still running because the message window is open but there is no menu selection to bring back the main page. The only way, I found, is to quit Outlook and start all over again. The single menu bar avoids this by enabling/disabling menu items depending on the application context.

Now, I want to mention, what I consider, the most serious design flaw in the Window UI. That is, how it treats foreground widows versus background windows. Anybody who does cross platform development better be careful of what is probably the most drastic difference between the UI's. To explain, on the Mac, if a window is in the background, it first must be clicked to be brought to the foreground. Then actions can be performed in that window's application. On a programming level, the OS sends only an activation event on the first click and a mouse-down on the second click. With Windows, the OS sends an activation event AND a mouse-down on just one click. The upshot is that on Windows there is no such thing as a background application window. What you really have is foreground windows and partially or completely obscured foreground windows. The UI tricks us in assuming that things in the background are inactive because it dulls the appearance of the window, but it is just as alive as if it were in the forground. Plenty of room for unintended actions there.

That's enough for now. I hope I've given people something they can chew on.

P.S. I'm glad to see that you disposed of the use of profanity.

@Steve: No! Don't do two UI designs :) The only time where that's good is if the only way to make your application feel native is to do that. But, in most cases, there is a UI that will feel native on all platforms, with minimal changes. If you've already done some testing with users, and they like the way it looks and feels, roll with it. If you get complaints, then evaluate what the complaints are caused by, and evaluate from there.

@Victor - Panic is great. I love their software. I feel like we're arguing for the same side here :) I'm not talking about the feature set of Pages, or the bloat of Office. All I'm talking about is what the user cares about, which is feeling like they are productive. I haven't used Pages much more than a little bit at the local Apple store, but I have used Keynote and won't go back to PowerPoint. But even in porting iTunes (which Aaron despises on Windows :P), Apple had to change some UI. They balanced their UI decisions with the Windows experience, threw some stuff out the door, let some stuff in. In the end, they have people like Aaron who detest their user interface, and others, like me, who like it.

Ah.. PageMaker. I loved and hated that program. I used it in high school as our school's newspaper editor. Fun times... But enough reminiscing ;)

As everyone can see, UI design isn't an exact science. UI guidelines are guidelines, not requirements. While if you follow the guidelines you will generally feel good on that platform, there are good and valid reasons not to adhere to the guidelines exactly. The best thing to do is ask your users and do usability testing. You may think that your interface is perfect, but just watch someone try to use your application, and see what happens. I'll end this comment with a quote from The Graphing Calculator Story:

I had long been proud of the elegance and simplicity of our design. I wanted our program to ship with every Macintosh, so I had designed it for all users, even those who know little about computers and hate math. I wanted to make mathematics as easy and enjoyable as playing a game. In a classroom, any time spent frustrated with the computer is time taken away from teaching. Sitting behind a two-way mirror, watching first-time users struggle with our software, reminded me that programmers are the least qualified people to design software for novices. Humbled after five days of this, Greg and I went back and painstakingly added feedback to the software, as if we were standing next to users, explaining it ourselves.

"@Victor – iWork is great, but if you put that UI on a Windows box as-is, you wouldn’t steal many users from PowerPoint or Word. On the Mac, it works great because it’s what Mac users are used to. However, on Windows, the users are not used to it, and in the end, what feels familiar will prevail. I realize that there are exceptions, but in general, whatever makes the user feel at home and productive is what they will use."

From a user standpoint this statement makes very little sense. It is like saying we are going to dig a hole. Here is the shovel that you are used to. If you look over to your left there is a back-hoe. If I show you how to use it you will be able to dig that hole with much less time & effort. Your answer is that most people will use the shovel.

Jonathan wrote: "All I’m talking about is what the user cares about, which is feeling like they are productive."

Ah, yes. Feeling like they are "productive"... a few weeks ago I had to rescue a massive Word document an engineer had been struggling with (crashing Word 2000 on Win2K and Word X on MacOS X)... I imported it into AppleWorks 6 on my iBook G4 (didn't have Pages yet, and TextEdit mangled it), extracted as much of the content as I could, and gave it back to him in plain text so he could re-apply styles. It was a Frankenstein document, with section formatting and paragraph styles from untold ancestors... anyways, one of my pet peeves is a word processor that tries to do double duty as a page layout program and fails miserably. I haven't stress-tested Pages enough yet to see if it will ultimately pass the annoyance test, but its default UI beats the heck out of Quark 6.5 and InDesign CS, which I also have to support... *sigh* So many apps, so little time...

The Graphing Calculator story is a must-read for all SW developers and UI designers (and the Slashdot thread it spawned was pretty amazing, too). Also, read Dan Bricklin's essay on 200-year software; the original link is down but you can get the gist of it, and another SW engineer's take at

http://ose.typepad.com/neils_blog/2004/07/

I'll close with some choice quotes from the recent Fortune article on Apple's software innovation (online access is subscriber only but you can get in using bugmenot to get a subscriber number):

I remember sitting with Steve and some other people night after night from nine until one, working out the user interface for the first iPod. It evolved by trial and error into something a little simpler every day. We knew we had reached the end when we looked at each other and said, "Well, of course. Why would we want to do it any other way?"
— Jeff Robbin, lead software designer for iTunes and the iPod

Your typical corporate CIO must be wondering, "Why aren't there some nice new exciting applications for me?" Nothing has really changed in his world, while on the consumer side there's all this cool new stuff like iTunes and the iPod and iPhoto and iMovie. That's where the real innovation is now, and Apple is driving it.
— Bill Joy, co-founder and former chief scientist at Sun Microsystems

"Everyone in every corner of the software business could learn a lot from iLife" - Bill Joy

Powerful, feature-rich software that's also easy to use... what a concept!

SpongyBoy wrote: "Your answer is that most people will use the shovel."

ROFL -- perhaps these are the same people who have "cupholders" in their PCs.

Why a One-Button Mouse Makes Sense (Even Though I Often Use Multi-Button Trackballs)

Help Desk Analyst: Click on the green square to highlight it.
PC User: Left or right click?
Help Desk Analyst: Left-click.
PC User: What's next?
Help Desk Analyst: Now click on the green square again to bring up the options.
PC User: Left click?
Help Desk Analyst: No, right-click.

On the Mac, there is NO amibiguity in the out-of-the-box default. It's CLICK the ONE mouse button. If you design your app UI so that right-clicking is required for essential tasks instead of offering ADDITIONAL, secondary shortcuts for "power" users, you have just managed to create opportunities for new-user confusion. As the Graphing Calculator author stated: "programmers are the least qualified people to design software for novices" -- ain't that the truth. No matter how familiar a user may be with the UI for the underlying platform, every app that tries to solve an unfamiliar problem domain (video editing, etc.) has novice users. This is even more true of web apps, and we all know how poor web UI usability leads to abysmally low site traffic. Does the Panic T-shirt store require right-clicking? Do most web apps? Nope. Right-clicking in a web app makes about as much sense as using a shovel when a backhoe is available.

Aaron wrote: "Everyone deserves to be able to use a computer."

Nope. I can think of a few obvious exceptions: criminals, murderous tyrants, liars, and the glaringly incompetent, like the new PC owner who said to the help desk analyst: "You mean, I have to turn it on?" ;-)

Disclaimer: I once set up a desktop PC and a portable PC for a blind person. His Braille printer made the most awful noise when printing, and the synthesized speech from the screen reader hardware grated on my ears as well. But I agree with the general sentiment in your statement, I'm just being pedantic, as usual. :-)

Sheesh, I come back to a whole ton of comments (that's what I get for leaving my computer for 12 hrs I guess) :-P

@Peter -- "By the way, I’m sort of curious: You talk about how Windows programs shouldn’t work like Mac programs, and vice-versa. Yet you develop a programming language which, if I can read between the lines, creates just such an environment. How do you reconcile those two things?"

Well, it's actually rather difficult in some regards, but easy in others. The basic ideas and controls are the same between platforms (for the most part). Every OS has a button control and they all do the same thing, for example. So we provide a consistent API across the platforms in most cases. Where things start to break down is when there are concepts that exist on one platform but not another (sheet windows on Mac, the Registry on Windows for example). And in that case we provide the user with the native control where we can, and a reasonable alternative on the other platforms. For example, a sheet window becomes a document modal window on Windows. However, we don't try to port all concepts -- so the RegistryItem class only works on Windows and does nothing on Mac or Linux.

@Kurt -- Apple has yanked many more ideas from Windows than just the menu activation. The easy ones off the top of my head: full keyboard access, Rendezvous (which is a better form of uPnP), the multicolumn listbox control, combo boxes, etc. And Microsoft has stolen tons of ideas from Apple as well. It doesn't matter who comes up with them first though , the point is that there are specific guidelines to follow on every platform and developers coming from anywhere should work to follow them as best they can.

@Everyone else -- as for whether innovation should come from the OS vendor or not -- I still claim it should. If you want to innovate and do something non-standard because your application would be horrible to use another way, then go ahead and innovate. It's why they're called guidelines -- you don't *have* to follow them all. But there are a number of reasons why doing non-standard things isn't a bright idea (even aside from breaking the principle of least surprise). For example, what you're doing may very well rely on a bug in the OS APIs, which could get fixed at some point and your app breaks. If you do something new, and the OS vendor gives it their blessing, then great, others will gradually begin to use it and users will come to expect it. But that doesn't mean that it's peachy to take known UI concepts and break them because that's how it's done on another platform.

@Jon, Brady, etc -- there, the text area is larger now. :-P