XForms for Prototyping

By Philip Fennell
December 1, 2008 | Comments: 10

There is a group within the organisation I'm currently working with who are interested in the concept of prototypes as specifications. They cite the Silicon Valley Product Group's blog entry High-Fidelity Prototypes as a good example of this thinking and from which I draw one of the stated benefits:

A high-fidelity prototype provides the engineers and QA organization with a rich, interactive description of the product's intended functionality and design to be used as a reference basis for implementation and test.

Whenever this subject is raised my thoughts turn immediately to XForms. For the client side of web applications, XForms provides descriptions for the data model, its bindings to the view (form controls), business rules/logic, data submission, user interactions and error handling. All that is left is structure and presentation, which can be handled by the host document (e.g. XHTML or SVG) and CSS respectively.

Gathering and Managing XML Information

XFormsXForms Essentials — You'll learn how to integrate XForms with both HTML and XML vocabularies, and how XForms can simplify the connection between client-based user input and server-based processing. If you work with forms, HTML, or XML information, XForms Essentials will provide you with a much simpler route to more sophisticated interactions with users.

The fact that XForms is not natively supported within browsers, and therefore slightly more problematic to deploy across the web, does not mean that your prototyping efforts are going to be wasted. The advantage of prototyping with XForms is that it is quick, declarative, readable and well defined. The good separation of concerns helps concentrate the mind wonderfully. Gone are the good-old days of Photoshop layered walkthroughs, nasty hacked-together DHTML, or the even more esoteric Director demos that I've encountered.

XForms allows you to start simple, working with static instance data to test-out the basics. Then look at the customer's requirements for constraints, validation and logic. Once you feel you're on the right track you can retrieve the data from a server and start working on you RESTful web services. Presentation can be layered on top without affecting the underlying data bindings or business logic. It's easy to see how you can be very Agile when working with XForms.

How you go on to deploy the final application is up to you. You can keep it XForms and look at a variety of server-side and client-side implementations. If there are specific customer requirements/constraints that mean you need to look at either an XHTML/AJAX application or maybe Flash/Flex then the details of the design, as described by the mark-up in your prototype will aid that transition, and after all of that, when XForms becomes main-stream, and it surely will, the knowledge you'll have built-up with your XForms prototyping will put you in a commanding position in the advanced web application sector.

In a series of up-coming posts I will be illustrating how XForms can be used to prototype an Atom Publishing Protocol (AtomPub) client.

You might also be interested in:


I completely agree with your suggestion to use XForms for prototyping.

Programming with XForms is quite concise because it is in a declarative approach and it simply does what you it to do ! Programming or logically specifying, it's the same with XForms.

I think that the main problem is the lack of browsers support. Server side solutions need J2EE servers and it might be a problem for some organizations, especially "just" for prototyping (eventhough it is very important from my point of view). I have re-engineered AJAXForms (http://www.agencexml.com/xsltforms/) so XSLT is enough to convert XForms to XHTML+AJAX and it can be used on almost any browser. Because it's a free opensource project, it is perfect for prototyping, even with Internet Explorer !


I really must have a look at your XSLTForms. I have previously worked on similar projects that implemented, in my case, a subset of XForms via XSLT and JavaScript so I'd love to see what you've been up to. I've also worked on other XSLT transforms that convert XForms to Flex. However, Flex falls way short of what XForms can do on the declarative front. There is a lot of ActionScript required to bridge that gap.

As you say, the trick is plugging the plug-in gap until the browsers go native with XForms.

Hi Phil,

Can you give me more information about XSLT to Flex forms? I am interested in converting an XSD schema into a Flex form.



I totally agree with everything you said. I have been using XForms for prototyping for almost three years now and there is NOTHING that comes close to its power. I start my JAD sessions by drawing XML Schema diagrams in front of my users on a SmartBoard. It takes them about 20 minutes for them to get familiar with the notation. Once we get all the elements in the XML Schema I just save the xsd to a native XML database and "poof", I generate the XForms application directly from the XML Schema (and metadata from a metadata registry) using a simple XQuery. This high fidelity prototype can be used to validate the business requirements and even be used in the application.

I am looking forward to your future posts.


You describe a very compelling workflow for you design process.

My intention is to use the series of blogs to illustrate how you can manually build the AtomPub client prototype with successively layered aspects that illustrate the very good separation of concerns that can be achieved with XForms and its host document.

The ability to generate the same result automatically, with XQuery and/or XSLT, from a schema just underlines the power and cohesiveness of the XML stack.

An interesting idea, but I don't fully agree. Using XForms for a prototype will result in a very data driven, programatic prototype. Thats fine if you are largely only looking to test the flow of information of a project - i.e. the IA side of things, but that's of little use if you are testing the design, interaction, iconography, visual concept, etc. I can't see how an XForms prototype can easily and quickly fulfil the need for that kind of work.

I think you are forgetting that XForms works within a host language, in most cases XHTML but SVG would be equally applicable, and as such it is the clean separation between presentation and data that XForms affords you. Therefore, when you are working on the data binding and business logic aspects of your prototype you can also have people looking at the presentation and interaction aspects on a parallel track. It is then relatively easy to merge the presentation layer with the data/logic layers, resulting in the 'high-fidelity' prototype of which I we seek. But the important thing to stress here is that the separation is not lost in the merging process. You try to pick apart some prototype delivered in Director, for example, and you'll be in for a rough-ride.
XForms is not the whole solution, it is an enabling component that sits neatly within the prototype, providing a solid foundation for data driven applications upon which presentation can be layered and demonstrated/evaluated in a more realistic fashion.

What you describe has significant development time and complexity verses faking/mocking-up a user journey in flash or rough HTML+JS+CSS. Making a prototype they way you suggests mean you end up with what is almost a product, rather than a proof of concept prototype.

The aim of a HiFi prototype is to act as an interagtive style and interaction guide, but very specifically not to provide any usable assets to a final product. To do so introduces risk, as interntionally unoptimised and non-thought out elements would bleed over from the prototype to the product.


It would seem that we are at opposite ends of a spectrum and we'll end-up agreeing to disagree; though you rightly point-out that 'unoptimised and non-thought out elements would bleed over from the prototype to the product', but that can happen in both scenarios.

The 'faking/mocking-up' is what I'd call a 'fire-and-forget' prototype that only deals with the surface layer of a product and ultimately becomes someone-else's problem to implement. In addition, when not properly grounded in reality, such prototypes can set expectation in the cutomers mind that cannot be easily delivered without extensive developement down the line, and can adversively affect the cost/time/quality equation when ill-thoughout but non-the-less signed-off designs have to be implemented.

Conversly, a prototyping process that encourages the layering of aspects, the separation of concerns and is grounded in reality will not necessarily take any longer to build; it plays to the strengths of Agile's 'Release early release often' mantra and the end result is both better thought-out and has the added benifit of the real possibility of code re-use between prototype and product. In my opinion, the second approach has the better chance of ironing-out problems early-on and is also born-out by experience.

Phil - referring to xforms and flash/flex - we are looking to build an xforms processor for as3. Just interested to see how far you got in to it and if you can share any knowledge i'd be most appreciative.



News Topics

Recommended for You

Got a Question?