The dichotomous identity of the InfoPath end-user

InfoPath is a truly interesting product. I have to be honest and say that prior to October of last year, I knew little about it. I had installed it but never used it (if you are an Office executive an reading this, please know that I was busy writing killer demo's for WordML instead :)). While working a booth at PDC for Office development, I was barraged with questions about InfoPath (and smart documents, research and reference libraries, WordML, and more). I was prepared for pretty much anything but InfoPath, and there were InfoPath specialists there to handle the product-specific questions. Nevertheless, I started demo'ing the product, hooking it up to SQL Server databases, Web services, creating cool forms, and exploring the XML. I am not afraid to say that I was pretty much learning while doing. But, the product is pretty straight-forward.

One of things that is striking about this program is that the end-user story is bivalent. For example, InfoPath has menus and dialogs and so forth, but they are mostly for the person who develops the InfoPath forms. Then, there is the end-user of the forms that the forms developer creates. Thus, there are two kinds of end-users involved. This similar to FrontPage and less like Word, Excel, PowerPoint, Visio or other members of the Office family. Even though one could legitimately argue that Word templates are to Word what forms are to InfoPath, I believe there is a difference.(disagree?) How we draw that line of distinction can have a big impact on how we treat these programs, how we create help for the end-user, and how we extend them. What other impacts does this kind of relationship have on a product and its reception is something I want to think about more.

A second rock thought for the day (yeah, I usually only do one rock thought, but I have more on my mind): I was listening to Neil Young's "Razor Love". Wow.

Rock on