Forming Web Applications to Instantiate Business Processes

…”Quite rare is the Web application that doesn’t make extensive use of forms for data input and configuration” — Luke Wroblewski

Last week saw a very constructive initial meeting of a Web Forms Working Group that is charged with delivering a strategy about how forms should be surfaced, designed, tracked, and governed.  The group has been convened by the Business Process Management Office at The University of Auckland and enjoys sensible and wide representation from technical, faculty, and service-division areas.  There was a bit of discussion during the session about the definition of a form and about the scope of the group’s mandate.  Particularly:

  • Scope: when referring to a form, are we talking both about paper forms and also about web (and other channel representations) of forms?
  • Web: what is the difference between a web form and a web application?

Subsequently, i became embroiled in a way-too-long and quite-unconstructive discussion about the difference between a web form and a web application.  The two views were unable to be reconciled, though i doubt they’re actually very different from one another at the end of the analysis.  Here’s a summary of the two views involved:

  • jeff’s View: We shouldn’t fuss the distinction between a web form and a web application, because it doesn’t change what we’re trying to achieve, because web forms are notorious for becoming complex and starting to look like something more than what a web form might otherwise be, and because we’re really looking at the set of attributes that defines the behavioural requirements of some artefact that is needed to instantiate or to continue a business process (i.e., we don’t get people to fill out forms for nothing!).
  • The Other Guy’s View: Web forms are intrinsically different from web applications because they capture information but then they place it into some kind of local pre-processing suspense-type area rather than updating a transactional system with the information directly, so the difference between a web form and a web application is what happens after they capture the information from a user.

Gartner’s recently-published Hype Cycle for the High-Performance Workplace, 2009 suggests that e-forms are climbing the plateau of productivy, and offers the following defintion of electronic forms:

  • E-forms provide a user interface to data and services, typically through a browser-based interface. E-forms enable users to interact with enterprise applications and back-end systems linked to them. Web applications, e-government and e-commerce solutions have sparked the demand for better Web forms that support richer and more dynamic interactions than are possible with HTML forms. New e-form applications include XML content identification, multiple data callouts, field-level validation and embedded process logic contained within a secure and often portable format.

…and i’m taking this statement as supportive of my view — that everything is a web form, and that web forms have a bad reputation because they’ve generally been things that are:

  • implemented badly
  • ungoverned
  • allowed to grow into complex and standalone devices
  • not related clearly to enterprise business processes

…whereas web applications are just bigger versions of those things that we (often) pay money for.

This leads back to the atttributes of the web artefacts people use make things happen.  Elsewhere, we’ve identifed several potential behavioural requirements of web forms:

  • Authentication
  • Authorisation
  • Prepopulation
  • Validation
  • Integration
  • Branding
  • Email Routing
  • Event Routing/Tracking
  • Usability/Accessibility
  • Digital Signatures/Signing
  • Mobile Device Support
  • Development Speed
  • Ease of Creation
  • Training/Systems Knowledge Required
  • Multi-channel CRM integration
  • Questionnaire-Style Surveys
  • Deliverability
  • Scalability

In a constructive environment that responds with agility to business needs we should be able to interrogate a decision matrix to plug in the behavioural requirements and determine which solution patterns are suited best to enable which sets of business opportunities.  Whether it’s officially defined as a form or officially defined as an application is a Gordian knot, and nothing more than a time-consuming distraction.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s