One of XML's design goals is to separate content from presentation. XML focuses on the content rather than the way the content is presented to a user. In this week's column, I look at what this aspect of XML means to a forms designer.
In the not-too-distant past, in any business office or government agency, you could find hundreds, sometimes thousands, of paper forms. Whether the forms were fancy or plain, a forms designer—perhaps a graphic artist, perhaps an office clerk—had a hand in their design.
As organizations began to automate, the data collected with the forms has gradually moved from filing cabinets into computer databases. But the forms themselves often haven't changed. Even if the organization has eliminated a form's paper version, the replacement is usually an electronic version that resembles the original paper form. And where does that leave a forms designer?
HTML is somewhat friendly to the forms designer because of the number of good WYSIWYG editors that let the designer easily replicate a form's appearance or design new forms. Granted, the designer is isolated from the data, but with a tool like Visual InterDev, a well-trained designer can control the look and feel and the table structure.
With XML, the forms designer's role is dramatically diminished. The forms designer is even more isolated from the data. Complexity is partly the cause: Between the designer and the data stand so many more technologies, such as schema, Document Type Definitions (DTDs), Cascading Style Sheets (CSS), and Extensible Style Language Transformations (XSLT). But part of the diminished role is that the emphasis of XML tool development is on the back-end technologies, not on the technologies that a forms designer can use. In fact, the form is an afterthought with XML. Typically, the data structure is modified, then work proceeds from back to front.
Forms designers need an XML equivalent of Visual InterDev. Perhaps Visual Studio .NET will ultimately fill that bill. Even better would be a tool that would let the forms designer design and/or modify a form, and then the tool would generate the database schema. This approach would let design work from front to back instead of the other way around.
As an example of how my approach might work, assume we have an electronic form that collects customer information. It's a well-designed form that's easy for customers to fill out. The form also includes the company's branding. The data from the form is stored in a SQL table called customer. The table has fields such as name, address, and date of birth (DOB). Suddenly, we need to collect some additional data. Which happens first—the changes on the back end or the changes to the form design?
With the tool I have in mind, the forms designer could make the form changes using a WYSIWYG editor, adding the new fields, arranging them, and specifying their font and color. When the design is complete, the tool (or a related set of utilities) could create the necessary intermediate products, such as the DTD, and add the new fields to the customer table. Such a tool would be particularly useful for simple changes to Web forms and would improve forms designers' ability to perform their jobs.
Ah, for such a tool.
