Active Forms

Requirements for On-Line Forms

• Appearance:
  • familiarity - looks like the appropriate form
  • integrity - related information is seen together
  • function - data entry, labels, explanations, submission, etc.
• Functionality:
  • support for entry of complex values (example: map regions)
  • complex (cross) validation of fields at time of data entry
  • conditional presentation of blocks of fields
  • minimal non-redundant data entry - default and computed values
  • selective/re-active level of instructions, advice
  • ability to save/print replica of filled-in form
  • protection of privacy when submitting form

Architecture Choices

• Extend HTML:
  • + likely to meet appearance requirements: style sheets, frames
  • - unlikely to meet functional requirements
• Provide additional scripting capabilities (example: JavaScript)
  • + single specification of presentation and function
  • + most functional requirements can be met
  • - limitations of types of event notification
  • - some functional requirements not yet met
• Use Applets (examples: Java, Tcl/Tk)
  • + all presentational/functional requirements can be met
  • - specification "split" between HTML and applet
  • - complex interaction between browser and applet

An Applet-based Approach using the SurfIt Tcl/Tk Browser

• SurfIt is an HTTP/HTML browser, which supports Tcl/Tk applets (compare Netscape, which supports Java applets).
• It uses the HTML 3.0 feature which allows the SCRIPT attribute of the FORM tag to associate a client-side script with a fill-out form.
• No extensions to HTML are required, due to the availability of Tk for managing the form.
• The environment in which Tcl applets are executed includes:
  • evaluation in a safe slave interpreter, with an isolated namespace protecting the browser and other applets from interference.
  • access to windowing functions via Safe-Tk, with a top level window automatically created for the applet.
  • access to the browser window in which the applet was loaded.

Browser and Applet API and Interaction

• The applet Commands:
  • browserversion, embedwindow, embedindex, level
  • formendindex, formitems
• Browser Call-ins:
  • terminate
  • HMend_form, HMreset_form
  • HMsubmit_form method query
  • HMapplet_item type name value widget

Example - SurfIt Browser

• See http://pastime.anu.edu.au/SurfIt/
• Example: Australian TaxPack Form

The SurfIt! WWW browser

Example - Sample Form

A sample form, with the applet displaying information gathered for the input items

Example - Conditional Blocks

The form before the user has pressed the "Yes" button.

The form after the user has pressed the "Yes" button.

Future Work

• Form State:
  • volatile form state is maintained by the applet, not the browser
  • browser needs to know form state to cope with applet termination
• Reloading Forms:
  • data entered into form is not preserved when the applet terminates
  • form state should be saved and applets suspended, to permit reloads
• Stylesheets:
  • text added by an applet to a form should conform to the style
  • best done by adding text to/as HTML elements
  • but this is problematic when adding an element with subclassing

Conclusion

• Forms need to present, selectively gather, and validate information.
• Presentation, within the WWW environment, is best specified via HTML (with extensions) and controlled via the browser, but gathering and validating inputs is best done by an applet or script with full GUI capabilities.
• However, this currently leads to complicated interactions between HTML, the browser, and the applet or script.
• It would be desirable to have a single specification of all aspects of a form, whether presentational or computational.