Chris Adamson's Blog

Swing Archives

The urge to svn merge

Joshy and I have just sent the final copy for Swing Hacks to the editor, along with over 200 screenshots to the production department (yeah, they're going to love us). After a reasonable but non-trivial amount of time, it'll be available at your favorite bookstore or online bookshelf.

This was my second book (the first is about QuickTime for Java), and my first with a co-author. Important lessons learned from both experiences:

• Subversion rocks -Granted, Joshy covered this earlier. For sharing and revisioning code, it's truly awesome. We used subversion both for the code examples and for the book contents (the write-ups and screenshots). This was an easy way to share and manage stuff between the two of us, far more practical than e-mail could ever have been (imagine juggling source, images, write-ups, etc. for each of 100 hacks). When two contributors (hi Jonathan; hi Romain) came on the project part-way through, it was easy to get them caught up by having them do a svn checkout. In fact, when I dropped into VirtualPC to test my hacks on Windows and make any adjustments, I would just use a separately checked-out repository there, committing back any changes coded on that side. The only thing I can truly say I dislike about subversion is that setting a property to ignore class files is nowhere near as easy or as memorable as just doing cvs ignore *.class
• I should have made an ant build file sooner - On the QTJ book, I set up an ant build file early in the process, and every example in the book can be compiled and run with a single ant call like ant run-ch03-undoableqteditor. It's a hassle up front, but it pays off. We didn't do that work up front on Swing Hacks, so I have to go back and do it now so the downloadable code will be ready for everyone to use when the book's ready.
• Find just the right amount of experimentation to do, and budget accordingly - Generally, inventors of a technology don't write the defining book on it, though there are exceptions (such as O'Reilly's perl, Ruby, and Subversion books). So, the author usually has some amount of learning to do in the writing process, and even a little experimentation. You want to get some things in that nobody's done before (or at least nobody's posted in a place where Google can find it). Thing is, if your whole book is like this, it will take 10 years to write. And if you never do this, the book can have a "nothing new" feel to it. So on Swing Hacks, Joshy and I did put some stuff in the proposal where we said "we haven't done this before, but we really think it's doable". And those were good to figure out and get in there. But they can't all be like that.
• Read your co-authors work early - Joshy and I have different code-quoting styles, and we only realized late in the game that they looked strange when they were in the same chapter. I ended up changing a lot of my long listings to a more broken-into-pieces style to match. By the way, do people still type in programs from books by hand? We've really tried hard to make sure this is still possible, though it is obviously far preferable to download a book's code from its supporting website.

Hopefully, you'll like the book. We learned a lot from each other and from our contributors as we were writing it.

As Your Users Like It

'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.

This work is licensed under a Creative Commons License.