Work done on one website, utility components and common configuration patterns can now be distributed and shared to other sites. The methodology is called "Features" (which is a little bit too basic when talking about it in conversation ... but it is at least descriptive).
Drupal 'Features' support the concept of configuration-in-code. 'Features' are sets of instructions that take an existing base site and set it up in a certain way, such as by deploying security policies, page layouts, or user preferences. They can be full site recipes or just parts of recipes, such as “place a block showing the last ten media releases on the front page”.
If the Drupal module selection is a box of Lego, “Features” are the instruction booklets that tell a site how to put itself together. Once built however, the administrator can regain control and further tweak that recipe in supported ways, using the normal CMS UI.
Features can be applied to existing built sites with little impact, and even exported from existing sites for re-use on others ...if the original construction was well-built and the developers keep re-use in mind.
A Features Server is a web service that provides a library of re-usable recipes. It can be integrated with the CMS module and version management services, and in Drupal7 can even be used to auto-install these features. This could serve as a central repository for all contributing web service developers to share and improve a number of “solved problems” in the NZ Government web space. A Features Server provides both a web front-end for issue tracking and collaboration, and the back-end web service for update notifications.
You can mix and match from different feature servers, ecah development house can have their own if they want, but a nominated one dedicated to New Zealand Government specific tasks would be great.
A library of shared site recipes
We have built and deployed small number of features suitable for re-use across Government sites we build (and a large number of features that are less generic). These include tasks like:
- Setting up taxonomy lists of [New Zealand regions and suburbs], [NZGLS metadata tags]
- Configuring CMS authentication settings to comply with NZGWS
- Providing a staff database with teams and roles for use on a website
- Setting up sets of standard roles and permissions for editors and content managers
- Configuring the plugins required for a Docvert MSWord-to-text service to auto-convert uploaded documents
- Pre-configuring the chosen WYSIWYG editor to use a subset of 'safe' typography styles for regular use
Tasks like this would previously either have been provided in module code (and become hard to adjust without developer help) or been configured through the UI provided by various plugins (which is sustainable, but complex and often requires many many clicks each time)
With a central features library available to all New Zealand web teams, site administrators can pick and choose a set of functionality they want to be available to their clients, and then the clients can pick and choose:
I want a “corporate-look” site, with a media releases section, a list of contact centres, and a news feed.
After being presented with their pre-configured framework site, the site manager can customize the presets (make it just 5 media releases on the front page) and add more (or less) features at a later time.
These features should be available to and contributed by any development agency, and would grow over time. They do not all need to be built before the repository starts to become useful, as this tool works alongside the normal website development process. Already-done work can be exported from working sites and contributed back into the pool for re-use – possible after some work to remove site-specific customizations.