User Interface Changes for Mac when Porting Windows Application

Question

I have an existing windows application, for which I have decided to create a Mac version. The problem is that the current UI involves a lot of buttons, tabbed panels, multiple windows etc.

This UI had been rated as intuitive and easy to use and straightforward by many customers and editors. But a beginner (very less experience) may find in confusing a little, but it has been complemented with tutorial.

When creating the Macintosh variant, should I focus on creating a simplified and minimalistic UI (this does not mean the current UI is complex, but I think Mac user's prefer a simple UI right?) or should I try to copy the exact same thing?

By reducing the UI some of the features may be missing. But it can be added later if needed. Should I focus on a fresh approach (this is easier rather than copying the complex UI pattern) or should I go with the old recognized setup?

Answer 1

Apple has created the OS X Human Interface Guidelines, which describes the user interface, and other aspects, ought to behave on OS X. Moreso than Microsoft or other companies, Apple strongly encourages developers to follow these guidelines and I believe that OS X users have an underlying assumption, whether they realize it or not, that an app they use will follow it.

In the preface, Apple says what OS X users are looking for:

OS X users have high standards for the apps they run. Meet these high expectations by designing a user experience that is enjoyable, streamlined, easy, and adaptable.

You want people to feel that your app was designed expressly for the OS X platform.

There are myriad details you need to handle as you design the UI of your app, including choosing the right menu items, naming new windows correctly, and using the appropriate controls in a toolbar. Don’t be tempted to ignore the guidelines that govern the use of these UI elements, because users tend to notice even subtle differences in appearance and behavior.

The document goes into greater detail about what these actual changes are, but notice that it's describing little things like menu items and window names and not sweeping changes like massively simplifying the UI. For instance, it describes that Preferences ought to be in the Application menu, rather than the Edit or Help menu like is commonly done on Windows. Similarly, menu bars in-window and shortcuts activated with the Control key are fine on Windows, but on a Mac you need to use the menu bar at the top of the screen and have shortcuts use the Command key. Violating user interface conventions like that are a sure way to make your app "not belong" on OS X, which Mac users are particularly sensitive to.

I think that Mac users prefer a simple and minimalistic UI just as much as, but not more than, users of other platforms. While it's true that Apple has been trending away from skeumorphism and towards flat UIs, the extent to which this has been done in the most recent version of OS X are not nearly as pronounced as the changes done on iOS 7. At any rate, that's an issue involving custom-designed UIs and seems to match a general trend among user tastes. If you're using system-generated buttons and other UI elements, you'll absolutely be fine as it will render such elements as other OS X apps do (and future-proof it in case Apple changes the style).

However, Mac users are probably a bit less tolerant of bad UIs, which may be part of the "simple" thing you were going for. I think that's more because developers tend to pay more attention to the UIs, in part because of the emphases on the Human Interface Guidelines, so they are just more accustomed to seeing good UIs than bad ones.

So your best bet is to focus on matching the little UI things that are defined by the Human Interface Guidelines. Another great thing to do is to use lots of OS X apps and get a feel for how things are done. Sometimes Apple violates their own guidelines (iTunes is guilty of this), but in general, I think you'll see a lot of consistency and will get a feel for how it's supposed to behave.

I'll add that if you are using a completely custom interface (e.g. custom-drawn buttons that are different than the standard operating system buttons), then you probably are fine on another platform so long as it doesn't violate any expectations OS X users will have. In that case, you shouldn't need to redesign it.

I personally have a cross-platform Java app that uses standard UI elements, so those are automatically drawn by OS X. I only have one code base, but make checks for the target platform at various points (e.g. if on OS X, put the Preferences menu item in the Application menu, else put it in the Edit menu). The user interface has been well received by OS X users, which I take away as meaning that they don't necessarily care about a minimalistic UI, but rather one that is consistent with the OS X Human Interface Guidelines, whether they realize it or not.

Answer 2

Microsoft and Apple have slightly different UI guidelines, which I think you should adhere to. It may be important to note that the latest OS X Human Interface Guide hints a near-future shift towards touch supportive desktop interfaces. Which, if complied with, could mean a radical application redesign. The same is also already true for windows 8 applications.

Other than that, I believe that a system should be similar (excluding OS controls such as file dialogs) and equally usable on both PC and Mac. I fail to think of a single application that has Mac/PC UI variants (say, Photoshop, for instance). Some applications running on a PC are minimalistic, whilst some running on a Mac are complex. Users just want their needs met in the most efficient way, regardless of whether the application runs on this OS or another. Mind you, the popularity of web applications (eg, gmail) mean that users are accustomed to a variety of interfaces, particularly on desktop machines.

I think your question applies much more to mobile devices, where 'native' interfaces are much more obvious than on desktops.

Answer 3

Having a simple UI does not need to mean a loss of functionality, it means a prioritization of functionality.

I would suggest "focusing a fresh approach", as you said, and when you do so, start with the following:

1. List all your desired functionality and features. Distinguish between the two. Functions are transparent to a user, while the features fit into the user story.
2. Group the functions and features when appropriate. Features and functions that relate might combine well together in the UI
3. Prioritize the functions and features. 20% should be high, 30% medium, and %50 low. This distribution is important. If everything is high or equal priority, it may cause a lack of direction and understanding of where to focus for the user.
4. Use this prioritization to make design decisions. The high priority items should be visible right away, while the lower ones may be hidden by an action or two.

Answer 4

Mac users can deal with complex UI, like Adobe and Maya. Windows users appreciate streamlined interfaces as much as Mac users.

When porting to Mac, it is essential that you have genuine Mac UI person on your team, who understands specifics. Some typical issues are:

1. Macs have different common menu layout and keyboard scheme. Make sure your Preferences and Exit are in the Application menu among other things. "Exit" is named "Quit". It is ugly and confusing when your application has "Quit" in the Application menu and "Exit" in the File menu.
2. Integrate Mac UI elements. Personally I find it really irritating when document-oriented applications don't show document proxy icon on the titlebar or use status area on the menu bar to show information that belongs to Dock icon.
3. Pay attention to install experience. Do you want to distribute through the App Store? Read the guidelines, they may impact your system design.

Answer 5

You should create the application that your target users need.

This means that you should understand why Mac users would want to use your application, what competing products exist on the platform, and how your product would fit into their current usage. Additionally, you should understand whether your target Mac users would also have experience with your existing Windows application.

The application that you create should not have an identical UI to its Windows counterpart. Your Mac application should follow the Human Interface Guidelines. If you choose to break a guideline, you should have a very good reason for doing so. One of the definitive characteristics of the Mac platform is the high degree of consistency between applications, regardless of who developed them. For example, I recommend keeping the common Mac keyboard shortcuts even if your existing application uses those keyboard shortcuts for something else.

The application that you create might or might not have all of the same features as its Windows counterpart. This goes in both directions: you might have features that are unique to Windows, you might have features that are unique to OS X. In both cases, the application should fit the needs, expectations, and aspirations of the user.

It is not true that Mac users expect a simplified experience, if your definition of "simplified" is that there are fewer features. It is true that Mac users expect that applications support their overall workflow, and that it should be easy to complete the most common tasks.

Answer 6

Your decision should not just be based on the UI experience, but also on your maintenance and development model. If you have enough resources to maintain two applications (one on windows, and one on Mac), you could of course "streamline" each of the programs for the specific OS. Especially, when you have different teams for both applications.

But if you have only one team for both, or you are the member of your one-man-team, then you typically want to maintain only one source code for both systems (with different compile time configurations for each system, of course). In this case, you should try to keep things as equal as possible, so you avoid to fix each bug twice, to maintain double documentation etc.