Vital Signs 2.0 (VS) is an educational citizen science project consisting of an extensive Drupal website created by Image Works in Portland, Maine for the Gulf of Maine Research Institute (GMRI) and funded by the Hewlett Foundation and a generous in-kind donation of services by Image Works.

The VS project provides students, teachers, scientists, and citizen scientists with the tools to monitor environmental conditions throughout Maine. The project includes a structured central data repository, tools and protocols for identifying, mapping, tracking and analyzing the occurrence and spread of invasive species into and around the state. Beginning in fall 2009, these resources and supporting programs are being utilized on the laptop computers provided to all Maine middle school students and will be made available to all interested parties starting early 2010.

The project's site is composed of 13 original custom Drupal modules, approximately 2 dozen Drupal core modules, more than 40 contributed modules, Google Maps and other web services. In order to give back to the community that made this project possible, we are releasing the full source code for the website under the GPL license and adding it to the Drupal.org project repository.

Participation

Vital Signs targets and encourages participation from three primary groups of users: 7th & 8th Grade students in Maine, individuals with an interest in studying, monitoring and preventing the spread of invasive species, and research scientists studying invasive species.

User generated content

Vital Signs provides its community with a number of avenues for contributing content to the site. These include:

• Species Observations
• Projects such as presentations, videos, and podcasts
• Curriculum Resources
• Peer Review and comments
• Expert Review and comments
• Community Policing
• Forums
• Commenting

Development Process

The development team consisted of 2 Drupal developers, an Adobe AIR/Flex prototype developer, 2 graphic designers, an information architect/project manager, and of course, the client. We followed an agile process where we tried to do releases for the client review every 1-2 weeks. This allowed us to have continuous feedback and adjust the path that the website was taking. We used the open source MantisBT bug tracker for all of the issue tracking and change requests.

Each developer/themer worked on a local copy of the website that was checked out from Subversion using periodic database snapshots from the live site that the client was entering content on.

Early in development when radical changes were expected, we set up an installation profile that would allow us to modify core settings in the system (such as content type structures) and quickly wipe/recreate the site. We only used and maintained the install profile until the site reached a stable state and the client was ready to populate it with real content.

When doing releases, we had two websites setup on our server at Rackspace: a test site for reviewing and testing new functionality, and a staging site on which the client was entering the actual site content that would eventually become the production site. During our 1-2 week release cycle, we would update the test site by simply logging in via SSH and issuing an “svn update” command on the test website. This would sync the site with the latest version of the source code. Any database modifications required by the new release were built into the update scripts for the Vital Signs module.

When we hit each major milestone in the project, we would do a brief code freeze and deploy the current version of the site in the test environment to the staging environment using “svn update”.

Performance and Hosting

The site is hosted on a single server at Rackspace. The primary things we did to optimize performance were to write clean, efficient, and solid code and take advantage of the performance boost provided by APC.

Amazingly, even though we have a large number of modules installed and enabled, the per-request memory footprint of the site is relatively low at 25-40MB, depending on the page.

Challenges and solutions

We faced a number of challenges in the development of Vital Signs. Some of the significant ones include:

Non-admin users managing user accounts with the same e-mail address
One of the primary requirements of the Vital Signs site was that teachers could create user accounts for their students without using any email address belonging to the students. For example, teacher John Smith may decide to break his class up into 4 teams. He would create 4 student user accounts that all have his email address. Additionally, he may want to re-use these 4 team user accounts across multiple classes, so there needed to be a way for him to manage all user accounts that he created.

Our solution to this challenge was a mixture of contributed modules and custom administration screens. We use the SharedEmail module to allow creating multiple user accounts with the same email address. We then added a hidden profile field to link the student user accounts to the teacher user account so that we can reliably determine which users the teacher had permission to manage. Finally, we created a custom user account management screen that the teacher uses during the setup of their field trips. This custom administration screen gives the teacher the ability to either add previously created user accounts to the new trip or to create completely new user accounts.

Role-specific user profile fields
Related to the above challenge, we also needed the ability to define different tabs of information on the user profile screen based on the role of the user. For example, teachers have a tab asking information about their teaching background that does not display for students.

We addressed this challenge relatively easily using the ProfileRole module allowing us to define which roles had access to each of the tabs on the user profile screen.

Preventing some users from editing their profile while allowing others
In the case of student user accounts, since there was the possibility of them being shared between multiple students of a single teacher we had to find a way to disable and hide certain fields on the student's profile page. For example, we didn't want the students to be able to see or change the teacher's email or the account password.

We solved this problem by using a combination of the UserProtect module and some custom theming. The UserProtect module allowed us to define additional permissions to allow editing of individual profile fields on a per user role basis. We then took it a step further, removing the locked out profile fields from the page display for those user accounts.

Specialized custom e-mail notifications
There were several specialized e-mail notification requirements of the site that required some custom development. For example, when a visitor submits a species observation the site needed to be able to inspect the values entered in the CCK fields of the content to determine which species was looked for and then search through the profile fields of all of the user accounts in the Expert Review role to determine which users are the reviewer of that species.

