Skip navigation
kfarnham

Thick As A Brick Blog

Posted by kfarnham Nov 13, 2003

One of my grad school instructors, Dr. Muth, used to stress to us that we'd get more mileage out of synthesis, connecting ideas from different sources and combining them into new ideas, than cold analysis, taking a source and stripping it down to its essentials. In that spirit, I'd like to connect the dots between what java.net bloggers and other smart people have been saying recently about "thick clients".

Phillip Brittan recently blogged about Microsoft's thick client plans for Longhorn, its next major OS rev. Philip notes news coverage of Longhorn's thick client API's, which are meant to lure developers into writing more sophisticated clients that can provide a richer experience than what's possible in a browser... and of course, such clients will only run on Windows.

This is what Daniel Steinberg and I were talking about at the O'Reilly Mac OS X conference, when we left a session on thick/rich clients by Watson creator Dan Wood. As Daniel relates in his weblog, we talked about the possibility that web content developers would create single-platform rich clients and, as we've seen so often with desktop software, just do a Windows version and figure that's good enough for the majority of users.

So much for the openness and heterogeneity of the internet. If I have to pay a Microsoft tax to go online, forget it.

But there's a way out of this trap, and we're a part of it. In the slides from Dan's session - and this is from memory because only a Keynote version is available online (um, hello? print to pdf?) - there was a very surprising item at the end of his session. Thinking about how to distribute rich clients in the future, he wondered if Java Web Start might be the answer. I was surprised to see this because as far as I can tell, Watson is very much a native Mac application, and Java was never mentioned in any other part of his session.

But let's pick up this ball and run with it. Let's say we have a net application that's poorly suited for a traditional web client. We need to build a richer, more desktop-like client. A native application is an obvious choice, but then we have to have expertese in multiple platforms (or anger users of platforms we choose not to support), and we have to hand out an installer - absolutely unacceptable to some users, particularly in the enterprise. We could try single-window DHTML, which saves us the installer hassle, but pointless differences between browsers (thanks again, Microsoft) make this as bad an option as native apps.

So here's a wacky idea... how 'bout we do it in Java?With J2SE, we get:

  • A mature language with a huge talent pool available
  • A deep set of API's, particularly strong in networking and XML
  • Deployment via Java Web Start prevents us from having to hand out an installer, yet it practically becomes an application after repeated use.
    and most of all...
  • Write Once Run Anywhere. This is the point of Java after all, why not finally exploit it?!

In my session at the OSX conference, I argued there were no Java "killer apps" because seemingly nobody has applied Java to tasks to which it alone is the best solution, where WORA is critically important. I suggested there were two general fields where Java could make the most impact:

  • Off-network apps, since a web app obviously can't be considered for such tasks
  • Situations where the user experience requires a richness that can't be provided by the click-wait-read cycle of a web app, yet multi-platform support is desirable or even critical

In my session, I offered DVD extras - sometimes currently offered as a Windows-only goodie - as an example of the former. An ONJava blog I did a while back, "What If the iApps Had Been the jApps" was a hypothetical example of the latter. Interestingly, when I wrote it, I had no idea that someone had actually written jTunes 4, a remarkable Java mimicry of Apple's iTunes.

But it makes sense - this is an MP3-playing app that could be run on any OS that currently supports Java, and nicely, any future OS or device that supports Java. Analysts have expected for years that Sony wants the PlayStation 2 in your living room to become a "media hub" - if it supported Java, you'd immediately have a top-flight audio player without anyone having to write or port a new app to the PS2.

What's also interesting about the iTunes example is something that Amy Fowler wrote a while back in her weblog, Would you run in flipflops (actually I did once, trying to get on Star Tours at Disney World... caught the tip of my right sandal and nearly cartwheeled) She points out that the typical web interface is a miserable way to sell and manage music. And she's right. But iTunes is a more interesting hybrid than I think she realizes.

Here's the basic iTunes window. This is how you browse, arrange, and play music.

https://bloggers.dev.java.net/files/documents/84/1707/itunes.png

Obviously, we're in thick client territory - lists, tables with sortable columns, custom components, copy-and-paste, drag-and-drop, and nice fast responsiveness.

But the integrated music store is different. Find some music and click on an artist. You get a screen that looks like this:

https://bloggers.dev.java.net/files/documents/84/1706/supertramp-bio.png 

This is obviously HTML, supported by the Safari WebKit, and if it's not it might as well be - simple paragraph formatting, some images, links to each album, and a "buy" button for each album's form. Notice also the simplified browser-like navigator above - forward and back buttons, plus browsing hierarchy links for "Home -> Rock -> Supertramp"

So then, what do we make of this situation:

https://bloggers.dev.java.net/files/documents/84/1705/trash.png 

