Key differences between Apple and Microsoft's UI guidelines?
March 31, 2010 7:30 AM Subscribe
I'm preparing a talk for my design studio on the key differences between Apple's Human Interface Guidelines and Microsoft's Windows User Experience Interaction Guidelines. Looking for any resources.
I'd like to be able to give a checklist to Mac-centric designers (such as myself) as a way to verify designs against the Windows way of doing things.
Small stuff like the order of "ok/cancel" buttons or close buttons on the top right versus top left, or bigger stuff like Apple's historical one-button mouse and how it affects software design... it's all valuable.
Thanks!
I'd like to be able to give a checklist to Mac-centric designers (such as myself) as a way to verify designs against the Windows way of doing things.
Small stuff like the order of "ok/cancel" buttons or close buttons on the top right versus top left, or bigger stuff like Apple's historical one-button mouse and how it affects software design... it's all valuable.
Thanks!
The GUI guidebook gallery may help with researching differences.
One major difference is that the Apple HIG calls for consistent dialog buttons, and that button labels should be verbs — buttons should call to perform an action on behalf of the user. Windows applications do not have this consistency; specifically, Microsoft seems to encourage confusing Yes/No-style dialog buttons, which is strongly proscribed in the Apple HIG.
Another design oddity in Windows is the counter-intuitive requirement to click on a Start button to shut down a computer.
posted by Blazecock Pileon at 8:33 AM on March 31, 2010
One major difference is that the Apple HIG calls for consistent dialog buttons, and that button labels should be verbs — buttons should call to perform an action on behalf of the user. Windows applications do not have this consistency; specifically, Microsoft seems to encourage confusing Yes/No-style dialog buttons, which is strongly proscribed in the Apple HIG.
Another design oddity in Windows is the counter-intuitive requirement to click on a Start button to shut down a computer.
posted by Blazecock Pileon at 8:33 AM on March 31, 2010
Another design oddity in Windows is the counter-intuitive requirement to click on a Start button to shut down a computer.
I've heard this before, Julie Zelenski mentions it in her Programming Abstractions course. I don't understand what the issue is here? You press the "start button" (as of Win7 is just a Windows logo) and then you press shutdown. It is rare that I shutdown the computer in the first place, so the fact that it can only be accessed from a menu is not a big deal.
I agree with you on the yes, no style dialogs.
You might want to include a discussion of the iPad's use of non-modal windows:
I've heard this before, Julie Zelenski mentions it in her Programming Abstractions course. I don't understand what the issue is here? You press the "start button" (as of Win7 is just a Windows logo) and then you press shutdown. It is rare that I shutdown the computer in the first place, so the fact that it can only be accessed from a menu is not a big deal.
I agree with you on the yes, no style dialogs.
You might want to include a discussion of the iPad's use of non-modal windows:
I don’t recall encountering the modal variety during my all-too-brief iPad spelunking expedition; the non-modal ones seem far more prevalent.posted by geoff. at 9:09 AM on March 31, 2010
The overall effect of popovers is that you do far less view switching in an iPad app than you do an iPhone app. Things that slide an entirely new full-screen view on screen on the iPhone — like say going back from a message to a list of messages, or displaying your Safari bookmarks, or showing the details of a calendar event — on the iPad instead appear as popovers on a main view.
The biggest difference in my mind is how all mac apps are forced to follow the apple guidelines. They give them less options which makes everything prettier.
Forced? You can do what ever you want. It just turns out that the majority of Mac software developers choose to think about interface usability and design aesthetics.
These are recommended best practices from Apple:
http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIntro/XHIGIntro.html
There are the recommended best practices from Microsoft:
http://msdn.microsoft.com/en-us/library/aa511258.aspx
posted by OwlBoy at 9:51 AM on March 31, 2010
Forced? You can do what ever you want. It just turns out that the majority of Mac software developers choose to think about interface usability and design aesthetics.
These are recommended best practices from Apple:
http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIntro/XHIGIntro.html
There are the recommended best practices from Microsoft:
http://msdn.microsoft.com/en-us/library/aa511258.aspx
posted by OwlBoy at 9:51 AM on March 31, 2010
Well, on second thought you prolly already looked at both those links :)
posted by OwlBoy at 10:02 AM on March 31, 2010
posted by OwlBoy at 10:02 AM on March 31, 2010
Forced? You can do what ever you want.
The only exception to this is iPad/iPhone/Touch development. If you use any Apple widgets in your app, you have to use them in concordance with their interface guidelines or your app will be rejected. If you make your own (non-copyright-infringing) interface widgets, Apple doesn't really care.
posted by Blazecock Pileon at 10:05 AM on March 31, 2010
The only exception to this is iPad/iPhone/Touch development. If you use any Apple widgets in your app, you have to use them in concordance with their interface guidelines or your app will be rejected. If you make your own (non-copyright-infringing) interface widgets, Apple doesn't really care.
posted by Blazecock Pileon at 10:05 AM on March 31, 2010
Menus are grounded at the top of the interface (OSX). The user experience is dictated, left to right, top to bottom. There is supposed to be nothing you can't get to via a click or menu.
Menus in windowed mode in windows (not maximized, not minimized) with overlapping menus leads to the possibility of multiple file/edit/etc menus. Often I see software that the only way to access a feature is via right click in the right space.
posted by filmgeek at 10:29 AM on March 31, 2010
Menus in windowed mode in windows (not maximized, not minimized) with overlapping menus leads to the possibility of multiple file/edit/etc menus. Often I see software that the only way to access a feature is via right click in the right space.
posted by filmgeek at 10:29 AM on March 31, 2010
Response by poster: As a follow-up:
My talk was pretty thin. On one hand, there are a lot of philosophical differences between platforms, but it's best to just read the UX styleguides from each company to get a read on those.
In terms of a checklist for a QA person to go through, I wasn't able to come up with much. Maybe someone will one day.
posted by jragon at 8:22 AM on May 30, 2010
My talk was pretty thin. On one hand, there are a lot of philosophical differences between platforms, but it's best to just read the UX styleguides from each company to get a read on those.
In terms of a checklist for a QA person to go through, I wasn't able to come up with much. Maybe someone will one day.
posted by jragon at 8:22 AM on May 30, 2010
This thread is closed to new comments.
Windows freeware ranges from looking terrible to looking even worse because there is no real standard. Or atleast one that is followed
posted by lakerk at 8:07 AM on March 31, 2010