Views
The Multi-Modal Web App
From PicoForms
Now that PicoForms has an XForms plug-in for Microsoft Internet Explorer (currently in closed beta testing phase), we are in a better position to begin to explore the challenges behind XForms' claim to be a platform for multi-modal Web applications.
Contents |
[edit] The Task
Proof of pudding is in the eating, so we decided to take an existing XForm (see: UK Life and Pensions article) that was designed to run on a mobile phone, and try to run it in Internet Explorer. We went for a form intended to show a professional financial adviser up-to-date information about a client's personal pension plan. There are several good reasons for this choice:
- The application is just as useful on the desktop as on a mobile phone.
- The application displays a lot of structured data that was challenging to present well on the mobile device.
[edit] The Form
[edit] Customer Search
Here the adviser provides the reference, or name for the customer they wish to retrieve details for. Two options, pretty straight forward stuff.
Here is the original:
Our main concern for the mobile platform was to provide quick access to the search option that requires the minimum amount of navigation and typing from the user. The Customer Ref field is selected when the form loads, focus moves directly to the Find button as soon as a value is entered.
For the desktop, these problems disappear (assuming a sighted user with the ability to use a mouse), but the design still works. So we ended up with the following:
Same XForm code, but different CSS applied. So, thus far the form has not changed. That said, it is now only taking up the top right-hand corner of the window, so there is plenty of room for more. Let's assume that our form is likely to be embedded in a parent application, so we won't gratuitously take up more screen space than we need to just now.
[edit] Customer Details
This is where things start to get challenging for the mobile app. Lots of data to slice up into manageable chunks that still tell the user enough to be useful to them
We broke things up into tabs. The first tells you whether you got the right customer, and what they look like (or not). The second tells you where they live and the third lists all the policies that you have authorisation. The sequence in which information is set out is a logical progression for the adviser. Address can be skipped if the adviser wants to move staright to the list of policies.
We could have presented all the information together, as one scrolling list, but we felt it was better to highlight what information was actually available in the tab headings at the top, and to provide the means to jump straight between the three sections.
For the desktop form, screen real-estate is not such an issues, and so we decided to reduce the number of tabs to zero and make everything visible at all times.
Unfortunately this meant that we had to go beyond using different CSS, and we actually had to rearrange display items in the form itself. However, this isn't as bad as it first seems. The logical grouping:
- Photo + personal deatails.
- Address
- List of pension policies
are still valid, they have just been arranged in a different order, and are all visible at the same time. So, the core elements of the form remain untouched, but the UI logic around them has changed.
We found that this was a recurring theme as we looked at the rest of the form. The groupings, normally suggested by the XML instance displayed in the form, are retained, but the increased screen area allowed more to be seen at any one time.
Perhaps most profound in impact is the change in screen orientation from the mobile phone's portrait, to the PC's landscape screen. Suddenly a tabular layout, rather than a straight forward list-with-caption layout became not only practical, but essential to make best use of screen space.
[edit] Policy Details
In the mobile application once a policy has been selected we move on to another set of tabs that break up the rather detailed information returned into logical and manageable groupings.
Again the logical groupings are suggested by the source XML document being rendered, and even with paged tabs it is still necessary for the user to scroll, though this will vary with the format of the device being used - a PDA with a larger screen will be more comfortable to view.
For ghe desktop view we have taken the opportunity to leave the still essentially portrait view of the customer details on the left-hand-side of the screen, whilst viewing the policy details in the right-hand two thirds of the window.
We can now see that the customer details view, even with all elements visible at the same time, is probably taking up a disproportionate amount of space. It this were a rel application we would take the time to reorganise this part of the application space further, either by narrowing further to the left, or perhaps into a bar running across the top of the screen.
The policy panel has remained largely intact though. There is still too much information to display comfortably in one screen, and the groupings we have already established still make perfect sense. The challenge now is to move from a vertical list view of data, to a tabular view.
Surprisingly this is actually quite easy to achieve using just CSS. We revisited the original HTML markup of the form to genericise what we had (fewer semantically significant elements such as <a/>, more <div/> and <span/>, and then found that we were able to preserve both the original layout, and the new tabular layout just by swapping in and out different CSS.
[edit] Conclusions
For this form at least it seems true to say that it is not really possible to just reuse the same application layout on a mobile device and desktop PC. However, this is not actually as bad as it first seems.
Firstly, and most significantly, the XForm model, containing data, and submission information, was not touched in moving the application from mobile device to the desktop. This represents a potentially significant measure of reuse in a more complex form than this, and helps to demonstrate one of the chief values of XForms use of a model-view-controller architecture.
Next, we should not that the vast majority of look-and-feel changes were managed by adding and referencing new CSS. It is with precisely this benefit in mind that XForms defines its form and layout controls in such generic terms - so that by their use the form designer is not bound to particular presentational limitations.
Finally, the few changes that were necessitated by the change of modality did not involve a fine-grained rewrite of the form, rather a simple rearrangement of logical units, and the stripping out of some grouping structures.
So whilst we do end up with two forms, each tied to its own modality, they are recognisably derived from the same logical form, and there is a good chance that their derivation from that logical starting point - based on the underlying data and its use - can be formalised as transformations to recognisable and reusable design patterns.
Future articles will explore this line of thought in more depth. Perhaps the next challenge is to re-use the same form as the basis of a voice-driven application for use on a conventional telephone.
