W3C home > Mailing lists > Public > www-forms@w3.org > February 2004

RE: how do you do this form in xforms?

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Mon, 23 Feb 2004 17:12:58 -0000
To: "'Ian Hickson'" <ian@hixie.ch>
Cc: <www-forms@w3.org>
Message-ID: <003201c3fa30$490849c0$6b01a8c0@W100>

Hello Ian,

> I've been keeping an eye out for forms to see if there are any that
> could be simplified by some simple addition to the Web Forms spec I'm
> working on, and I came across this W3C form:
>
>   http://www.w3.org/2002/09/wbs/35125/tp2004/
>
> ...specifically the section entitled:
>
>   Attendance to Monday Mar. 01 meetings

Thanks for posting this, and it is indeed a good form to use to show the
power of XForms.

I think the first thing to establish - before we use this form as an
illustration - is what exactly the form does. This is important since
XForms is at its most useful as a way to capture a forms 'purpose',
rather than getting too bogged down in whether to use one control or
another. It is this that makes it possible to then use the same form on
different devices.

So, although the snippet you have given us has 'radio buttons' and
'check boxes', we really want to know what information the author was
trying to garner from the form-filler, rather than simply saying "let's
have a check-box here and a radio button there".

The form snippet as it stands does the following:

1. A user can indicate that they will not be attending on the
   specified day.

Or:

2. A user can indicate one Working Group that they will be attending
   that day.

Or:

3. A user can indicate that they would like to be an observer
   on that day ...
4. ... in which case they can request observer status at one or more
   Working Groups.

Note that not all groups accept observers, some accept them
unconditionally, and some accept them with the permission of the chair.

In the form you posted, points 1 to 3 are achieved through 'radio
buttons', which means that the options are mutually exclusive. Point 4
is achieved through 'check boxes' which means zero or more of the
options can be chosen.

I've spelt this logic out because the form that you have referred to
does allow some permutations that it should not - for example, you can
indicate that you are attending a WG all day, and still request observer
status at another WG. But since to start getting into this level of
checking on the client would involve all sorts of scripting - something
that would get painful to maintain as the number of days and workgroups
increased, and is one of the prime reasons we need XForms - we can
forgive the author that. ;-)

> I'm curious to see how an XForms version of this form would be
> written, to see if the XForms way would result in a better user
> experience (as I imagine it should). However, I couldn't work out
> how to do it myself. Could someone give an example of that section
> done as an XForms form?

OK. The form is at the end of the email, but I'll go through how one
would build it up, using XForms concepts.

In XForms parlance, from the above 'logic' we first need an xf:select1
to indicate whether the form-filler will be:

(a) not attending
(b) attending a workgroup
(c) observing one or more workgroups

If (b), we then have a second xf:select1 to select the workgroup, and if
(c) we have an xf:select to choose 1 or more workgroups. Note that the
list of choices for the latter is only those that accept observers
(unlike the form that you have referred us to which shows all Working
Groups).

However, whilst it is always tempting when designing forms to begin with
the UI controls, let's put those to one side for the moment, and let's
look at how to capture the form's logic. If we can get that right, we
can put any UI we want on afterwards.

So, the current HTML form has two values that get returned to the
server. The first has the following possibilities:

na    - the person is not attending that day
obs   - the person would like to be an observer that day
css   - the person will be attending the CSS Working Group
mmi   - the person will be attending the MMI Working Group

And so on for all the possible working groups.

If this first value is 'obs', then a second field should become
operational, and this contains a list of groups, picked from the same
range of values as the first field, i.e, 'css', 'mmi', and so on.

Despite what the *layout* of the form tells us, looking at what actually
gets submitted to the server, what I have outlined here is the *intent*.
This logic is extremely trivial to capture in XForms:

    <xforms:model>
      <xforms:instance id="instMyAnswers">
        <instanceData xmlns="">
          <day id="0" att="na" wg="" obs="" />
        </instanceData>
      </xforms:instance>

      <xforms:bind nodeset="day/@obs" relevant="../@att = 'obs'" />
      <xforms:bind nodeset="day/@wg" relevant="../@att = 'wg'" />
    </xforms:model>

The first part (the instance data) is a simple XML node that will
capture our data from the user. As you can imagine it would be very easy
to add more nodes for more days of the conference. The second part - the
bind statements or 'business rules' - allows us to say that the question
relating to observers (@obs) is only relevant if the attendance question
(@att) has been answered with "obs". Similarly, if the user answers "wg"
to that question, the question relating to the Working Groups becomes
relevant (@wg).

How the logic of this form is presented to the user can be layered onto
this, and it may well be the case that different authors or different
web sites have different form layouts that interact with this 'model'.
But what should be clear from the few lines of code we have here, is
that keeping the logic separate from the presentation means that we get
the information we want, whether the user interacts with this data via a
voice system, or WAP phone, a WebTV, or a full-fledged browser on a
desktop.

For our example, we will say that any question that is 'not relevant' is
hidden:

    <style>
      *:disabled { display: none; }
    </style>

Whatever CSS is chosen for the output (and that is up to the author),
the important concept here is that the logic of the form has been
captured in a way that is easy to see, test and reproduce - and
certainly not hidden amongst a jumble of controls and JavaScript.

I hope this goes some way to answering your question. A full version of
the form discussed above (tested with formsPlayer) is available here:

    <http://www.formsPlayer.com/demo/tech-plenary.html>

As you'll see it is a much clearer user experience, and I would even
venture that it is clearer to read for developers.

Best regards,

Mark


Mark Birbeck
CEO and CTO
x-port.net Ltd.

http://www.formsPlayer.com/
Received on Monday, 23 February 2004 12:13:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:57 GMT