Summary
... wherein we ponder on whether reality is best reflected by realism ...

It has been long known that the unreal can be better at expressing reality than true realism. For example, photographs are harder to recognize than a good sketch.

Currently I'm playing around with something designed to play with this notion. As Joel Spolsky discusses -- and many of us have painfully experienced -- showing people a mockup of your application that looks real when it isn't has an unfortunate consequence that people remember it as real. So after a few weeks your manager will start wondering, having seen the mockup, what kind of patsy you are playing them for. After all, you were done weeks ago! They saw it! Intellectually they know better, but emotionally they are completely off base. And we all know that in the contest between reason and emotions who wins.

One way to look at this is that the problem is with the manager. If we could only get a better class of manager this wouldn't be a problem. Possibly so, but even if true this is like saying that with a better class of people we wouldn't have to endure swill like "Survivor", "Garfield", or (God(ess)((e)s) help us all) Britney Spears screwing up her tattoos. In other words, nice universe if you can find it, but the rest of us have to live on this planet.

So, as Joel suggests, to solve this kind of problem you must change the presentation to make the provisional stuff look, well, provisional. Your typical mockup uses standard GUI widgets and so looks just as done as if you'd spent the last three weeks polishing the bevels.

Java can have plugable "look and feel" modules. They're mostly used to produce widgets that look like the local platform. There is a standard Java L&F if you want everything to be the same no matter the platform. And just in case you want to play around, there are several variants of this form.

Excuse me while I yawn. I mean, there are some problems with every platform's look and feel, but variations on the theme are fun for people who like to play with all the levers available, but don't do much new.

But now we have a real use for the idea: Make a provisional-looking look and feel that can be used for the provisional parts of your project. Then the emotional reaction to the visual presentation will match reality: This project is unfinished.

I've gotten moderately far on this. I call the napkin look and feel -- it's designed to look like it's been scrawled on a napkin. You can find it at sourceforge. It's in alpha, but you can easily get the idea. There are some screen snapshots there, and a webstart demo based on the SwingSet2 demo.

I'll be blogging on my java.net blog for small updates, now that I have something to show. As usual, my longer, thinkier pieces will be here.

One thing that is clear is that the plugable look and feel infrastructure is a really hard design problem. There are just too many degrees of freedom someone might want, and too few tools to attack it. For example the Basic LAF (the normal starting point for custom LAFs) has a supertype shared by all toggle button types: BasicToggleButtonUI is the superclass for BasicCheckBoxUI and BasicRadioButtonUI. This sounds nice, but what about me? I want to change the behavior of toggle buttons, but I cannot subclass BasicToggleButtonUI and thereby modify the behavior of BasicRadioButtonUI. I need to instead subclass the two leaf classes (radio button and check box) and use some other means (probably delegation) to share implementation between them. It's a pain.

Another is that there is just a limit to the expected variation, and it is built into the infrastructure. There is a background color. Well, I don't want a background color -- I want a background image. Sorry, nothing there. The color gets in the way. (I have actually set the background color for almost everything to "transparent" and overridden the update() method to draw in the background image, but it's pretty ugly overall.)

What we have here really is a very big, complex infrastructure that is used by very few people for very few projects, and so is not really completely factored out properly. There just isn't the time for it. All the cool patterns and factoring in the world will not make something nice without time to spend making it work smoothly.

Anyway, for me the main thing is to see how folks react to this. It's an interesting idea, I think, and a few people have tried to use it. If you have a shot at playing with it, I'd like to know what you think.

Talk Back!

Have an opinion? Readers have already posted 10 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Ken Arnold adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Ken Arnold is a recognized loose cannon in the software business, whose previous fusilades include being an inventor of Jini, designing JavaSpaces, writing books on Java and distributed systems, helping design CORBA 1.0, and (while at Berkeley on the BSD project) the curses library package, co-authoring rogue, and generally enjoying himself. His interests include designing APIs and programming languages using general principles of human factors design because of his radical hypothesis that programmers are human, and other applications of this same principle to software design, management, and production.