RE: AW: XForms-processor as applet

Aha, now we have hit upon one of the most common arguments in the forms
world.  Should the form be immutable in all presentations or should it be
altered to best utilize the medium it's presented through?  The
(unfortunate) answer is that it varies from form to form and application to
application.  There is no one right answer.

In adhoc workflow forms, the presentation of the form is less important than
ease of use.  This is very analogous to the way HTML works.  You typically
want the form to take advantage of whatever screen real estate is available
and you probably want to allow the user alter the look of the form to suit
their individual needs/tastes (increasing font size, etc.).

In legal forms, the presentation of the form is more important than ease of
use.  You typically want the text presented in a certain fixed and
determinate manner.  This is analogous to the way PDF works.  You make the
medium (i.e. the screen) conform to the way you want the form presented.

Then, there's all the in-between cases.  Maybe you've got a bunch of legal
text and you don't really care how it's presented as long as it's legible
(size < 6pts) and text appears on the same page as the signature (to ensure
the signer has read it).  There's an innumerable number of in between cases
that run the gamut from "form can only change a little in this one specific
way" to "the form can do whatever it wants except that this one thing must
be true".

For V1.0 we are assuming that the user will have access to XHTML + CSS2 and
we will be incrementally improving these in the context of forms.  We won't
be tackling the printing of perfect paper forms until later (as is stated in
the "Future Considerations" of the XForms Requirements Document).

Rob

-----Original Message-----
From: Neil Walker [mailto:neil.walker@mrc-bsu.cam.ac.uk]
Sent: June 14, 2000 6:15 AM
To: www-forms@w3.org; ashutosh.galande@tatainfotech.com
Subject: Re: AW: XForms-processor as applet


> It would be highly beneficial to have a perfect rendering engine
> (independent of a browser) that will felicitate coexisting of
> pre-printed paper forms and client-printed paper forms (printed from
> within the browser etc). I feel it should be possible to print a form
> from within a browser that looks exactly the same as its paper based
> counterpart and a plugin based approach is better in this regard.

Agreed a perfect rendering engine would be a Good Thing, I feel
technology should be used appropriately.  On paper, I might say "please
circle the answer that best applies", while on a web form I might use a
checkbutton or pull-down list, and on a fax-back form a tickbox.

Like most of us on this list I'm working on a forms generator, and my
view on this is that there could be an extra button marked "Print" to
print out either a pre-prepared paper form, or something suitable
generated on the fly from the XML. The question then becomes, whether
XForms is required AT ALL, or whether we go straight for
HTML4+Javascript generation from a yet higher level metadata standard.

Yours
Neil Walker
--------------------------------------------------------------------
Neil Walker                     tel:   +44 (0) 1223 330379
MRC Biostatistics Unit          fax:   +44 (0) 1223 330388
Cambridge, UK                   email: neil.walker@mrc-bsu.cam.ac.uk
                                web:   http://www.mrc-bsu.cam.ac.uk 
--------------------------------------------------------------------

Received on Wednesday, 14 June 2000 12:19:41 UTC