An XML Framework for Coordinating Creative and Technical Design

Legend has it that the Tower of Babel was the world's second great engineering project (after Noah's ark)—and its first great engineering failure. Things went smoothly at first, as long as the architects, construction crews and project managers all spoke the same language. When that paradisical state ended, things literally fell apart.

Real-world projects are multi-cultural endeavors. Even when everyone speaks the same language, different factions bring different interests, priorities, strengths and weaknesses to the task at hand. Anticipating and accomodating this reality is one of the keys to project success.

In this article, I'll talk about the cultural dissonance often seen between developers, information architects, visual designers and other groups involved in Web projects. Then I'll describe the XML-based framework Respect Systems created to smooth handoffs between groups during production of Fleet Financial's 600-page Web site.

A Motley Crew

To build this site, Respect Systems provided technical project management to Fleet and its interactive agency. As is often the case, the agency's artists, multimedia designers and other creative professionals overwhelmingly preferred the Apple platform (Macs) to Windows PCs. More important from a project standpoint, this community insisted on using rich-media software tools to capture design concepts, preferring Adobe Illustrator and Acrobat to Visio or Word, Macromedia Dreamweaver to HomeSite, Flash to DHTML, and so on.

By contrast, the developers responsible for cross-platform front-end design were most comfortable on PCs and held nearly inverse software biases. A third community, that of information architects, focused on what might be called the "dramatic" artifacts of system design -- user personas, goals and use cases -- a craft poorly supported by software tools of any ilk. As a result, the information architects documented their design work using a grab bag of office applications, including Word (for narratives), Excel (for outlines), and Visio (for site diagrams).

As a strategist, I found this diversity challenging. On the one hand, the notion that each design community had an almost tribal affinity for a set of tools seemed inviolable from a productivity and morale standpoint. Yet the utter lack of interoperability between design tools meant that concepts were being stored in multiple, unsynchronized formats, obviously a productivity and quality nightmare. Short of enforcing top-down standards on the project teams, how could the design process be streamlined? One of the value propositions most cited for XML is the way it enables designers to separate content and structure from presentation. In terms of our design constituencies, it seemed fair to identify the information architecture (IA) with site structure and the visual design with presentation. Front-end developers were responsible for mediating between the two, populating templates with DHTML in confromance with both the style guide (a creative design document) and the site architecture. It turned out to be straightforward, even 12 months ago, to mimic this organization in code using XML, DTDs, XSLT and the DOM.

Decoupling Structure and Style

The first step was to recognize that the content, which in this case amounted to around 600 pages of Word documents, was well structured. This meant that it could be converted programatically to XML and validated against a Document Type Definition (DTD). Every document had a title, multiple paragraphs of body content, legal disclaimers and numerous optional elements which, importantly, always stood in well-defined relation to the mandatory elements. We created a rough DTD by inspecting a small number of documents, then refined it by exception during the conversion process. The final DTD was a formal representation of all the structures in our content.

This yielded a number of minor benefits, such as the ability to define copyright notices and legal disclaimers as "entity references" -- constants of the form ©right; and &legal1; which could be defined once for the whole site. While nice, this is hardly compelling; many non-XML sites accomplish the same thing using server-side includes.

A bigger benefit was the way the DTD enabled communication between project teams. For once, the art department received a formal and comprehensive listing of all the element types appearing in the site. Using this designers were able to create a mapping from each element type (for instance, the title tag) to a presentation style (such as "font-size: 18pt; color: navy"). In so doing, the designers, while remaining true to their aesthetic proclivities, fleshed out a style guide formal enough for front-end developers to use as a CSS specification. In effect, the developers created a CSS "binding" to the DTD based on the art department's design work.

While love was blooming between these former sparring partners, the information architects realized they, too, could use XML to capture site structure and navigation concepts. Again, there were minor and major benefits. An XML blueprint for site architecture can be validated against a DTD (or, in view of its more data-like character, an XML Schema), which preserves integrity under changes. For instance, the concept "Every page showing product info should have a list of links to upsell opportunities" can be blueprinted, enforcing it as a business rule. Very useful, but again, there are effective non-XML techniques for capturing business logic.

The real advantage to having an XML site blueprint is the ability, using Extensible Style Language Transforms (XSLT) and the CSS binding of the style guide, to programatically generate site prototypes. Using XSLT, the site architecture, instead of being buried in a set of Visio diagrams or Excel spreadsheets, can fluently be rendered into Web pages and submitted for usability testing.

We accomplished this in late 2000 using Microsoft's MSXML parser and server-side DOM implementation. (See the Wrox text "Professional ASP XML" for an overview of relevant techniques.) For DTD development and XML conversion, we used Altova's XML Spy [http://www.xmlspy.com].

The ability to generate Web pages programatically from XML design documents will strike some as the ultimate boon of the approach described here. That has great merit, but I reserve top billing for XML as a platform-neutral means of exchanging design information, enabling teams to focus on shared concerns rather than cultural differences.