Month: October 2005

Playing with Konfabulator

There is one area in which the Internet has had an effect perhaps more pronounced than all its other ramifications: software names. From Skype, to Ubuntu, to Greasemonkey, the young developers who currently stand astride computing technology’s leading edge seem to favor the off-the-wall, the punnish, and the pleasingly ethnic. Just which of those categories Konfabulator falls into, I couldn’t say if my life depended on it. That hasn’t kept me from having a lot of fun with it, though.

The best way I can describe Konfabulator is this: it is a shell that runs Javascript, provides a framework of common services that extend the language, and allows scripts to easily do things like display images, read files, connect to COM objects, etc. Konfabulator loads the scripts and runs them. The scripts themselves provide the user interface and the functionality. Konfabulator also parses XML entities and instantiates them as objects, so that the script can access and manipulate their properties. This is how user interface elements are created, among other things. Konfabulator’s creators decided that these bundles of XML and script should be called widgets, and widgets they are. Currently I have six running on my desktop.

Konfabulator started on the Mac, and is hugely popular on that platform. The Mac has always been notable for the slickness of its interface, and the widgets that are available for Konfabulator flaunt that ancestry with striking design, soft colors, transparency, and reflective effects. In other words: they’re pretty. They are also useful. I have one that runs Winamp, another that displays an elegant analog clock, and a third that monitors CPU and memory load. None of them are essential, but they are cool.

No good idea remains unmolested, of course, and Konfabulator now has plenty of competition. Skinning the Frog at Joeuser.com has a nice article comparing some of the different platforms. In addition to Konfabulator and Samurize, probably the two most popular, there is DesktopX, and Object Dock, and now Microsoft and Apple are both adding widgets, or gadgets, or whatever the marketing types decide to call them, to their own shells. Recently, Yahoo purchased Konfabulator, and it may be that, as with browsers, the independent guys will be out of this market in a few years. That would be a shame, but the creators of Konfabulator will always be a part of the history of the applet paradigm.

Konfabulator is very easy to use. You can download the latest version, 2.1.1, here. Once it is installed you will find a folder of widgets that come packaged with the apps. Just open the folder and double-click on a .widget file, and you’re in business. Once you fool around a bit you can visit the Konfabulator Widget Gallery and grab a few more. Most are small, and download in seconds. Once you have a few running on your desktop, hit the F8 key, and experience one of the application’s neatest features: Konspose mode. In Konspose mode all the normal Windows XP desktop elements receed behind a grey fog, and all the widgets pop up to the front. Very slick.

If you would like to write widgets you’ll need a text editor and a paint program in which to create graphics, and of course some knowledge of Javascript and XML will be helpful too. If you don’t have that, then Konfabulator is not a bad environment to learn it in. The reference .PDF docs make the process and syntax pretty clear, and in a lot of ways working with widgets reminds me of programming in BASIC circa 1980: you make a change and run the program and see the results immediately. The whole environment in which the app runs is very simple and makes it a pleasure to explore new capabilities. So now that you know about Konfabulator, you have something better to do than read this website. Go accessorize!

Dvorak on Rinky-dink Software

You gotta love John Dvorak, even if you hate him sometimes. I’ve been catching his stuff for years, first in Byte, then PC Mag, and now PC Mag online. Sometimes I agree with him, often I don’t. But in his rant in yesterday’s column I think he got it pretty much right. Photo editing software, of which category Adobe’s Photoshop is the reigning monarch, is a good example of the difficulty inherent in simplifying complex tasks. Some amount of complexity is irreducible, but if you have used image or video editing tools, software development environments, word processors (who hasn’t?), etc., then you know how frustrating it can be to attempt some task you know you have completed successfully in the past, only to find that you can’t remember the navigation path to get to the goal.

I have long felt that the concept of layers is important, and might lead us to a general paradigm of mastering complex interfaces. This is where a good understanding of what an abstraction is comes in handy. Think of all the complexity of any given subject at it’s lowest level of detail: all the individual parts in a car by name, for example. This is equivalent to the thousands of individual commands in a complex software application. There is too much detail to remember, so we classify things and group them into named abstractions like “drive train,” and “cooling system,” and “editing functions.” When we confront such complexity the creation of appropriate abstractions is almost second nature: it’s hardwired into our heads. But deciding how to organize those abstractions in terms of how they relate to one and other is more difficult, and not everyone is good at it, or has enough time to think about it when designing an application. The simplest place to go, since we have been doing it for so long, is to hierarchy. And for many simple applications hierarchical orderings of interface elements work fine. We don’t have any problem finding “Edit->Search->Find and Replace” in a text editor.

But when you look at complex applications that require batches of multiple commands to achieve an effect, such as “Put a reflective glass pane in the empty frame in this picture,” the hierarchical approach breaks down. This is because achieving the goal requires more than a simple drill-down through the layers to an end-point command, and then a click. To achieve this goal requires picking effects and commands from various points in the hierarchy and stringing them together. In essence this is another layer of relationships between functions, orthogonal to the tree structure of the command interface. It’s a layer in which relationships are goal-based rather than class-based.

Wizards were one early attempt to provide an alternative navigation path through a featureset, but wizards are not flexible enough: the goals are not mutable. There have been many different attempts to address this issue, from allowing the user to create custom wizards to using “sideband” interfaces that collect groups of commands together under meaningful names.

There is probably no more challenging or critical area of focus in the world of software development. We have made tremendous strides in terms of how we specify, engineer, test, and deploy software, but we have come almost no distance at all in the interface. Complexity has overwhelmed utility in many application domains, and the fact that we have been hearing this same complaint for twenty years says a lot about the situation. A new interface paradigm is required, but in my opinion there is nothing on the horizon that promises to be revolutionary.