We solved this challenge by extending the Notifications and Messaging modules to provide custom notification hooks and custom message templates. When an observation is published, the site triggers the notification hook which inspects the observation for the species and then searches the list of expert reviewers for the appropriate user accounts. It then passes control back to the built-in notifications module to queue notification emails to those select user accounts.

Conditionally changing some text on the site based on the age of the visitor
In order to comply with the COPPA laws and current best practices for users under the age of 13, we needed a process for conditionally changing some of the text on the site for registered users. For example, on the user registration page we conditionally change the labels on the e-mail field to say “Your parent's e-mail address” rather than “Your e-mail address”. We also make a similar change to the Terms of Service acceptance checkbox label.

The solution to this was using hook_form_alter to dynamically modify the text of page elements based on the birthdate of the visitor.

Allowing a save & continue capability on incomplete content
Some of the data entry forms can be quite long so we needed a way for users to be able to save their data in an unpublished state even if some required fields had not been completed.

The solution to this was to add a custom “Save & Continue” button to the data entry forms that took advantage of the SkipValidation module to conditionally disable Drupal’s form validation routines and allow us to save incomplete nodes to the database.

Disabling anonymous user page caching on select paths
There are three pages in the Explore Data section of the site that allow visitors to search for and visualize observations in a variety of ways. Since this was a dynamic search, we couldn't allow the pages to be cached by Drupal but we also didn't want to disable caching altogether for the entire site.

The solution was to install the CacheExclude module which allowed us to define a set of site paths that would always be excluded from the Drupal page caching.

Modules used

Obviously a site of this complexity uses many contributed and custom modules. Below is the full list of modules used on the site.

Core Modules:
Block, Blog, Color, Comment, Contact, Database logging, Filter, Forum, Help, Menu, Node, Path, Profile, Search, Statistics, Syslog, System, Taxonomy, Tracker, Trigger, Update status, User

Contributed Modules:

• Administration menu
• Admin Role
• Advanced help
• Advanced User
• Chaos tool suite
• CacheExclude
• Calendar
• Checkbox Validate
• Content Construction Kit (CCK)
• Custom Breadcrumbs
• Date
• Dirty Forms
• Embedded Media Field
• FileField
• Flag
• Flag Abuse
• GMap Module
• Google Analytics
• Image API
• ImageCache
• ImageField
• IMCE
• Install Profile API
• jQuery UI
• jQuery Update
• Keys
• Legal
• Messaging
• Nodewords
• Notifications
• onBeforeUnload API
• Page Title
• Panels
• Pathauto
• PNG Fix
• Profile role
• Shared Email
• Site map
• Skip Validation
• Token
• Transliteration
• User Protect
• Views

Custom Modules

• Vital Signs : General utility module
• VS Calendar: Handles the Calendar of Events
• VS Data Entry: Handles everything related to the student and teacher data entry process
• VS Explore Data: Handles the display and functionality of the Explore Data section of the site
• VS Export: Allows users to export the site observation data as a CSV file
• VS Flags: Create custom flags for site visitors to notify the administrator of inappropriate photos or potentially invalid data such as GPS locations in the middle of the ocean.
• VS My Vital Signs: All of the custom blocks used on the My Vital Signs dashboard page
• VSORE: All of the customizations related to the Shared Curriculum Resources area of the site
• VS Project Bank: All of the customizations related to the Shared Projects area of the site
• VS Review: Custom Sidebar blocks and notification hooks related to peer and expert review
• VS Science Notebook: Customizations related to creating Science Notebook content
• VS User: Handles all user customization and permissions

Base Theme: Zen

Credits

This web design and development work was done by the following team at Image Works:

Misty Mallar – Information Architect, Interaction Designer & Project Manager
Shawn Smiley – Senior Software Engineer
Liem Khuu – Software Developer
Dana Hutchins – Creative Director & User Experience Designer
Larry Needle – Prototype Designer
Jake Frederick – Adobe AIR Prototype Developer
Heather Peters – Usability Testing
Clare Potter – Usability Testing

For more information on Image Works, please visit us at www.imagewks.com.

Additional contributions to the website design and development were made by GMRI staff including:

Sarah Morrisseau – VS Coordinator
Sarah Kirn – VS Manager
Petri Tuohimaa – VS Graphic Designer
Alan Lishness – GMRI Chief Innovation Officer
Alexa Dayton – VS Community Specialist

For more information on the Vital Signs project, please contact the Gulf of Maine Research Institute at http://vitalsignsme.org/contact.

Conclusion

We researched a number of open source CMS offerings before starting this project and without a doubt we can say that Drupal was and is the best platform for building this site. It easily supported our needs early in the project for rapid prototyping and radical system changes as we refined the project. The flexibility and customizability of the Drupal platform is one of its strongest features and a critical factor in the success of this website.

Finally, we’d like to thank everyone in the Drupal community. It's an obvious statement, but worth making again; without your support, initiative, ingenuity and hard work creating the exceptional web development resource that is Drupal, this project would never have been possible.

Drupal version: Drupal 6.x