In this case, we see a merging of the two worlds - the album info is HTML, with links to the artist, top downloads by this artist and (if you scroll right), recommendations based on purchases of this album. But below that, we have a thick-client table, still sortable by title, artist, time, etc. And the "arrow" icons here act as links to albums or artists, reloading the HTML section above. Overall, iTunes is a very slick merging of the thin and thick client.

So getting back to the concerns about Longhorn and its thick client API's...

if writing thick web clients is such a good idea, why don't we do it today, in Java?

Longhorn's not coming out for two years. Java workstoday. Java Web Start works today. Swing workstoday (despite Joshy's complaints to the contrary). Sockets, RMI, JDBC, XML parsing, even auto-discovery with Jini are all available, for free, today. Simple HTML support is in Java today (maybe not enough to write a good browser with, but enough to do something like the music store).

Consider how Apple had to whip up a Windows version of iTunes to get their music store to Windows before they were eclipsed by competitors (analysts actually suggested that Napster releasing its music store a week before iTunes would kill iTunes... ha!). Had Apple written iTunes in Java in the first place - and jTunes proves they could - then they could have had a Windows version outthree years ago And it would run on Linux. And it might make users want Java on their PS2's.

Why wait two years for Microsoft to screw up the internet for everyone? Java is ready for the future today. Are you?

kfarnham

Toasting Java GUI's Blog

Posted by kfarnham Nov 4, 2003

My last weblog entry generated some good discussion about Java GUI builder tools and how they should work - how they could be made to save serialized objects instead of code, and how some apps already do this.

A couple of people made the point that new and better GUI tools won't necessarily result in better applications. jeremyzacker writes:

The problem with Java GUIs isn't the language, its the notion that any Java developer can write a GUI. Java makes it so darn easy to write GUI code that people who would normally have nothing to do with a GUIs think that they can write one.

He goes on to note that the real problem is with developers who don't understand threading and the Java AWT event-dispatch/repainting scheme, who block the GUI and create apps that appear slow or prone to freezes. Good point, and one that was directly addressed in a recent java.net article by Jonathan Simon. I ran in to similar problems a while back and blogged on ONJavaabout it.

In a way, this ties back to how I kicked off all of this with a mention of my session at the OS X conference, which in discussing Java's perceived slowness, asked the question "Java often used for enterprise / nework apps... does network latency look like a performance problem?"

Sure, you could save some time laying out your GUI with a visual tool... but is that really the hard part of developing Java GUI's? In the last couple of years, I've done complex GUI's, and yeah, I blow half a day on 500 lines of GridBagLayout code, but the parts that seemed challenging to me were some of the parts I did myself - multi-line list labels with icons and different fonts, a historical performance widget that rendered itself as a bar with colored segments representing performance over a certain time-slice, a JTree that supported drag-and-drop to its contents by tracking the drag event's (x,y) and repainting the node underneath based on whether it could accept the drop, etc.. A GUI builder isn't going to help with that, and I don't think those kind of tasks are any easier outside the Java world. Sometimes doing Neat Stuff requires getting your fingers dirty.

And maybe I've gotten off track from my original point. The Q&A for my session did get deeply into why we don't have an Interface Builder - like tool for Java, but one of the points of my presentation was that Java developers have turned out a disproportionate number of developer tools. We've got JBuilder, Eclipse, IntelliJ IDEA, Netbeans, BlueJ... and yet not one Java app that really matters to end users.

I keep having this troubling analogy in my mind, that Java is like one of those college degrees whose only practical application is to become a college professor in the topic.

If you haven't read the slides yet, this is "Why Mac Users Hate Java". They were promised that they'd get more apps out of the deal, because developers would stop writing Windows-only apps and start writing stuff in Java. Hasn't happened. Because those developers don't have pretty tools? I doubt it. I think the people who didn't care about non-Windows platforms in 1997 still don't care about non-Windows platforms and continue to write native apps (or worse, they write Java apps that only work on Windows). To a degree, many cross-platform apps that might have been written in Java have instead been developed as web applciations - MapQuest replaces the Rand McNally CD-ROM, TurboTax.com replaces the TurboTax CD-ROM, etc. And maybe these are done in J2EE, so we really are using Java.

But I digress. The point was, is it the lack of better GUI building tools that has held back Java on the desktop? I don't think so - I think the hard part of delivering a Java GUI has to do with things like threading and custom painting and delivering a polished, intuitive user experience... things that a GUI builder doesn't address. If an app is worth doing, then hard or not, developers will find a way to get it done. In fact, it's more typical that something cool is done the hard way first, to prove it can be done, then is made easier through a process of refinement.

To my mind, we're still struggling to come up with really good applications for Java applications... we'll work through the GUI stuff once we figure out problem domains where being cross-platform is critically important, where only a Java app will suffice. So I think we need to stop trying to please developers and start trying to please end-users.

Filter Blog

By date: