Jump to content

XML: The halfway point between design and programming

  macslocum's Photo
Posted Oct 18 2010 05:35 AM

The luxury of being just a designer or just a programmer is largely a relic days long gone. It's now common for designers to tab out of the Adobe suite and pop the hood on code, and programmers need at least a rudimentary understanding of user interaction and interface.

Bob Boiko, instructor for O'Reilly's free live course "Website Architecture and Design with XML," knows the terrain between design and programming well. In the following interview, Boiko discusses:

  • The blurred line between information design skill sets.
  • The products and forms that benefit from XML's output-neutral structure.
  • How designers, content creators, coders, and programmers can find success by converging around information.

How does an an XML-based architecture differ from traditional website architectures?

Bob Boiko: There are really two types of traditional website architectures. The first and simpler is a static site. In this sort of site there are only prebuilt HTML pages. The web server finds and sends the page the user's URL points to. You can use an XML system to create these static HTML files.

The second type is a dynamic site, where the URL the server receives points to a program that knows how to build the appropriate page from data sources on the server and templates that create the look and layout of the page. An XML file can be a data source in dynamic sites, and it can provide the templates to create page look and layout.

Many sites are combinations of the two types, and many dynamic sites have more than one source of data and templates. I like to think that rather than replace a traditional architecture, XML fits into that architecture. It can serve as one of many options for building pages, providing data, and providing templates.

Does XML force designers and programmers out of their comfort zones?

BB: Interestingly, XML is half-way between design and programming.

Designers using HTML can add code that makes the page look the way they want it to. But if they use XML, they're pulled into the structure of the information behind the interface.

As designers move deeper into XML, they're challenged to create a "logic of presentation" that systematizes and standardizes the way pages come together. That's a big step for visually-based designers to take, but it is a necessary step if they are to apply their skills to bigger and more complex systems; especially those that use management systems to build sites.

Programmers using XML must think differently about data. XML allows for a much "looser" data structure than programmers are used to. This looser structure is just the sort of structure you need to represent narratives and other complex content that we want to show on websites.

Programmers are sometimes deceived by the often repeated idea that information in a relational database is structured, but information in a word processing document or web page is unstructured. This is a mistake. While subtle and variable, the structure of the document or web page is just as real and just as important. But it is not the sort of row/column structure that programmers may be used to. It is more the hierarchical structure that modern programming languages have come to depend on.

What is an "information type"? How does that apply to XML?

BB: An information type is simply a kind of information: like a movie review, a newspaper article, or a product profile. But beneath this simplicity is a huge concept and a lot of work.

The concept is "divide and conquer." If you want to effectively manage a lot of information, you have to divide it into a set of types. Consider the difference between saying "my website has 100,000 pages" and "I have 10 types of information each with 10,000 items of that type." In the first case, you have said "I have 100,000 things to manage." Each page is a separate issue to deal with. In the second case, you have said "I have 10 things to manage." There may be 10,000 items of each type, but you manage the types, not the items. You create a single origination, tagging, organization, and presentation process for all 10,000 items of a type. This reduces the complexity of your job enormously.

There is no free lunch, however. It is easy to say I have 10 types, but it is difficult to wrestle 100,000 items into 10 standard forms. It's also difficult to get companies and organizations to adopt the standardized creation, storage, and distribution processes you envision.

As for the relation to XML, info types have nothing particular to do with it. XML is one way among others for making this important concept real.

What tools do you need to create XML architectures?

BB: Technically, all you need is a text editor. In reality, an XML integrated design environment (IDE) will help you develop the system. If you plan to use XML in a dynamic site, you will also need a code library that allows you to open, manipulate and transform XML.

If you build an XML-based architecture, what products and outputs can you port your content into?

XML stores information in an output-neutral way. You then create outputs as you need them from some combination of the information stored in XML and the tagging that the output requires.

For example, you can combine the information stored in XML with HTML tags to create a web page. A lot of work has also gone into allowing you to create PDF outputs by combining the information stored in XML with PDF tags, which are much more complex than HTML tags. Another output target is "other XML," such as an RSS feed. To create an RSS feed from your XML, you would transform your XML tags to the RSS tags.

Many systems can accept input that uses specific XML tags (OpenOffice and Microsoft Office are good examples). Any of these are a potential target for the XML you store.

Finally, any type of output that has a text representation is a viable target for XML. The older .RTF and .CSV formats are examples.

Are the lines between designers, content creators / coders, and programmers blurring?

BB: The lines blurred a long time ago. It's been more than 20 years since I sat in my first software development team meeting with artists, writers, programmers, and managers all trying to figure out how to talk with each other. They continue to struggle today.

The language of business value and information structure is a great candidate for the common tongue we're looking for. Everyone on a team should be able to say why they are doing this project and what part they play. That's business value.

More specifically, in the center of a project you'll find the information that the project collects, stores and delivers. Designers need to understand the structure of that information in order to present it. Content creators need to understand it to originate or edit it. Programmers need to understand it to build the machinery that moves it from place to place.

The lines that need to blur are not at the center of the design, coder, or programming disciplines, but rather where they meet. And where they meet is in the information.

This interview was edited and condensed.

You can get a taste of Boiko's free live course, "Website Architecture and Design with XML," in the following video. Details on the full course are available here.


Website Architecture and Design with XML

Learn more about this topic from Website Architecture and Design with XML.

Take your web design skills to the next level with XML, and learn how to use the content behind the site to drive the information, navigation, and design of a full-featured website. In this 10-session video course, you’ll build a professional website from the ground up by focusing on back-end structure and information to create brilliant front-end design and functionality. You’ll learn how to architect your content once for use in multiple formats and venues: the Web, desktop, mobile devices, and PDF.

See what you'll learn

1 Subscribe

0 Replies