When you design an application to be cross-platform, or if you have decided to take an existing application to other platforms, your first step should be to translate that application to the new platform. In moving from a desktop application to a mobile one, the changes are quite radical and somewhat obvious. Moving from the desktop to the web, while tricky, is still understood as a big change so people tackle the problem accordingly, (generally) paying attention to details. Moving from one desktop platform to another is, unfortunately, a place where many mistakes are made, because sometimes software-makers forget that platforms are different.

Sure, it sounds quite obvious that they are, if you think about it. After all, you have to make some changes to the code to get things working, package differently, market it, have a support model etcetera. Why is it, then, that some of these applications fail so miserably to integrate with the operating system, while others get most of the things right, though not everything?

Developers forget that platform distinctions do not stop at the code; the most obvious differences for customers/consumers are in the UI.

Java applications are the first culprit and probably the most oft-found. While the UI integration is mostly there¹, subtleties in interaction paradigms are often wrong and follow just one of the platforms’ principles, if even that (sometimes developers take liberties with pop-up dialogs, menus etcetera). The result is a piece of software that feels out-of-place on some platforms, only just “fitting-in”. By extension, most applications written in interpreted languages are prone to falling into that trap because of the “write once, run everywhere” concept.

The subtleties I speak of can be found in OK/Cancel dialogs, the organization of items in menus, button layout and even typography. Any one of these things by itself does not sound like much, but screw a few of them up and you have a different story. It all boils down to the misconception that, after the code is ported, your job as far as cross-platform work goes is done. I have been part of projects where the lead architects believed just that, and no amount of complaining could convince them to task someone with studying the target platform’s UI paradigms and then refine the application accordingly.

With the code working, you are still far from done. Look at your application on the new platform and open up something that critics recongise as a good example insofar as UI and interaction/usability goes. And start tweaking. Think not in terms of a cross-platform application, or rather do not imagine the different platform implementations to be twins, because at least one of them will be restrained from achieving its full potential if you do. Try to look at your application the way your users do, without knowledge of or care for its cross-platform nature. For them, it is a piece of software running on their machine. So their machine, with its UI paradigms that they are accustomed to and the interaction expectations that they have learnt, is the one in control, not you. You change code so that the new platform understands it — why stop short of changing the user interface so that your new users do, too?

1. Apple controls the distribution of the Java runtime on the Mac, so they also integrate the graphical widgets properly [↩]