Written by Joyce Peralta
Web Analyst, McGill IT Services

When I arrived at McGill 3 years ago, I was happy to discover that at long last I would be working at a university with a centrally-supported open-source CMS!  At other universities I had worked at previously, I had unsuccessfully advocated for the adoption of an open source CMS system, twice. As it turned out, finally getting to work with the CMS I had always wished for was everything I had hoped it would be, and then some – and by ‘and then some’ I mean, some things that were better than I had expected, as well as some things that were, well, more challenging (but we’ll get to that later).

Once upon a website

One of things that has always most impressed me about McGill’s web space is the surprising number of sites that its CMS can support. When I delivered my presentation at #PSEWEB 2018, the number had grown to over 850 websites, including all of McGill’s top-level websites. I believe the consistent use of McGill’s CMS can be explained in part by the history of its web publishing service.

Similar to other university sites at that time, in 1997 McGill’s web network was a collection of simply constructed HTML websites. These sites were managed by staff, faculty or students in individual departments who had volunteered to take on the work in addition to their usual responsibilities, often with little or no supervision. Not surprisingly the structure, look and feel and general quality of web pages was a little inconsistent.

McGill’s webpages eventually began to have a more standardized look-and-feel after the introduction of a homegrown CMS (a content management system developed in-house). By 2004, a good number of McGill’s sites were being powered by this system, originally developed by a small team then known as the Web Communications Group, later renamed the Web Services Group.

By 2009, the homegrown CMS was firmly established as the tool for building websites at McGill, although the team knew it would need to be replaced with a better CMS. In contrast, my experience at the other universities during this time was quite a bit different. In my experience, in the early to mid 2000s sites were being migrated out of the CMS and into Dreamweaver templates. From my conversations with other web professionals at other institutions, this seemed to be a common practice at many universities during this time. This meant many universities were moving back towards stand-alone html sites instead of sites being housed on a common system.

But at McGill, sites continued to be powered by the centrally-supported CMS. When it came time to replace the homegrown system, Drupal was chosen as the replacement platform. By 2012, most of the sites had been migrated onto the new Drupal system. Since then, the system has been migrated from the original Drupal 6 platform into Drupal 7 and plans are underway to upgrade to the current version of Drupal, Drupal 8. A Web Evolution project also kicked off earlier this year that will see a renewal of our top-level websites as well as our web services. Which brings us to where we’re at today…

Where we’re at today

By the numbers

• 850+ websites powered by McGill’s centrally supported CMS
• An average of 8-10 million pageviews per month
• 115^th most popular website in Canada (as reported by Alexa Rank)
• 1,700 departmental site managers and editors

The platform on which these sites are built, our Drupal-powered CMS, is developed and maintained by a team of 10 people – our team manager, 6 developers and 3 support staff. We’ve been an Agile team for about 8 years and currently complete our work in 2-week iteration sprints. Our CMS system is further supported by our extended IT Communications team that includes trainers and writers. We also have a close working relationship with the Digital Communications team in Communications and External Relations (CER) who provide strategic guidance, brand guidelines and resources, and policies.

Technical benefits of our in-house development team

Keeping a close eye on the health of our architecture and infrastructure

The additional teams who maintain our servers and infrastructure are our colleagues in IT Services. This allows us to closely participate in the management of these systems. When changes or upgrades are needed, we are able to collaborate with them on decisions that need to be made. And when something goes wrong, getting the information we need to assess the situation can be as easy as riding the elevator to another floor.

Wonderful integrations

From a technical perspective, one of the most important accomplishments of McGill’s CMS is the number of integrations with other campus-supported systems.

Integrations alleviate the need for site managers to manually update information by pulling information dynamically from other systems on campus where the information is already stored and kept up-to-date. Having begun my career as a faculty secretary in the early 2000s, I know very well that keeping information on websites current is one of the biggest challenges our site managers face. I remember the experience of having to manually update course information year-after-year and the amount of effort it took. Having updates dynamically pushed to websites can be a huge timesaver.

While it might not be unusual for university sites to have these types of integrations, I believe it is unique to have so many of them, implemented at this level of complexity in such a large web network.
Here’s a list of some of the key integrations:

• Banner (Oracle-based ERP)
  • Course calendar
  • Class schedule
  • User profiles
  • Campus building data
• Documentum (uploaded documents)
• Destiny One (non-credit registration)
• External RSS
• Twitter blocks
• Facebook and Linked In campaign trackers
• Course data exposed to external services (APIs)
• Public course Calendar
• Staff directory
• Campus org chart
• Staff profile pages
• Channels news and events

Support benefits of our development team

UX testing

In addition to providing site management advice and training to departments, for past 2 years, we’ve also guided site managers in conducting UX testing exercises with their audience members. In doing this, we’ve begun to amass a pool of data from the various departments across campus, and we’ve started to assess the combined results as a whole. The combined analysis is providing general high-level guidelines for smaller site projects.

Here is a list of some of our UX testing tools and services:

• Usability testing
• Tree testing
• Focus group workshops – card sorting exercises
• User journey mapping (initiatives currently underway as part of our home page redesign project)

Our developers are encouraged to participate in or observe in UX testing exercises. An experience that allows them to gain a better understanding of the audience perspective and the characteristics of our audience members.

Documentation and communications developed in-house

Each time we complete one of our two-week sprints we release updates and new features. These updates need to be communicated to our site managers and editors through knowledge base updates, articles, and email announcements that are generated by our team, with additional support from our technical writers.
Keeping on top of communicating news and announcements about our updates to our users usually results in 4 or more news articles a month, a list of announcements in our email newsletter, as well as regular updates to the 100+ how-to articles in our Knowledge Base.

Training team

McGill’s IT Services training team offers 3 levels of training courses for people who use our CMS. Each course is offered twice a month.

Since the migration into Drupal was completed in 2012, these courses have seen over 4,000 registrants. In the past year, 600 registrants have attended these courses.

We meet on a monthly basis with our IT Trainers to keep them in the loop on information about changes and new features to share with course attendees.

Relationship with the WMS community, or the ‘human’ side of development

The biggest benefit of having an in-house development team for our open-source CMS is the close working relationship we have with our site managers, editors and members of our general audience. Our developers regularly participate in and attend user testing sessions as well as presentations and meeting. The largest of these events is our community presentations which happen a twice or year. These events usually reach maximum capacity – a large segment of our site managers and editors coming out to meet our team and hear about our high-profile recent updates.

Shaking hands with the developer

I’ve come to appreciate that there are many benefits to having a web team with developers and communicators working closely side-by-side, but there are also many challenges. If you work on a university web team in either a communications and marketing department or an IT department, you’re probably well-aware of these challenges.

But at the end of the day, if you can identify common goals, and a way to work together to make those goals happen, the outcome should be a better (and friendlier) web network for everyone.