Mac-compatible vs. Mac-like

Thanks to cross-platform GUI libraries, writing an application that can be deployed on more than just one computing platform is reasonably straight-forward. But there is more to making an application truly Mac-like than just compiling it for Mac OS X.

Beginning of this month, the beta version of OpenOffice.org v3.0 has been released (also see this blog post by my esteemed fellow-blogger, Todd Ogasawara). It is the first release of this open-source office suite that sports OS X's Aqua look without relying on the X11 Window System. But despite the looks, this app still has its share of issues with the feel of OS X, so it serves as a good example for how "Mac-compatible" differs from "Mac-like."

Differences between how it looks-and-feels and how it should look-and-feel can be categorized as follows:

1. No keeping up-to-date with new usage paradigms
2. Non-standard placement or behavior of UI widgets (like buttons, sliders, etc.)
3. Non-standard behavior of direct manipulation techniques

Note that what I describe in this blog post applies to any target platform, as each platform has its own peculiarities and idiosyncrasies that software developers should take into account. In that sense, there's "Windows-compatible" vs. "Windows-like," "Gnome-compatible" vs. "Gnome-like," etc., but, this being a Mac-oriented blog, let's focus on "Mac-compatible" vs. "Mac-like."

Not keeping up-to-date with new usage paradigms

The general paradigm of the WIMP graphical user interface (Windows, Icons, Menus, Pointer) hasn't changed much at all since it first become available to the masses (if you could afford a Mac back then, that is) in 1984. However, it has been enhanced and expanded with new ways of how we interact with the data on our computers, like drag-and-drop, toolbars, and inspector panels.

Speaking of the latter, inspector panels are found in many Mac applications: they are used for changing the settings of the currently selected elements of a document, like, say, the basic page layout of a Pages text document.

What's special about inspectors is that any changes you make are instantly applied to the corresponding elements of the document. That way, you can easily monitor how these changes affect the look of your document and fine-tune them without juggling any dialog boxes. Not so in OpenOffice.org, which still uses modal dialogs.

For setting formatting options in this app, you open a modal settings dialog, make changes, dismiss the dialog by clicking OK, check if the changes to your document are what you were looking for, then go back to the dialog box to tweak the changes some more, etc. etc.

Settings dialogs in OpenOffice.org do not have an Apply button, so you have to dismiss the dialog before you can verify your changes in the document. The fact that the order of the buttons is wrong (for a Mac application), too, won't help much, either.

If you've ever compared both methods side-by-side, you'll agree that the inspector approach is vastly superior, because it let's you concentrate on implementing changes to the document, i.e., on the real work you're performing, whereas juggling the "classical" settings dialog boxes in OpenOffice.org adds way too much UI overhead for these kinds of tasks.

OpenOffice.org's is not really un-Mac-like in this regard, though, because there are still many Macintosh applications that use modal dialog boxes in a similar way. This is more about not keeping up with new current developments in UI design than being truly different. Non-standard placement or behavior of UI widgets, though, is about being different.

Non-standard placement or behavior of UI widgets

Apple's Human Interface Guidelines are very specific about the look-and-feel of dialog boxes, including where to place which buttons. The key thing here is consistency: once you've gotten used to a certain way of "reading" a dialog box on OS X and, thus, expecting the button for the "most appropriate action" in a specific spot within that dialog box (namely the lower-right corner in most cases), noticing that another button has been placed in that same spot will kick you out of your (work)flow instantly.

This is not about rules for rules' sake, mind you, but all about feeling at home in your work environment, and just like even a misplaced flower pot in your office or cubicle may do bad things to your concentration and feeling-at-ease to get work done, so will non-standard placement of UI widgets like buttons, sliders, etc.

Case in point: when trying to close a document that has not yet been saved, you're presented with a dialog box asking if you would like to save the document to a file, discard the changes, or cancel the task of closing the document window.

Pages uses OS X's standard implementation of that dialog, which sports a clean, spacious (dare I say "pleasant"? Oh, I just did...) layout and places the "Don't Save" button away from the Cancel and Save buttons. Which is good design, (and not just because the HIG say so, but) because it provides a clear visual and mouse-targeting differentiation between the one button that, when clicked, will lead to data loss, and the two buttons that are safe to use.

OpenOffice.org, though, not only gets the Cancel and Save buttons' order wrong; it even places the "dangerous" Discard button right between the other two with hardly any space between them. All it takes to lose your whole document is a quick slip of the hand while trying to click the Save button. Ouch.

Non standard-behavior of direct manipulation techniques

Direct manipulation goes even deeper than standard UI elements in that the functions available to you as a user may not be obvious.

When you look at a menu or a dialog, the options are right there in front of your eyes: want to know which options you have for creating a new file? They're (usually) all there inside the application's File menu. What formatting options do you have for a table in Pages? Open the Table pane in the inspector panel and "what you see is what you can set."

Direct manipulation is different: you do get to see the result of a specific action you perform, of course, but, more often than not, there is no indication as to which actions are available to start with. Take text editing.

When you select a piece of text, that text will be highlighted. But just by looking at the text container itself, you cannot tell which methods you can use to actually select any of the text. You can't tell just from looking at the text container that holding the shift key while moving the cursor with the arrow keys or the mouse will select the text that the cursor passes over; that double-clicking a word will select the whole word; or that click-and-dragging selected text will move it to a new position or even create a text snippet file if you drop it into a Finder window.

This is the kind of usage patterns that do not have implicit, built-in documentation -- like the items in a menu, e.g., --, but you have to learn them the old-fashioned way until they are ingrained in your motor memory. And you will also need to learn which techniques are not available in a given context.

To use a specific example, the following key combinations are very useful for quickly moving around in a standard text document in any Mac application:

• Command-[Left|Right]-arrow moves the cursor to the beginning or end of the current line
• Command-[Up|Down]-arrow moves the cursor to the very beginning or end of the document
• Option-[Left|Right]-arrow moves the cursor to the beginning of the previous, or the end of the next word

From that list, OpenOffice.org only supports the third item, and it will always move the cursor to the beginning of the next or previous word. Hence, if you're editing a document and you'd like to select the text from the current cursor position to the end of the file, just hit Command-Shift-Down-arrow. Unless you're using OpenOffice.org, in which case you'll be stopped dead in your tracks, wondering why this doesn't work, and what other option is there to perform this action.

One such option is to revert to the mouse, but even that behavior is different from the True Mac Way™ which would be to double-click-and-drag on a word in the text so you can extend your selection whole word by whole word, and if you drag the mouse all the way into the top-left or bottom-right corner, you select the text from the word you started out from, to the very first, or last, word, respectively.

Again, not so in OOo, where you have to precisely position the mouse pointer to achieve the same result, and you cannot select preceding or following empty lines that way, either, as you can see in this video:

Maybe OOo does support all those cursor positioning functions I described above and just uses different keys. The point is, however, that if there are established defaults for such keyboard commands, don't make the users learn new ones, but just adopt those defaults in your application.

Don't rely on technology; rely on people

All in all, OpenOffice.org is a feature-packed, very stable office suite that is highly compatible with Microsoft Office and comes at an unbeatable price. And yet, OOo is a prime example for an advanced application that has been ported to the Macintosh without fully taking into account that platform's specific look-and-feel.

If you want to make sure that your application behaves just how the users of that platform expect it to, then you need to listen to people who are intimately familiar with that platform and who know the ins-and-outs of how software for that platform should look and feel.

Fine-tuning an application's UI this way is something that you cannot automate, and relying on a developer's library to do it for you won't suffice.