You are here

Webmark Reform

Project ID: 
Current stage: 

Description: Enhance the existing 'Webmark' service, partially in response to recent requests, to produce a more general-purpose form generation and submission system, to be known as 'Reform'.


  • A refreshed version of the existing Webmark service which functions similarly to the existing one.
  • Additional core functionality such as field validation, multiple data sources, chained inputs and outputs.
  • Generic input, output, form source APIs.
  • Allow external sources to define form contents.
  • Configuration format reworked to act as complete form descriptor (where appropriate)
  • Draft form storage
  • Session change handling.
  • All forms to be converted to new configuration format, or full support for legacy configuration
  • Project choice agreement form, if still required
  • Partial delegation of form structure to authors


School of Informatics; Computing Support, Undergraduate and Graduate offices.

Features typically requested by members of the teaching offices, with input from academic staff.

Case statement:

New forms and features of the additional forms are now being requested by members of academic and teaching staff, and the existing Webmark framework can no longer cope easily with these changes.

For the past four years, most new forms have demanded some new functionality of the system, and while most could be integrated neatly, others were bolted on hastily and have demonstrated a limit to the flexibility of the core of the system. Continued augmentation is now difficult to do in a safe and clear way, and in particular integration with established School Database systems, which would save considerable effort for administrative and academic staff in teaching duties, is difficult. Requests continue, in particular a new requirement for a "project choice agreement" form which requires more complex interaction with school data, and demand for additional features continues to be expressed by ISS and teaching staff.

Furthermore, form configuration is straightforward at present, but enforces limited functionality. Without redevelopment, existing form commitments cannot be fulfilled in their entirety and future additions and modifications will be comparatively expensive and error-prone.



Webmark was originally developed in 2007 as a means of generating the multiple paper marking forms required by both College and School for final-year undergraduate and MSc students. The initial design specifically limited the scope of the project and the first revisions met the requirements well.

The existing Webmark service continues to function reliably and allows the straightforward addition of new forms where the demands of those forms do not differ from existing ones, however new features become increasingly difficult to add to the existing structure.

Requests both for additional forms and extended features of existing forms have been pending for some time.


New form configuration is always ongoing and will likely be performed in parallel to development of the new service. The sooner the service is redeveloped, the more customer time will be saved.

Focus on this work will be affected by high-prior


Time: Estimates:

  • ~1 week to plan architecture for core
  • ~2 weeks to fully rework core including
  • ~1 week to reimplement dropped core features in new API
  • ~1 weeks to refactor existing I/O and to add new modules
  • ~2 weeks documentation, testing, support training

Proposal: To follow the plan according to the description to provide the deliverables within the specified time.


  • CO time
  • One Apache-capable DICE server (already exists)
  • Access to the school database


  • Produce architectural overview, recommending development options.
  • Reconfirm requirements and pending augmentations of existing forms.
  • Work out wider picture wrt database connectivity.
  • Rework / rewrite core to allow full extensibility. Augment core with new functionality as required. Remove functionality where it can be provided in a more generic manner.
  • Rework inputs / outputs to use new core API
  • Document APIs and configuration format.
  • Evaluate form drafting functionality, potentially as generic input/output.
  • Add new input/output modules. Ensure these are self-documenting at a level usable by form authors
  • Adapt existing forms to new format (possibly delegated)
  • QA against existing form output


Forms depend upon the "Theon" School Database, the Projects Database (though see project sortable list"; also utilises the ISS Request Tracker system.

At completion, expected to continue to depend on both the School Database and the ISS RT. Non-submission data (for example, for form coordination) might reasonably be expected to rely on a dedicated database.


  • Usual risk of slippage.
  • Semi-public service: security of input to receive extra attention.
  • Insufficiently flexible redesign will be no more adaptable to customer requests.
  • Overly flexible redesign will be too complex for authors / support to administer.



Proposed date Achieved date Name Description