“It is the essence of play that a new relation is created between the field of meaning and the visual field — that is, between situations in thought and real situations.” — Vygotsky Mind in Society

“most of us are so busy trying to solve problems that we fail to notice that in solving problems we sometimes rob ourselves of the opportunity to learn something new.” Michael Hamman offers an interesting equation:

Creativity = competence + a desire to create a problem.

I agree that creativity requires competence, or at least confidence. I have observed in the development of software that I experience two extremes. One is where writing software is work. I relentlessly chase a bug. I perfect a piece of code through sheer persistence and fortitude. It can be satisfying, but it is not fun. The other extreme is where writing software is play. I can’t imagine that someone pays me for such challenging entertainment. Experimentation yields unexpected solutions. The patterns revealed by the trail of a bug lead to insights. Crafting a solution is a tangible, creative experience.

I often wonder what key factors create the experience of play. When I capture that way of working, I am undeniably more productive. I can see no down side to taking that approach all of the time, except that its not a state consciously achieved. One could argue that some things are just no fun. However, I don’t believe that the level of play is inherent to the task.

Dan Shafer asks a very good question about Laszlo:

“Instead of direct manipulation of graphical objects to create pleasing interfaces, i get to write XML code (with its extreme overhead burden) to describe how I want the graphical experience to look and feel. And that’s a good thing because…???”

I agree that it is counter-intuitive that XML would be a good format for developing graphical user interfaces. I always felt that XML made a mighty fine interchange format — it’s human-readable, almost self-doumenting, and these days if you are working on a large software development project you probably have at least one or two XML parsers already linked in. So… why use it for developing applications?

There are a few attributes of graphical user interfaces that map well to XML:

Graphical user interfaces are inherently hierarchical
Screen real-estate is naturally divided heirarchically. It is convenient for that heirarchy to be represented by the development environment.

Graphical user interfaces evolve
While a hierarchy could be effectively represented in a visual tool, arguably more effectively than it is in an XML file, it is the managing the evolution of a application where XML really comes in handy. It is natural for a design to change over time. In response to user feedback, bugs, or simply by realization of the author, an application needs new features, gestures, or an altered composition. When your design is caught in a visual tool with an opaque file format, you lose the magic of a diff. What happened between then and now?

Graphical user interfaces are often built by a team
XML files are simple text files. Media files live separately and can be linked in by name. Designers and coders can work together on separate pieces of an application without the need for complex group-ware solutions. Coders use the tools they are used to for editing and archiving files. Designers can use the tools they are used to for creating and editing art assets and media files.

Graphical user interfaces require structure
Graphical user interfaces need to be split into pieces to be manageable. XML provides a structured framework which makes its fairly easy to divide your work into bite-sized chunks. A common problem in a visual tool is that people “lose” things. It may be hard to figure out what object a script is attached to. An object that is invisible can be hard to discover or manipulate. In a system where all objects and code are encapsulated in simple text files, anything can be found. The inherent structure of an XML file helps organize an application. There are lots of visual tools that offer a tree-view of XML files which make this structure more approachable.

As an aside, for Dan who “still doesn’t get Laszlo,” there’s a whole lot more to Laszlo than XML. What makes Laszlo cool is its constraints system, animation geared to UI design, client-server data model, effective class re-factoring, and more.

Someday there’ll be a GUI tool for creating and editing Laszlo applications. Let’s face it: typing in pixel coordinates and RGB values is no fun. Ideally there would be a layout tool that directly created and edited LZX files. Most folks at Laszlo design in Illustrator or whatever and transfer pixel and RGB values to the XML files. By the way, this is often what folks do when building UI for desktop apps.

For the Laszlo developers amongst my readers…

I wrote a little interactive debugging tool that I have found very useful in my own app development. It lets you inspect the view hierachy and see and modify key properties (bgcolor, position, size, visible).

You can try it here. You can change bgcolor and view position. Click on the x/o to toggle visibility. Click on ‘…’ will send the instance to the debugger, where you can click on it for further inspection.

You can download a zip of the source from the mylaszlo forum.