Specification Lifecycle Management

This is where administrative users:

• create specifications.

  This is a design activity that precedes the start of campaigns and other data collection activites. Users choose target datasets, define selections, and project their data onto multi-page layouts with multi-lingual contents and a rich array of presentational components and styling options. Components are format-independent while previews and dry-run facilities give confidence in the final results for target formats. The activity is highly interactive and benefits from WYSIWYG editorial support.

  Reference data is a key input. This includes identifiers and descriptions of available datasets, their dimensions and flag sets, and the underlying codelists and flaglists. Actual statistics may also come into play for previewing, though a random population (or no population at all) may yield a quicker turnaround when the focus in on previewing layout.

• edit or dispose specifications.

  These are iterations over the design activity and typically intensify in proximity of campaigns.

  If questionnaires are self-standing after generation - i.e. have no lingering dependencies to their specifications - the lifecycle of the specifications can extend beyond the start of campaigns. Alternatively, specifications are locked at the start of campaigns and must be versioned in preparation of new campaigns.

  In some cases, specifications can also be disposed of, particularly in relation to exploratory design activities.

• clone specifications.

  Cloning produce copies, hence marks the start of new specification lifecycles.

  Cloning may be used to explore design variations in the conception phase of questionnaire design. Or it may serve in lieu of versioning, i.e. an on-demand change-preservation function. This is of course lightweight, user-managed form of versioning; until a clear need for stronger support emerges, the system may treat specifications and their clones as any two, fully-independent specifications.

• browse and inspect specifications.

  These is a routine activity whereby users take stock of past and ongoing design activities, typically supported by a range of filtering and search mechanisms.

How does the current system support these activites?

Specifications take the form of questionnaire configurations and are maintained in files. At startup, configurations are processed and syntactically validated.

Configurations can be created, edited, and disposed of through an administrative interface, which mirrors closely the underlying configuration format. The interfaces provides no facilities to browse reference data in context. Cloning, versioning, and previewing are not supported.

To date, the interface remains largely unused, presumably because it abstracts too little over the complexity of the configuration format. As a result, specification management remains a low-level activity performed by system administrators, who tend to rely on external, file-based editors for management tasks.