Summary
... wherein we ponder on whether reality is best reflected by realism ...
Advertisement
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.
> One thing that is clear is that the plugable look and feel > infrastructure is a <em>really</em> hard design problem. > There are just too many degrees of freedom someone might > t 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.
This is one area where I've found aspect-oriented programming to come in very handy. It allows you to intercept behavior and replace it with your own. Using aspects, you should be able to provide C++ mixin style behavior by introducing a shared Interface for both leaf classes and specialized Interfaces when the behavior diverges.
I concur with Chris. This is an excellent idea. It takes into account the very real factor of psychology in these things.
Along the same lines, I wonder if there would also be any merit in making the controls behave less than perfectly, as well. That is, a little randomization that makes the dropdown occassionally choose the wrong item, or makes something look funky, etc.
By the way, what tools do you use for GUI development in Java?
Clever. Perhaps too clever, but that doesn't mean I might night give it a try the next time I have to do a swing UI...
One simple tip for web-baseed development:
Do the UI slick and functional, yes, including those beveled CSS buttons and six-state rollovers, but in strict grayscale with the most boring (but clean, elegant, blah blah blah) fonts around. And show it on Firefox (or other decent browser) with the fonts properly scaled, anti-aliased, etc.
This gives you the best of both world: nobody will mistake it for "done" (obviously, the artists haven't had at it) and yet it looks super slick and professional.
It fits in nicely with the technique of beefing up unfinished functionality with temporary-sounding text. I also recommend a healthy dose of Lorem ipsum (http://www.lipsum.com/), both temporary UI features and filling out the copy so it doesn't look so empty.
My wife is a (building) architect. Like most architects, during the design phase she creates most plans and elevations directly in a CAD program. But when presenting those plans and elevations to clients, she often has to print them out and trace and color them by hand, with intentionally "sketch-like" lines.
Apparently the cold, crisp precision of computer-plotted lines makes clients feel like the lines are permanent, while ironically, the laboriously hand-drawn stuff somehow feels more mutable to them. Go figure.
It's very cool. I like it. The only downside I see is that I suspect that I could actually get used to using it. At that point, we're back to the perception of done-ness again. I think it'll work as long as no one releases a product that way :) If anyone tries it, it will be developers of IM clients and P2P tools.
This is a very interesting idea. Still, the fact that it actually runs, even tho it looks primitive, may lead a sufficiently clever manager to conclude that it works (other than the UI details which said manager might conclude were minor details anyway). The "clever manager" class is probably larger than the class of managers who believe PowerPoint slides can be automatically translated into a running application.
I don't think Ken or Joel were implying that this was intended to fool stupid managers. I think the idea is that even intelligent people can be very much influenced by visual impressions. I have noted in my own work that people are much more wowed by simple but nifty looking improvements to the UI (some of which is accomplished just by adding nicely rendered graphics to a window without changing how it works or what it does) then they are by significant improvements in the underlying technology that are not as visible. It isn't because they aren't clever, either. I think it is simply a bit of psychology to which we are all susceptible.
Sorry, I was half trying to be funny and half trying to make a point. Maybe I did neither. Anyway, I do appreciate the psychological aspect of this and I think a very interesting study could be performed (and I hope we see one). It could have a significant impact on how people communicate through software.
I'm in this situation right now where development has created an Alpha and our marketing team is showing it off at a conference. Development has re-re-re-iterated the actual state of the software. In light of this idea Joel and Ken discuss, I'm eager to see what happens.
Previous Topic
