Smarter Everyone, Smarter Everything, Smarter Everywhere
Engaging with customers (or employees) involves collecting information from them. To sell an insurance product, for example, you need to know what kind of insurance, how much, who's it for, their age, and a whole raft of other information. This is how we end up being able to provide a customer with an insurance quote or product, a financial preapproval, a medical appointment, and this is how we process IT requests, support requests, purchase orders, expense reports, etc.
If you're architecting a web-available XML-based information system, you will typically define the XML data required by the system. Specifically, what information does the organization need in order to process a transaction with a customer or an employee? A result of the design work will be an XML schema that describes the overall data structure and the data types for the back-end services that process the transactions. Then, a form is created to provide a web-based data collection interface for the data. Finally, there is the possibility of java servlet code in the middle to convert the data values collected by the form into the XML data structure required by your back-end services. Unless...
With IBM Forms 4.0 Designer, the XML schema describing the data structure can be consumed directly into the form design experience without the form author needing to understand anything about XML schemas. The "form author" skillset includes high precision GUI work to create either a UI that conforms to some regulations or a UI that captures and keeps the user's attention. The form author isn't and shouldn't be worried about the data structures. They want to drag and drop stuff onto a design canvas, and so much the better if the design environment makes sure that the GUI items are automatically mapped to the data structures needed on the back end to process the data collected by the form.
Here are two videos that give you an idea of what this design experience looks like: Schema-driven Forms Design and Schema-driven Forms Design and Dynamic Tables.
The form author has been provided with the data schema, and they just pull it into the design experience and ask for the data structure to be created based on the schema definition. Then, they drag and drop the GUI representations of the data elements to automatically create groups of user interface controls that are mapped onto those XML data elements. This leaves the form author free to focus on issues of colors, borders, GUI layout, and so on because the form automatically collects the data in the XML format defined by the XML schema. The form author needs no knowledge of XML schema, nor XML markup for that matter, to build up the form user interface.
The drag-and-drop operation is responsive to data types, so it creates different UI controls for various data types, such as calendar pickers for dates, check boxes for booleans, dropdown menus for closed enumerations, and comboboxes for open enumerations. The operation is also responsive to XForms label annotations on element and attribute definitions as well as enumeration items, so rather than using XML element and attribute names as the default values placed into the user interface, the data architect can assign friendly prompts or labels for element and attribute data to be collected as well as enumeration items appearing in lists.
The drag-and-drop operation is also responsive to structural definitions. If the form author drags and drops a piece of data for "Personal Details", then UI controls will be created for single child elements like "Name" and "Date of Birth" but whole subgroups of controls will be created for subtree elements like "Address", which may be comprised of child elements like "Street" and "City". Moreover, if an element being dropped includes a repeating subtree element, i.e. one bearing a schema maxOccurs value greater than 1, then a dynamic table element is created, including the insert and delete buttons that allow a user to insert or delete rows from the table.
So, have a look at the special demo videos above to see the work in action, then plug "IBM Forms" into your search engine, go to our site and download the Designer and Viewer trial software so you can give it a test drive, and stay tuned to this blog because in my next post I'll take you through a sample schema and show you exactly what bits of schema trigger the IBM Forms Designer to do something delightfully automatic for you.
One of the New IBM Forms 4.0 Demonstrations has just won the top-rated video award at Lotusphere. This is a fantastic victory for the Websphere Portal segment of Lotus, which focuses on products like IBM Forms that create and provide exceptional web experiences. It is also a victory for the W3C XForms standard since the Wizard Creator featured in the video is, as far as I know, the first point-and-click design experience for an XForms switch. This feature exemplifies the principle that declarative markup languages result in more powerful application design environments because they express what the author wants. With an imperative languages, a design environment must either operate at a much lower level (less powerful) or do some wicked reverse engineering/pattern matching to discern what the author wanted from how he did it.
So, XForms has definitely been my friend in helping to create an award-winning feature in IBM Forms. Wanna meet my newest friend? Here we are, just me and Watson, celebrating our victories at the closing session of Lotusphere 2011:
To put it in Watson's terms:
Category: Lotusphere Best Demo Video Winners
Answer: An IBM Form that uses XForms to express Wizard interfaces for forms.
Question: What is a Smarter Web Application?
MC: Congratulations Watson, you're ready for prime-time! Wanna join my social network?
The hit rate on my last blog announcement about IBM Forms 4.0 makes it clear that the release is pretty big news. I'm very pleased about that because it is a *major* release, both technically and in terms of the corporate branding. Corporate branding is not a decision lightly made, so it took the time it took, and meanwhile we didn't want to delay the technical features hitting the market, so you'll see some references to "Lotus Forms" under the covers of the main IBM branding. Not to fear, we're working on that for the next release.
Meanwhile, now that IBM Forms 4.0 is released, I've made a number of demonstration videos to show you key aspects of the IBM Forms Design and Run-time products. They're available on YouTube in HD, and they're broken into small segments, so you can really take them in pieces according to your interests.
To start, here's a 5-part series that takes you through run-time features with a demo form that ships with the product. These videos help you understand the value proposition of IBM Forms as well as new features of the release that will change your mind about what forms are and what they do.
We also now have several videos that show off the IBM Forms Designer. This release really raises the bar on what level of data interactivity can be created through design GUI configuration rather than grunge coding, and many powerful XML data processing features of the IBM Forms Designer are directly attributable to W3C XForms. This includes Design by XML Schema, Dynamic Tables, Web Service Connections, Interaction Rules (e.g. constraints), and Wizard Creation:
Finally, here's a video series on the new FormParts feature (I didn't make these, but they're excellent and really belong in this post). FormParts allows you to create components that can be reused and kept up to date across a forms library.
A major new release of our forms software, version 4.0, is now only a few weeks from shipping. And as of this release, the product line will be known as IBM Forms! This is an incredibly important indicator of the strategic value IBM sees in the Forms business as a key component in building a Smarter Planet. The feature set coming in this new major release combines the best of Web 2.0 client application behaviors and design experience with the traditional strength of interactive XML data collection for which the prior releases our product line are well known. IBM Forms documents are interactive web application instances that have many traditional capabilities that we have been building into them since 1993.
Now lets add to that what's coming in the new release:
As the XForms working group gears up for our face-to-face meetings next week, I can't help but be energized by the selection of features we are working on for XForms 1.2 (http://www.w3.org/MarkUp/Forms/wiki/Category:XForms12).
If you have a look at the linked page, you can get an idea of the current feature pipeline as well as some initial text describing each feature. Here's some further commentary on selected features.
I look forward to improvements to the available XPath function library. This includes addition of functions like pattern() and replace(), which would simplify data matching and manipulation via regular expressions. This also includes functions like an XPath eval(), XML parse() and serialize(), and run-time XML node creation functions. However, this also includes increased capabilities in the area of user-defined XPath functions and even XPath variable definitions.
Speaking of extensibility, we've had huge success with XForms by extending the capabilities of the submission element so that it is easier to connect it to more kinds of services, like REST services, ATOM services and of course SOAP-based web services. Looks like two-way JSON communications are on the horizon.
As propeller-headed as it may sound, I'm looking forward to having the context attribute everywhere. It has proven very useful for the insert and delete actions, but it is really needed in other elements. Probably most notable would be the action element, to provide a common context to a sequence of actions. Similarly, I am really ready for it on the bind element as a way to mitigate having to type so many ../ sequences into calculate formulae. Next would probably be group, to impart context without attaching to model item properties like relevance. And, of course, the repeat element would benefit just from the standpoint of parity of expression with the insert and delete actions that amend the data to which the repeat table binds.
At the UI level, I look forward to the addition of the dialog element. 'Nuff said there. We also have a basket of features intended to beef up the capabilities of the user interface switch element. Most notable will be a declarative way of binding a switch to a data node that controls which case of UI controls presented by the switch. To me, this will complete the XForms story of letting the data drive the web application.
One of the hardest problem we have to solve is to tease apart the use of relevance versus switching in various kinds of user interfaces. Right now we have UIs that need to style non-relevant controls as disabled, and we have other UIs where relevance means the controls simply shouldn't be there at all, and still more UIs where something is non-relevant because it is not yet pertinent in a multi-step UI experience, or perhaps has already been pertinent and is no longer. Some of this could be solved by better recognition of the difference between a group bound to a non-relevant node versus a switch with selected and non-selected cases, but in current XForms we have equated non-relevant groups and non-selected switch cases, so we'll need to revisit that decision. Doing this work, though, will allow us to produce a very crisp UI control lifecycle and event model, which would improve the lives of advanced XForms authors.
Perhaps the only cooler thing we could do is define the XForms calculation engine in a way that does away with "rebuild" and makes it the XForms processor's job to dynamically decide when it needs to refresh to data model calculation binds, not just UI bindings. The trick, of course, is keeping performance in the linear or nearly linear order of magnitude. But, hey, that's why it would be cooler.
Well, clearly we have our work cut out for us!