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
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
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
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.