Davis Applied Technology College Drupal Case Study

Last modified: April 13, 2009 - 22:11

Davis Applied Technology College

The Davis Applied Technology College (DATC), located in Kaysville, Utah, offers open-entry/open-exit, competency based programs on a year-round schedule. Our programs are broken up into the following schools: Business & Information, Construction & Apprenticeship, Health Professions, Manufacturing, Service Professions, and Transportation. For 30 years the DATC has been offering opportunities to individuals with difficult schedules or tight finances to further their education. Which is why our motto is "we change lives."

Web Team

With a medium-sized College we definitely had a lot of people willing to give feedback regarding the new web site. With that in mind we decided to put together a team of about 10 faculty and staff members that met regularly to discuss the progress and plan for the site. This team made the preparations for the site a lot smoother because we were able to look at it from all angles. It helped us feel more comfortable about the decisions that we were making along the way. In the end it definitely made the outcome more welcome.

The College hired a full-time "webmaster" to be the main person involved in the development of the site. His experience upon hiring him only involved the creation of static PHP and HTML web sites. He had no PHP programming experience, which says a lot for the great community and Drupal. His responsibilities were to investigate CMS options, build a robust web site, and then train the staff to manage the content. Development time took about a year with multiple different projects being thrown in during that time. Total dedicated time on the site was around 8-9 months (regular 40 hour weeks).

CMS Selection

The College's old web site was running on DotNetNuke and had a large number of problems. It was easy for us to convince the faculty and staff that DNN was not the way to go for the new web site. After months of research and installing most of the CMS's that we found we narrowed it down to a few. We had two or three meetings to decide which one was the best option for the College. The last meeting held we weighed out all of the advantages of each CMS—Drupal won by a few points due to the simple admin interface and, of course, for it's flexibility.

Shortly after we made the decision it was obvious that Drupal was the perfect candidate for us. We started browsing through the forums on drupal.org and in the modules section. We began to discover that the community behind Drupal was even larger and active than we originally thought. The main things that sold us on Drupal were the following:

  • Great community (both active and friendly)
  • Optional Commercial Support (Acquia)
  • Very Very Customizable! (realized along the way)
  • Multi-Site Set-up was a must (and with Drupal it was easy)
  • Backend/Administration was Simple yet robust
  • Huge repository of modules/plug-ins for Drupal 5.x

Hardware

When it was time to look into hardware for the new site it was obvious that a Linux-based OS was the way to go. Before the site design started we looked into getting a brand new server from Dell with SUSE 10 on it. Not sure of the exact specs of the server, but it definitely was capable of doing what we needed it to. We have our own server room with somewhere around 20+ servers so it wasn't a hard decision to make to just keep the server in-house.

Design

One thing that we checked on each of the CMS's that we tried was how easy it was to build templates/themes on each platform. Plone was ridiculous, mainly because of the Zope Framework that it is built on. Magnolia was next and it was easy, but after a few tests we ended up running into a few road blocks that were a little frustrating. Both Joomla and Drupal were a pretty close tie with Drupal winning in the end.

In the Drupal Theme world we narrowed down our options of themes down to three, and the Tech theme was the one that everyone liked.

Tech Theme (click for larger preview) DATC Theme (click for larger preview)

Here's a side-by-side of the old and new designs. 

OLD NEW

We went through probably 3 or 4 different revisions before settling on this one. The 2nd revision was pretty close to what we ended up using.

Development

The main thing that the web team was focused on for the new site was our Program Pages. That is the bulk of our site. Initially that's where we spent most of our time during development. Most of which was working on getting the node content to display properly. We had to display some of the node's cck fields in a block (Quick Facts) and the rest in the main content section. Once that part was functioning the rest was just getting the data input for each page.

Aside from the Program Pages the rest of the development time was spent doing the following:

  • Setting a new and improved job board using CCK, Contemplate,
  • Configuring magic_tabs in the navigation block to show menu trees applicable to the current logged in user
  • Integrating the web site into our LDAP server for easy authentication
  • Mapping LDAP Groups to Drupal Roles to make the integration more robust
  • Setting up a way for users to submit cases for fixes/issues on the site
  • Migrating all other content from the old site
  • Coordinating with a developer to develop a Module for Webform to feed into our CRM App
  • and much more...

