Bad UI of the Week: The Cross-Platform User Interface
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Bad UI of the Week: The Cross-Platform User Interface
There are two kinds of snake oil in the software world that still seem to sell well. The first is DRM, where purveyors seem able to convince their customers that they can provide something that has been shown to be impossible. The other is that cross-platform graphical user interface.
Designing a good user interface is hard. Designing one that works well on multiple platforms is almost impossible. Unlike DRM, it is theoretically possible to build a good cross-platform GUI toolkit. The amount of effort required, however, makes it practically impossible—and probably not worth the effort.
The biggest myth in cross-platform GUI development is that getting the look right is the most important thing. A few years ago, Red Hat announced with great glee that it had created the BlueCurve theme that would unify GNOME and KDE desktops by making applications from both look the same.
Previously, the different appearance of KDE and GNOME applications would provide users with a visual clue that they should expect different behavior. With BlueCurve, this visual clue was removed.
Another culprit of this kind of behavior is Trolltech, whose Qt package on the Mac went to a great deal of effort to mimic the look of Aqua, but got trivial things wrong; for example, the shortcut key to skip forward or backward one word (Control+left/right in the Qt application I used, Option+left/right in every other Mac app).
Why is this important? Because as an end user, I am not even consciously aware of the shortcut key. When I type this article, I think a word with the front of my brain, and the back of my brain and spinal column translate this word into a sequence of key presses.
I recently discovered that I can’t spell a number of words that I type regularly when I try writing them with a pen (a handicap when trying to complete a crossword) because I don’t remember the sequence of letters. In fact, I remember the sequence of muscle actions to move my fingers to the correct keys. My mother had the same form of memory with a pen; when I was growing up, she would have to write down a word when I asked her the spelling.
This is commonly termed "motor memory" and is one of the most important concepts in the design of a good user interface. Using it enables users to delegate processing to their subconscious and dedicate their conscious awareness to the task at hand. If you’re thinking about the tool instead of the activity, you are unlikely to be as productive as possible.
Back to the text box. I know subconsciously that any application with an Aqua user interface should have a certain behavior when it comes to skipping words. If I use Windows, I know that any Windows application will use control, where the Mac uses option for skipping words. When I go to a *NIX desktop, I have no idea; I recently had three applications open, which all had different behaviors in this manner.
Why is this relevant to cross-platform GUI design? Because every platform has a set of behaviors that users expect. It’s not enough to take the menu bar off the window and put it at the top of the screen when you do a Mac port. The GIMP, for example, has two menus; one for the palette and one for the document. Which should go on the menu bar? How would you invoke the other? Would you merge them?
On OS X, applications interact with other components using the Services mechanism and AppleScript. On Windows, they use COM (or .NET these days). GNOME and KDE both have their own equivalents, too. How does your cross-platform GUI handle them?
Other behavioral differences are more subtle. On OS X, a document and application are treated as very separate entities. Now that Windows has ended its brief flirtation with MDI, they are regarded as the same. Each Windows document gets an instance of the application. When you close the document, you close the application, and vice versa.
On OS X, the converse is true. Applications exist independently of documents; an application can be running with no documents—or even windows. Ported applications often lose this behavior and exit when you close the last document. This is a problem for users because closing one document and then going to the menu to open a new one is a common sequence of actions on MacOS.
Most cross-platform GUI toolkits encourage users to use a single GUI on all platforms. If you’re lucky, it will look and feel good on one platform and bad on all the rest. If you’re not, it will simply be bad on all of them.
The only way to write good cross-platform software is to make sure that you have a good set of clean interfaces between your application logic and your user interface, and write a new UI for each platform you support. A cross-platform toolkit can help here because it will make it easier to reuse custom views and components that are would work on multiple platforms. More often than not, however, it will be a hindrance because the abstraction it provides will make integrating with native operating system services much harder.