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.
Sarah….
Thanks for the note, which TrackBacked to my site so I could find it!
Your explanation of why XML may have a valid role to play in GUI design is intriguing. I agree with it. Your final point is the core of my issue, I think. I’m looking now at building a first cut at a Laszlo GUI tool using Runtime Revolution. I’ll let you know if something useful develops from that work.
Note: most of what you build in a GUI is not actually pixel-tweaking. After spending the last year working on Laszlo Mail (www.laszlomail.com), I believe this even more strongly. A GUI tool is great for prototyping, but building a real UI that does anything interesting or innovative, is still a programming task. After three years of LZX coding experience, I’m convinced that declarative coding is just plain faster than creating procedural code. XML is reasonable choice for declarative code today.