Posted by editor
on February 13, 2004 at 3:28 AM PST
Should Java applications look like native apps or should they advertise themselves as Java?
'Tis true; for those that she makes fair she scarce
makes honest, and those that she makes honest she
makes very ill-favouredly
-As You Like It, Act I, Scene ii
As much as I hear people talking about "a renewed interest in Java on the desktop", I hear just as many differences in basic assumptions about what we want or expect from these applications. Conversations with other authors and webloggers, and some articles I've edited recently, have me thinking more about a basic question of how an app should present itself to the user.
The problem is a paradox. We want Java to succeed. We want to deliver great apps to users with Java. But here's where there's a split. We have one camp that believes it's best to completely obscure the fact that an application is written in Java, and make it as close to a native experience as possible. The positive reaction to Joshua Marinacci's series "Make Your Swing App Go Native", parts 1 , 2 , and 3 indicate there is a great interest in this approach.
But is that bad for Java? If users don't know that an app is written in Java, does the platform fail to get some end-user respect, support, and admiration that it would otherwise get? This is where a second mind-set comes in: the idea that an application should be very clear about the fact that it's a Java app. Successful applications that implant the coffee-cup and Duke icons into the public's consciousness are good for the platform under this theory, since it will prompt users to choose Java-enabled technologies whenever possible (you may be able to argue that this is happening in the phone space right now... they're certainly trying). In the ideal world, users would take their application from device to device (see my alternate reality vision of this ), and in such a case we'd want to give them a consistent experience on all these platforms, hence we would do our apps in Swing's "metal" look and feel and adhere to Sun's look-and-feel guidelines, even if they clash with those of the underlying native platform.
This is the paradox: if we do a great job of concealing the Java-ness of an application, then we don't really advance the platform (if that's even an important goal... should it be?). But it's a blunt reality that in the here and now, there are users who absolutely will not use a cross-platform look-and-feel application. Heck, I haven't worked anywhere where the management thought the Windows L&F was Windows-y enough (and I'm like, "what, our app is ugly and confusing... how much more like Windows do you want?"). Don't get me started on the Mac zealots. And as much as the multi-device argument makes sense in theory, in practice there are only three J2SE environments that matter (Windows, Linux, and Mac OS X), and it's a rare user that uses more than one.
There's an analogy to the web app experience. Working through a web page isn't particularly Mac-like, or Windows-like, or Linux-like. It's a specific user experience, in large part dictated by the limitations of working in a browser. J2SE is so much richer, it may not be able to define a user-experience in this way because the sense of how it's different from native apps isn't so different as to make users adopt a different mind-set. Worse, being just slightly different from the underlying platform's native apps may make users focus on the 10% of the experience that's different or less pleasing, and not on the 90% that's the same. On the other hand, it may be that web apps have delivered so much functionality that users tolerate the less-rich experience, whereas few useful Java desktop programs have made their way to end-users. Maybe users would embrace metal-themed apps if only there were any that did anything essential.