Teaching Support Forms and Workflow Enhancements - Part 2

Final Report for CompProj:459


This project covered additional requirements for Teaching Support processes that arose since (or during) CompProj:413. It was designed to further reduce (by automating) administrative effort in managing Teaching Support processes, and in particular handling data required for course proposals.


ISS (Teaching Support)


Though the project deliverables read a little like a laundry list of issues there were three major (external) categories of change required: Changes to the established tsp forms, Changes to the course proposal (courseprop) forms (incorporating a Full Course Proposal replacement form), and Theon process changes.


The project took ~6 weeks FTE of CO time. No significant CSO time was incurred by this project. The project was undertaken over the course of approx. 6 months.

The FTE figure seemed high at first glance but on review doesn't seem exaggerated. According to my offline estimates, ~1wk FTE was spent in discussion / iteration, and core software / form development is estimated to have totalled 3.5 weeks' FTE. It's impossible to separate the development time between form and webmark core, as the two were developed in tandem, though it's worth noting that applying most new features to subsequent forms is either free, or would take a negligible amount of time (e.g. the addition of shadow db drafts to a form would take less than five minutes; tabbed browsing, half an hour or so).

One unexpected software development cost involved the production of Word-compatible documents; due to a series of misunderstandings the requirement for .docx output was not understood; this functionality in particular took approximately 1 week FTE including all aspects of its implementation (a webmark-independent tool for templating Word documents; a Webmark-specific output format to make use of the tool; adapting the existing .docx to be template-filled). It transpired that the wrong document was produced, which cost approximately 1 day FTE in repeat effort (though, lessons were learned in producing multiple documents which will reduce future effort in template production).

The project had a longer tail than hoped, partly due to occasional absences, third party testing delays and other disruption; some of the "missing" FTE can be accounted for by bug fixes and deliverable changes that, though valid, might otherwise have been considered operational or folded into future development if the project had formally concluded earlier. I note I also had a slight tendency to roll unrelated webmark changes into project notes and figures. For core webmark features this is not without its merits, as the benefits were usually rolled into the tsp forms (though, see lessons learned, below), but these could reasonably have been tracked elsewhere.


The project is substantially complete, and following various discussions with the customer the deliverables which weren't met have either been rejected, rolled into operational work, or deferred for a future project.

Technically the project was successful: the form was relatively well-received and drove major improvements in Webmark's "shadow database" which stores partial and complete submissions prior to final processing. It has brought (potential or live) benefits to all other forms in terms of reporting, display, draft handling, etc. It also drove some basic reporting functionality which allows CSOs to review submissions without resorting to logs in many cases.


Effort: Development on the form started a little later than planned and was also skewed by absences of multiple members of staff, which meant the timescale was longer than anticipated (and perhaps some duplication of effort took place, but this did not feel significant). Nonetheless a workable preview was available by BoS and staff were able to (a) fill in details for completion later^1 and (b) able to present feedback which influenced the final release. It was anticipated that some form development could have been performed by CSO - this is true, but it would have had to take place after core development in most cases which would have hampered the incremental release approach taken and lengthened time to release.

Information design: A great deal of time was spent not on the technical implementation but on the information design from the point of view of those filling in the form. After many years of producing webmark forms (and handling feedback and errors) it's nice to be to apply some experience to what will be tolerated. Nonetheless the Full Course Proposal form is enormous, by far the largest in terms of word count and user complexity, and further improvements are no doubt possible. It's is surprising how often form design is explicitly seen as "adversarial" between sender and recipient - negotiating this in advance goes a long way towards reducing administrative effort. In the future it might be worth investing my time in further training on information design to see if more gains can be had.

Live code changes: The Webmark service is now well-established and heavily used, and (largely thanks to the timesheet submissions) in almost 24/7 use. Accordingly live development now largely takes place on a development host, which is a straightforward LCFG carbon-copy of the live server. The service is designed to fail gracefully at all levels -- though this doesn't guard against merge errors and common-variety human commit errors which jeopardise form submission any time code is updated! The cost of this sort of error remains low, but it's higher than it used to be and it might be worth considering dedicated Webmark instances (i.e. per-form) where development of new features for one form set carries a higher-than-usual risk of upsetting features in use by others. However I'd likely only consider doing this with a framework for seamless handover between instances, as fragmentation carries its own higher risks (and certainties) of trouble.

Accessibility and mobile access: Webmark has always maintained a strict policy of graceful degradation, and attempts lowest-common-denominator browsers support at all times. The full course proposal form is by far the largest and most complex form Webmark hosts, and designing the input flow in a way which maintains that support is important. However on early testing of the full course proposal form it became clear that it was significantly harder to fill in this complex form on mobile browsers^2. A few basic changes to Webmark's presentation layer were made, such that the same form layout would work on any style of browser. . As a consequence of this work I was also able to roll out improved mobile browser support on all forms with very little change to the site's appearance (on any platform) and with little or no change to individual forms.

^1 (with no loss of work, as the "online draft" feature was one of those driven internally by this project)

^2 A recent (rough) log analysis shows that mobile traffic to Webmark has been increasing continuously since its creation, and now constitutes as much as a fifth of our traffic. No further breakdown was performed in terms of numbers / types of forms submitted, but it's worth noting this is not an insignificant use case.

Future Work

Major changes that I expect to see in future projects:

  • Many front-end changes have been requested in the course of implementing this project, and those which were considered out of scope are listed at TeachingSupportFurtherEnhancements for a putative "Part 3" project. The only major back-end changes which didn't take place was the addition of file (upload) handling (since the deliverable which requested this was rejected) and custom validation (which wasn't needed at all). Much of the code for both of these now exists in some form, but full implementation and extensive testing would be needed.
  • Issues of data retention around the shadow database and caches - until recently handled in an ad-hoc fashion - are beginning to be addressed but these must be completed in a timely fashion and in concert with the release of (per-form and more general webmark) Privacy Statements.
  • The shadow database work has also made significant leaps towards a major Webmark milestone: atomic releases. The next project to involve work on shadow DB handling should include time to complete this feature, which will reduce ISS and computing support effort around mistaken / repeat submissions.

Much lower priority items:

  • Some investigation was made into the use of scripted browser environments to perform basic availability checks (and even basic automated regression and unit testing, in theory). Basic authentication and form selection was achieved, and a system to observe changes was worked out. It wasn't very usable -- more work would be desirable.
  • Some mechanism for handover between webmark instances, should the need arise for multiple live webmark instances (though personally I'd prefer better code control).
  • The utility which performs basic .docx templating could bear improvement and widening for use with more outputs -- or perhaps adapted into a more mature templating library. This is more of a 'stargazing' type goal.
  • A generic X -> PDF output module using unoconv was created; this turned out to be impractical in its basic form (required a daemon, and took many seconds to perform a conversion). This could use more further investigation.

-- GrahamDutton

Topic revision: r7 - 13 Feb 2019 - 13:45:46 - GrahamDutton
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies