SANBI

Business Problem

Image: http://www.sanbi.org/screenshots/sanbi.png

The South African National Biodiversity Institute (www.sanbi.org) is the custodian of the National Botanical Gardens in South Africa, and is a respected authority in research in applied biodiversity science, climate change, conservation and systematic and collections expansion. SANBI reports to the Minister of Water and Environmental Affairs for the South African government.

According to its mandate, SANBI is responsible for making information about its research programmes and national botanical gardens available to the public via its website. Additionally the Institute needs to advertise jobs, events, shops and venues, and keep information about the company and its partners up to date in line with government policy.

The easiest way to do this is to have members of staff in various departments involved in different research or other aspects of the organization to write their own pages and have them published on the website. In order to maintain cohesion and deliver the level of service to the public required (as you can imagine, specialist horticulturists have no idea how to adapt their content for the web), it was necessary to have a set of sophisticated workflow processes involving:

• authors to write content, viewers to make comments and suggestions on the content, approvers to approve what had been written,
• a dedicated web editor to edit content written by different authors,
• a publisher for a final check to each node before putting the changes live,
• and some way of prompting authors to check their node content after a set amount of time had elapsed.

Staff members had to be able to create, update and remove their own pages, news articles, links, photogalleries, events, documents and images (all created as content types in the system). Some of these different content types followed different workflow processes and had fewer user roles, so all in all this was an extremely complicated set of requirements.

Other non-workflow aspects of the website are as follows:

• Events had to appear in a calendar,
• It should be possible to create lists of customized news articles & customized event calendars for the individual national botanical gardens,
• SANBI staff members should be able to authenticate using their Active Directory usernames and passwords via LDAP
• The publishers have to be able to see old versions of content,
• WYSIWYG content editor should have a built in interface which allows image nodes to be browsed and images to be inserted, should also allow all other content types to be browsed and links to be inserted

Why Drupal

The previous SANBI website was created over a 5 year period on Joomla. The complex workflow systems described above were written by a variety of different developers, and were not well documented or working very well, as well as not being particularly user friendly. SANBI wished to have a revamp of the look and feel, a redesign of the workflow system (the most complex part of the website), and a new content strategy.

Image: http://www.sanbi.org/screenshots/beforeafter.png

The company evaluated the time and costs for creating a better, working workflow system in Joomla and revamping the look and feel of the website, and realized that there would be fewer overheads in redeveloping the site in Drupal. Drupal’s flexible modular nature made it a good fit for SANBI’s requirements – particularly because it allowed for different content types with custom fields. At the time of development the LDAP module and a few other required modules were not working in Drupal 7, so the website was developed in Drupal 6.

Infrastructure overview

As this was essentially a migration from Joomla to Drupal, both PHP CMS, it was possible to keep the original SANBI website hosting set up. This is a dedicated server with the hosting service provider Hetzner.

Solution & Timeframe

The project took nearly a full year to complete. The development was kept in house to keep costs down, but only a single multi-skilled designer/developer was employed on the project, as well as a project manager. The lifecycle of the project involved initial brainstorming, requirements capturing (both for the staff members and with the public), wireframing and design/user interface mock ups for front end and back end & content strategy brainstorming, back end development, front end development, testing and deployment.
Before launch another development team was hired for 1 week to do some rigorous testing of the system. A project this size really requires a team of developers and a separate designer in order for it to proceed smoothly. Additional requirements kept being added to the project which further complicated matters. A project like this should take a development studio about 6 months to complete.

Custom and Contributing modules

A few different modules were used, but this write up will focus on the workflow solution created for SANBI, as that ended up being by far the most complex task.

Workflow

The workflow system SANBI required was too complex to use the workflow module for Drupal 6 (for reasons which will become obvious further on), so a new system was created using the modules detailed below.

Taxonomy module

All content types are categorized using a taxonomy vocabulary called ‘Workflow’.
The terms and their hierarchy and ordering in this vocabulary are used to record the structure of the workflow processes. When applied to nodes, they indicate at which point in which workflow process the node is at – for example, in the screenshot, the page node ‘Research & programmes’ is categorized with the taxonomy term ‘roles_request’, which appears hierarchically under the ‘Update via request’ workflow (parent) term. Saved in the term description is following information:

