I had a small difference of opinion with a colleague today. It wasn’t anything big, but I was intrigued by our difference in “common sense” when it came to design (application design not graphic design).
My colleague predominately uses Windows (perhaps exclusively), and I predominately use Mac. I realized the difference came from frame of reference. There are very slight, but fundamental differences between the way one interacts with both operating systems. Using either one for an extended period of time seems to make one kind of “think that way” - if you get my meaning.
I, of course, try to design the Mac way. Someone who uses Windows might tend to default their design to the way Windows works. In general when I show someone the small differences in the way Mac works compared to Windows XP they often like the Mac way better. However, they generally say something like “but people are used to XYZ” - which is valid.
So in order to help translate between the two design philosophies (in a very small way), I made this short screencast. I hope it lets Windows only users understand where Mac users are coming from (pretty much all Mac users already know how Windows works). In the screencast I show a few (very few) differences in design between Mac and Windows using FireFox as the example guinea pig.
Now remember, I am Mac biased. However, I am not trying to push anything on anyone, or convince anyone of anything - just highlight some differences. Also, these small things are what really irritate me about using Windows XP so you’ll notice my happy thoughts are more towards Mac.
And lastly, Vista could be completely different than XP (can you tell I am trying not to upset anyone?). Ok, here is the movie:
To sum up a few of the basic design elements I think are important:
There are obviously many, many other differences between the two system, but these were some of the main ones that were involved in our discussion. Hopefully, this will help teams mixed with Mac and Windows users to see where each other is coming from.
(I should point out that we did not go with my recommendation on this particular UI element. Going with my suggestion would have been inconsistent with the rest of the application which would have been bad in its own right.)
To your credit, Apple’s user testing confirmed what you found in that you need to “tear” the modality of a window away to sometimes get context for the window you are working on. In your case, to see your changes applied to Firefox. In Tog’s example [search for modal], to figure out what to name your document you are saving via the Save As dialogue.
While I don’t have a document supporting Microsoft’s user testing results, my guess is from my own personal experience is that the vast majority of Mac user’s are more adept at window management. As such, windows can get “lost” to Windows users not familiar with navigating multiple ones, and the taskbar doesn’t help when the modal dialogue doesn’t actually register as a button on the windows taskbar in the first place. Thus, it’s invisible to the user.
That’s effectively 2 problems, which Tog does recommend the fix for the second.
Hi Jester,
I somewhat disagree with Tog’s take on the save as dialog. While I see his point, and wouldn’t mind a free floating “save as”, I’ve personally never had a problem with the current save as dialog because it’s re-sizable (it’s only “hulking” if you make it that way). Here is an example http://robrohan.com/wp-content/uploads/2007/01/MacSaveAs.mov (not to mention when I go to save a document I often know why I am doing it)
Most of the time in Mac the real modal dialogs - the “you can’t do anything until you deal with this” - are attached to the window they belong to (like the save). This makes sense to me because it links the need to deal with it with the window that requires action - whereas a utility or a configuration window might be opened for a longer amount of time while doing other things with the application.
I also see your point with “windows can get “lost” to Windows users not familiar with navigating multiple ones”, but I think the newer generation of computer clients - the ones who grew up with computers (e.g. ~45 year olds down (maybe 35 down)) can handle many windows quite easily - I know my 9 year old nephew can - and I know anyone can learn - my wife’s retired mom and dad can.
This is a touchy subject because it can easily degrade into a my OS is better than your OS discussion, but what I was trying to point out is that “common sense” to a windows only user is vastly different than “common sense” to a predominately Mac user which can lead to “but that doesn’t make any sense” conversations when working together.
Obviously, it’s up to you to decide which is better and more apropos for your own application.
Naw, not touchy at all. Just throw a build in front of your users, see what happens, and there’s your conrete answer!
Interesting points :) I have to say that the lack of OK/Cancel/Apply buttons is actually one of the things that I disklike about how most dialogs in OS X work. The system options / control panel thing is a good example…
Picture a user with that one-button mouse that comes with the iMacs - it is *really* easy to accidentally click that thing even if your hand is just resting in the center of the mouse. Combine that with dialogs where accidental clicks are instantly applied and you have no idea what you accidentally clicked on it makes for a very frustrating user experience. “Oh no, I bumped the damn mouse again and now I’ve turned something off and I want to get it back but I don’t know what it was!!!”. Using Windows conventions of OK/Cancel/Apply you can just click the Cancel button and not worry about what happened because your existing settings will be preserved.
Ideally you would want a combination of the both so that you had some safety mechanism combined with the speed of a real-time preview. The Apply button could be dropped so that all changes were visible in real time (if they even had a visible impact on the application behind the dialog - it really depends on the application), but if the Cancel button was pressed things would still go back to the way they were before the dialog was opened.
BTW, modal dialogs don’t need to appear in the Windows taskbar when they cannot be hidden behind the applications main window ;)