UTCS.org -- A Drupal case study

Malcolm Hooper and I recently launched a new Web site for UTCS, the daycare our daughters attend.  The school’s board of directors wanted to foster community among the parents, move paper-based administrative tasks online while maintaining security and privacy of the information being published.  Since I was volunteering my development time, I wanted to make this as turn-key as possible and minimize any custom development.

Sounds like a job for Drupal!

Requirements:

1. Public-facing site was to remain as-is.
2. The new site should promote parent interaction and provide updates about school happenings.
3. Parents, teachers and administration would be granted usernames and passwords to access the community site.
4. Parents can view some information about other parents and students such as phone numbers, email addresses and which days the children attend school.  Administrators can view all parent and student information.
5. Parents should be able to edit theirs or their children’s information.  Administrators can edit anyone’s information.
6. Any photos posted to the site need to be behind the username/password curtain for privacy reasons.
7. Using the site should not place any additional burden on the school administration.  Ease of use is paramount.

What we did – the general strategy:

Many people and businesses want to “build community" with their Web sites – it’s so very Web 2.0.  But few of them know exactly what building community means.  The way I see it, community comes about when there is two-way communication.  Companies used to build brochure Web sites.  That was great to let visitors know your hours of operation and something about your business.  But to build community, you need to empower your visitors to add content and feel a sense of ownership in the Web site.  For this site, that meant setting up a discussion forum and classroom blogs with comments.  It also meant getting parent volunteers in each classroom to add content to the site and answer questions in the forum.  Nothing defeats a community site faster than a forum with no activity.

To maintain privacy in the community side of the site, a username and password is required for access.  New parents can request a Web site account, but all new accounts have to be approved by a school administrator.

Previously, student information was kept in an Excel spreadsheet – several of them, actually – and administrators had to collate these tables each year to build a  student directory.  One goal of the new site was to move this effort online, hopefully removing the need for a paper-based directory.  CCK and Views were used to build two custom content types for this effort: one for student information and a second for parent information.

By setting the download method to “private” in Drupal’s file system configuration page, we keep anything that’s uploaded from being accessible publically.  However, this prevents us from aggregating our CSS and JavaScript files.

Finally, a documents section was suggested to allow parents quick access to various documents such as medical release forms.

What we did – the details:

If there’s one place I seem to lose hours and hours of development time its fiddling with the details of a site’s theme.  Drupal’s admitted weakness is a lack of quality, good-looking themes.  Fortunately Acquia is working to correct that with their release of Acquia Marina and Acquia Slate for free download.  We went with Marina.

To build a parent discussion board, we used Drupal’s built-in Forums module.  We also added a second forum for board of directors discussions and limited access to it with Forum Access.  An “Active Forum Topics” and “Recent Comments” block was added to the UTCS front page to keep parents and staff abreast on the latest conversations, hopefully drawing visitors deeper into the site.   (Note: there is a bug which allows non-board members to view board forum topics in the Active Forum Topics block.  I haven’t looked into it yet, but I’m hoping it is downstream of the fact that Forum Access is still in beta.)

Drupal’s roles and permission system is extensive and we leveraged that to allow different views of the site based on who was logged in.  Several roles were established to give us find-grained control over who could do what.  Anonymous users would see the existing site while authenticated users get a richer experience.

Giving each classroom at the school a blog would allow parents to stay up-to-date on what’s happening.  Drupal’s baked-in blog tool creates a blog for each user, which is not what we wanted.  CCK and Views were used to build a custom blog content type and a taxonomy vocabulary was created using the names of the classrooms, making it easy for users to find related content for a given classroom.

CCK and Views were also used to build several custom content types and the pages and blocks needed to display them.  Pages with sensitive information, such as a student’s medical history,  are only accessible to users with the “school administrators” role.  More limited student information, such as their home phone number, is viewable by any authenticated user.  Student and parent and parent directories were built using Views with the classroom as an argument, letting us filter the directory for a given class as well as allowing easy sorting of the data by the site visitor.  Content Profile allows us to use the parent info as their user profile. 

General and critical news items – with critical being made sticky by default – allow administrators to make updates to the community.  The most recent five of these are displayed on the site’s home page.

To make the site as easy to use for the teachers and administration, we used FCKeditor for inputting content.  ImageAPI, ImageCache, and ImageField were used to handle adding photos or illustrations to entries and Lightbox2 makes them all look pretty when displayed.  Barry Schwartz found that offering too many choices can make a site more difficult to use.  In keeping with that we limited the formatting options available with FCKeditor and only allow images to be ordered using Drupal’s nifty drag-and-drop interface to adjust weights.  The display of the images is handled by the theme layer so the user doesn’t have to worry about sizing images such that text flows around it properly.  Allowing users to save a draft of their work – a list of which appears when that user’s sidebar – helps when typing longer entries.

The Date and Signup modules allow users with the appropriate permissions to create events, such as upcoming school closures or field trips.  For weekend picnics or after-school events, registered users can sign up for events letting event organizers know how many people to expect.

Finally, CAPTCHA keeps the spammers at bay and the Administration Menu makes life easy for those of us that have to do a lot of configuration work.

Conclusion

While there are still a few bugs details to fix, the site has been well received and, more importantly, is making the jobs of the school administrators much easier by centralizing several tasks.  All of this was built using off-the-shelf Drupal modules with no custom coding, except for a few pieces of JavaScript in the theme layer.  Drupal makes a click-to-build website possible.