• the workflow role of the current user who needs to work on the node (which might be page specific, such as an author, viewer or approver, or role specific like the publisher and the editor roles – there is more information on this later on),
• their task (e.g., to view & comment on the content), and
• whether the workflow process is concerned with creating, updating or deleting content

Image: http://www.sanbi.org/screenshots/workflow.png

CCK module

Central to the idea of managing content via a workflow in SANBI’s case is the idea that individual staff members can be associated in particular roles for certain nodes, and not for others. For example user John Doe might be an author for a climate change research page and an approver for a pollination project page. User Sarah Brown might be an author for the pollination project page John approves, and also an author for a page dealing with Herbarium research. John Doe shouldn’t be able to see anything to do with the Herbarium research, and Sarah Brown shouldn’t have to concern herself with John’s climate change research page. In order to store users discretely for different nodes, CCK user reference fields were used.

The editor and publisher were ordinary drupal roles with specific permissions, and can view all nodes regardless of their workflow status and their authors,viewers and approvers. CCK fields were also used to store the deadlines for different stages in the workflow.

Workflow module

At this point, you can imagine that the create page form might be quite long and confusing as there would be:

• Checkboxes to select authors, viewers and approvers for the page.
• Duplicate checkboxes for authors, viewers and approvers, so that users can initiate role changes: John Doe might wish to ask the publisher to allow Sarah Brown to become an author as well as an approver for the pollination project page in the example above. This cannot happen until the publisher has checked the roles, so a ‘nominated author/approver’ user reference field is necessary.
• Date fields containing all of the deadlines for different stages in the workflow.
• The taxonomy workflow dropdown.
• All of the other CCK fields for various content types.

In order to simplify the interface, a custom module called ‘Workflow’ was created. This module used hook_form_alter to hide various cck fields based on the value in the workflow taxonomy. It also hid the workflow drop down and created additional submit buttons (and corresponding functions) for various stages of the workflow.

Image: http://www.sanbi.org/screenshots/workflow-createpage.png

For example, clicking ‘Save and send to publisher’ would change the workflow status to the correct term, trigger a hook for a rule (which works with the rules module and sends an email to all the users involved) and save the node.
The workflow module also has a cron hook to make sure that users are periodically prompted to update their content. It simply saves a new, unpublished revision of the node, with the correct workflow term applied to it.

Views module

A user interface was designed for the staff members’ workflow system. As soon as as a staff member is logged in they are presented with their task manager (a view containing their current tasks – i.e., nodes with particular taxonomy terms in the workflow vocabulary, and associated with the current user either as an author, an approver or a viewer). A separate view was set up to display all of their content (all nodes where that user was stored in an author, viewer or approver cck field).

WYSIWYG node picker & customisations

Images, documents and external links to websites need to be created using their corresponding content type whenever a user wishes to insert one of these items into a page, news article or similar. In order to allow users to easily select images and links within the WYSIWYG interface, the TinyMCE node picker was used .

Image: http://www.sanbi.org/screenshots/nodepicker.png

A small custom module was written to parse the inserted images & links (when the node is saved), find the corresponding node in the database, and save the node IDs to a cck field created for that purpose. This allows an element of control over what can be deleted and what cannot - a user attempting to remove a document node could be warned that a link to it appears in the latest news article, for example.

Conclusion

Drupal turned out to be an excellent platform for SANBI’s requirements, far more flexible and easy to work with than Joomla’s architecture in this case. The powerful Drupal 6 Zen starterkit for theming and the views and calendar modules meant the front end development proceeded smoothly, and other required features (like LDAP authentication, WYSIWYG node picker to insert links and image, content locking, revision moderation, google analytics, site maps, content editing previews, etc) were very easily added using the vast amount of contributed Drupal 6 modules. Feedback about the website has been positive – the public like the new look and responsive speeds and the SANBI staff like the more intuitive workflow interface. Future development for the website will include:

• Ecommerce,
• Newsletters (managed in another workflow system),
• Posts to twitter (managed in another workflow system),
• Multiple websites (integration of several other SANBI websites)