While WYSIWYG (What You See Is What You Get) and forms-based XML editing together compose a relatively new field, InfoPath is by no means the first kid on the block. Before delving into the details of InfoPath’s particular approach, let’s take a step back and examine some of the common design problems that engineers of related products face, and how they are often solved. Then we’ll be able to understand InfoPath’s design in a wider context.
Say you have an application that requires data to be gathered, stored, and presented. You also need to repurpose that data in different contexts, whether doing analysis on it or presenting it via different media. So you decide to use XML. Next you design an XML schema for your documents. So far, so good. Now you face a more difficult problem. How do you get your users to enter information in the format that you need? In other words, how do you get them to create XML? Well, you could try to teach them XML. While the thought of everyone in the world speaking our favorite language is a touching one, it’s also unrealistic. Your job isn’t quite done yet. You need to provide a user-friendly way for people to create XML without having to know or care that it’s XML they’re creating.
XML editing applications such as InfoPath represent just one way to solve this problem. Two other approaches to gathering XML include building a custom application and using a generic server-side framework.