Modules (worth mentioning)

  • Actions: used with Workflow/Workflow-ng to automate e-mail notifications of new and updated content.
  • Drupal Administration Menu: must have for backend management in Drupal.
  • Advanced Contact: A great module to take the contact form to the next level. One goal with the new site was to not include any e-mail addresses to keep spammers away. This module allowed us to use the contact.module to be redirected to different departments. The best part about the module is the pre-populate feature to make it easier for the end user.
  • CAPTCHA: Must have for any and all web sites with forms.
  • Content Construction Kit (CCK): Used in almost all of our content types to get all of the information necessary on the initial node creation step.
  • Click HeatMap: Not the quickest utility, but it is very cool to see where people are going on your site. Unfortunately we could only use this on the home page because of the slowness on the site when activated on each page. Makes sense though.
    (Click for a larger preview)
  • Computed Field: Not currently being used, but will be in the near future. It will be used to calculate total tuition cost based on the current hourly tuition cost. It will also be used to calculate all costs (tuition, books, etc.).
  • Content Templates (Contemplate): Life-saver on most of our custom content types. Did a great job at making the job and resume content types look pretty.
  • Diff: Used to keep track of different node revisions so they can be reverted back if necessary.
  • Editview: This module was a diamond in the rough when we found it! It can turn your table views into editable fields. Making changes to lots of information from one page can be priceless. We are using this to provide a page for our Financial Aid department so they can keep all of the numbers current.
  • Event: Great module for event management. We went back and forth between Calendar and Event and, as you can see, we went with Event module. Calendar had some cool stuff, but Event was easier for us to manage. The main use of the calendar was to manage events, so there you go!
  • External Links: We got multiple requests to somehow indicate which links were staying internal and which were going external. This module told Drupal to drop an icon next to each external link so the end user knew they were leaving the site.
  • FileField: This CCK module is used to allow the applicants to submit their Resumes and Cover Letters along with their application.
  • File Field Upload Limit: Allowed us to control the file size limits for the anonymous users.
  • Google Analytics: Gotta love Google's free analytics service. This module is great and allows great flexibility with the service.
  • Iconizer: Similar to the "External Links" module this one allowed us to add icons next to links that were PDFs, Docs, etc. Makes it easier on the end user to know what they're downloading before they click.
  • IMCE: Great module for image upload/management in TinyMCE. There are features that we would like to see it do, but not much we could do about that. It'd be nice to see a multiple upload feature that would then let you insert all of those images rather than one at a time. Overall a great module though, and the only one of it's kind.
  • Job Search: This module does a little more the name really says. You create the Job and Resume content type and tell the module where they are. A feature is then activated that adds a "Apply for this job" at the bottom of the job nodes. We had a unique situation in that we also have external companies contacting us with new jobs for future graduates. We have both an external and internal job board using views that displays the currently available jobs. Any employers that want to post jobs on their own can apply for an account so they can post them up to be approved by an administrator. This has been a very welcomed feature for the new web site.
  • Javascript Tools (JS Calendar): This module made date selection in Drupal a lot easier for our users. Instead of typing it in manually it allowed you to select the date on a pop-up calendar on the forms.
  • LDAP integration: Drupal wouldn't have worked out for us without this module. This most definitely was one of the deciding factors so we were happy to see that there was one that was updated. All authentication on our site goes through our LDAP server first, and then Drupal. Since 99% of our site users were going to be faculty, staff, or students it was easy to go with a service that would allow tight integration with usernames and passwords. The LDAP Groups integration with Drupal roles was also a life saver. We were able to utilize pre-configured LDAP groups and sync them with Drupal roles on the site. The only thing about the LDAP module is that the initial login for a user in LDAP is a little slow. Other than that the module is great and we can't really complain about something that works!
  • Login Destination: A simple module that allowed us to forward certain users to different parts of the site after they logged in.
  • Magic Tabs: We really liked this module when we got it up and running on the site. The set-up is a little more advanced users, but once you get used to it—its really easy. This module was used to combine different sections of our menu tree into a single block. The reason it's so magic is that when you click on the tabs it loads the other block using AJAX. No need to reload the entire page, which is very appealing to the user (it's also nice to the server as well).
  • Matrix Field: A light-weight module that allowed us to create CCK fields that look like tables in our content types. Here is an example on the resume form.
  • Menu Trails: A must have for any Drupal site. Here's a brief write-up on our Webmaster's personal blog.
  • Node Auto Term [NAT]: With all of the different Programs that we offer we wanted them to also have a Taxonomy Vocabulary that would sync up to each of the program_page nodes. This made it easy to associate different content across the site with different programs (i.e. jobs, news, etc.). This will also allow us to include content a "related content" block on the program pages to bring all of the content related to the different pages onto their respective page. This part is still being researched.
  • Node Profile: This will be used soon for instructors to create Instructor Bios on the site. Also looked at the bio module.
  • Meta tags: You want to get your pages recognized on Google? This module can definitely get you there. It will also integrate with the search.module when people search through your site. In the upcoming weeks the different Programs will be supplying us with keywords that people might use to search for their programs. It will make our programs more available to users no matter how familiar they are with the lingo of the program.
  • Path Redirect: Since our new site didn't follow any of the same links from our old site it's been pretty interesting to see how many links that people hit off Google and MS Live that take them to a 404 page. With Path Redirect we've been able to fix some of those important links so that the user gets to where they are wanting to go. Once Google and Live get the new Sitemaps in place this will not be necessary.
  • Prepopulate: Will be used to make it easy for instructors to create sub pages for their program pages.
  • Private Upload: Some files on our site are meant for certain eyes only. This module, which we just came across weeks ago, allows us to isolate private files into a private directory controlled by an htaccess file. This makes it impossible for a user to get to the file without the appropriate access control in Drupal.
  • Remove Non-viewable Menu Items: Wanna hide menu items from users that don't actually have access to view what's on the other end? This module does all of that. Light-weight... and very helpful.
  • Salesforce Webform Web-2-Lead Integration: This was the module that we had developed by a third-party developer. One of the big challenges during the development of the site was the requirement of integration with Customer Relationship Management (CRM) System. We looked around on d.o for modules that would do the trick and weren't able to find anything. We hired Obsidian Design to develop a Webform plug-in that would allow us to push the submissions to our CRM account upon submission of the form. This would allow us to utilize Webform's field validation, and also to take advantage of CAPTCHA control on the forms.
  • Scheduler: Some jobs that are posted on our job board have a closed date. This module allowed us to attach an end date to each job so that they get un-published from the site on a specified date.
  • Search config: This module enables more settings on the Search settings page so that you can tell Drupal what to include in search results for users. Works similar to "Restricted Search" module.
  • SMTP Authentication Support: This made Drupal mail be sent A LOT quicker.
  • Table Manager: We couldn't have done the program pages without this module. We weren't all that crazy over the way that the admin side of it works, but what it does do—it does very well! Each of our programs have a list of different tracks that can be taken with different courses for each. This module let us create this content in tables that could be managed by certain users. Users with the right permissions will see an edit/delete button next to the rows that they have access to change. Our original goal was to not have very many hard-coded tables on the site, and this module made that easy. It's very user friendly for the users that are editing the content, but the admin backend, as mentioned, isn't the best. Looks like it is being worked on though!
  • TinyMCE WYSIWYG Editor: Still not sure if this one's our favorite WYSIWYG Editor, but so far it's been pretty good. It's pretty light-weight and just works. It doesn't handle paste from Microsoft Word like we'd like it to, but we haven't had a ton of time to play with it.
  • Update Status: Must have for keeping modules up to date. Sometimes we wonder which of our modules are left out from this though. :(
  • Views: Not much needs to be said about this module other than the fact that we used it for a lot of things on the site. One specifically was on the Quick Facts blocks that displayed some quick info about the program. Using this block took a large chunk out of the main content area making it much more clean and easy to find. Our Webmaster also wrote about this solution on his personal blog.
  • Views Fast Search: Added to views tables for the end user to search through the query.
  • Webform: Must have for any forms on a Drupal site.
  • Workflow & Workflow-ng: Currently is only being used to notify HR when Resumes are submitted. Eventually will be used to control content revision approvals.
  • XML Sitemap: Wanna be present on Google? Use this module. It's going to take us a few months to get all of Google's search results updated for our new site. With Google's Webmaster accounts you can manage all of your XML files and tell them which links to remove from their database.

Home Page

A lot of our time during the development was on the home page of the site. We worked closely with the Marketing Team to make sure that we presented what we had to offer in the most simple and professional way possible. Our old web site. had a rotator image that would change on each reload. This, for the new site, wasn't going to be good enough. We looked into many different options and finally ended up going with a small javascript library called Smooth Slideshow. We had to hard-code it into the page-front.tpl.php file, and found it to be a pretty slick slideshow in the end. Everyone that saw it loved it. It's a good way to showcase different events and Programs here at the DATC. We've got another slideshow just under the main slideshow that showcases different programs using the same javascript library.

Custom Content Types (worth mentioning)

  • Board Book: This content type is a simple one with a Title field, and a Filefield for uploading PDFs. This was a quick and easy way for us create a basic system for uploading and sharing the Board Book with the Board Members from time to time.
  • Job (External): This content type is used for our external jobs that are submitted by our Entrepreneurial Division and from external employers.
  • Job (Internal): Similar to the one above but for internal jobs. Workflow is set-up to notify all Staff & Faculty members of new jobs.
  • News Item: Used for press releases and student of the month announcements. We added a node_reference field to link the news items up with Calendar items, which was a very handy feature.
  • Program Page: This was by far the most complex content type. Most of the compliments about the site are on these Program Pages that were a really nice upgrade from the ones from the old site.
  • Program Sub-Page: Still under development. This content type will be open for faculty to create within their program pages to supply additional information about their program.
  • Resume: Anonymous/Authenticated users can create their own resumes and apply for a job.

Conclusion

At this point we think that the best decision that we made was the decision to go with Drupal as the CMS for our site. In the end Drupal was able to meet and exceed our expectations. The College only had to pay one third-party developer to develop a module—all the rest came straight from the community. That says a lot about the Drupal Community. Great platform, great community, and easy customization. In the CMS war . . . Drupal wins!

Drupal 6 Upgrade Write-Up Coming Soon!

Super Casestudy

miesel - September 25, 2008 - 22:17

Das ist eine wunderbare Casestudy. Die Erklärung warum Drupal genutzt wurde, ist eine der simpelsten und einfachsten Erklärungen warum man diese System nutzen sollte.

"The College only had to pay one third-party developer to develop a module—all the rest came straight from the community. That says a lot about the Drupal Community."

... und das ist genau der Punkt bei dem sich viele andere Syteme sehr bemühen und alles für ihr System tun, bei Drupal habe ich irgendwie doch immer das Gefühl, als das bei anderen Systemen, das auch alles funktioniert wie versprochen (bzw. wie in den Moduledokumentationen beschrieben wurde).

Tolle Seit, tolle Casestudy ... all thumbs up!!

drupalgermany.com - misgin.com - meyermisginmedia.com
Alexander Misgin

Wonderfully detailed write

venkat-rk - September 26, 2008 - 06:20

Wonderfully detailed write up. Thanks to whoever documented all of this. This is a far quicker way to learn about which module to choose for a specific purpose than wading through a few thousand modules. Thank you again.
----
Previously user venkat-rk.

Hi event calendar problem

bharanikumariyerphp - October 12, 2008 - 11:47

Hi in your event section event next week navigation not working,

this is the first time am checking your site, when i reache this link i meet the event calendar, but the calendar look is not good, i thing

there ajax not working , can check it out this link,

i used the mozhila 3 , this is the link http://www.datc.edu/event/2008

this is the pnly one issue , then site is excelent look and file and navigation and all..................

Awesome write up

Lynn Bankockor - October 17, 2008 - 12:59

Awesome write up

Front page shouldn't depend so much on javascript

HansBKK - October 17, 2008 - 13:01

I surf with js turned off by default, and your home page looks very bad that way, poor first impression.

I'm not saying don't do the js-based image rotating, but find a way to do it so people with JS (and even images) turned off get a coherent, meaningful and reasonably attractive presentation of your main messages.

My 2 cents, take it for what it's worth. . .

Thanks for your feedback.

amariotti - October 20, 2008 - 20:04

Thanks for your feedback. I've never had anyone bring up something like that. I will take a look at it though. I could see possible just leaving a single image and caption showing if the user does not have JS enabled. I'll post here my findings.

Or in the meantime at least

HansBKK - October 21, 2008 - 04:59

Or in the meantime at least throw up a warning "this site requires javascript"

Thank you for this!

2ndmile - November 18, 2008 - 14:25

Great write-up.

I work for a small university in Kentucky. I inherited a 3rd generation roll-your-own CMS and I have been planning for a move to Drupal for some time. Thank you so much for the module list. Great info, very helpful.

One thing I would like to hear more about is how you set up the admin of the different sections by the different departments. Do you have one user role that can edit all the pages or can each department only edit the pages from their department?

I am sure I will be asking more questions as we begin our transition this winter.

One thing I would like to

amariotti - December 11, 2008 - 15:35

One thing I would like to hear more about is how you set up the admin of the different sections by the different departments. Do you have one user role that can edit all the pages or can each department only edit the pages from their department?

Our Instructional Systems Design department has control over all program-related content on the site. This includes all programs pages, and tables therein. Since we're small that department consists of only a few, but enough to keep everything up to date. We've also given them access to create new program pages when new programs are approved and ready for enrollment.

The Marketing Team has access to editing all content, including the program-related content. Sometimes there will be changes made to our brochures and pamphlets and they will need to jump in and make minor changes. Marketing also has the ability to add images and videos to each program page to add more life to the programs. We've been discussing how we're going to go about organizing something like this for a while, but haven't had the time to pay too much attention to it.

There are pages on the site that certain users needed to control. For example, the woman involved in the Testing Center needed access to her Testing Center page on the site. That was simply done by adding her as the author and giving her role the permission to "edit own page." It's worked out nicely thus far, we'll see how it plays out down the road.

Aside from what I mentioned there are a few other little ones to add content to the site (i.e. events, news, etc.). Does this answer your question?

 
 

Drupal is a registered trademark of Dries Buytaert.