Purdue Templates

About

The Purdue web templates have been a product that the Purdue Office Marketing and Media (MM) has provided to the University since the late 2000s. After development, MM makes the HTML, CSS, and JS available for download so that other developers on campus can implement them in their own systems. A separate service provided by MM includes a CMS implementation of the templates within the centrally supported CMS, Cascade Server.

When I joined the team 2014, they were in the midst of implementing a new version that most notably included a new responsive design using Bootstrap 3's grid system. At this point, development was mostly complete, and my initial responsibilities included assisting in migrating sites to the new templates.

I didn't play a more prominent role in their development until the next update.

My Contributions

2015 Template Updates

Since the release of the updated templates in 2014, our team was gathering feedback about both the base web-templates and our CMS implementation. Using the feedback, I, the only web developer on the team at the time, made the following updates that were released a year after the last release.

Implementing SASS

In an effort to improve readability and solidify the Purdue brand, the header and footer were redesigned along with other elements on pre-built pages.

While making these updates, it became clear that current and future maintenance would be time-consuming. The 2014 version of the templates, used a single, vanilla CSS file that was difficult to navigate. To improve separation and decrease maintenance time, I divided our central CSS file into multiple SCSS files.

Along the way, I implemented variables and mixins where appropriate to decrease duplication of styles.

Using these methods, I was not only able to decrease maintenance time, but also reduce the size of our final CSS file by ~60%.

Centralizing Events

A common request we received from clients was the ability to list events they were sponsoring; however, we didn't necessarily have components styled for this use case. While our design team was concerned with how users would interact with an events feed, I wanted to ensure that our campus events weren't completely separated site-by-site.

I independently reached out to Purdue's Calendar Office to understand how their current calendar system could assist us. After being granted access to the system, I discovered it had the ability to generate an API endpoint that listed events based on given parameters. Using these endpoints, I was able to setup our events feed page to pull from the central calendar system.

The events feed was created using server-side PHP rather than client-side JS. This decision was made in an effort to improve progressive enhancement by having the feed independent of browser version and whether JS was enabled.

Since its creation, multiple groups at the University have moved from their own, separate calendaring system into the shared, central system.

Improved CMS User Interface (UI) and Documentation

Perhaps the most significant improvement to the Purdue templates in 2015 was the UI within our CMS. In 2014, the UI consisted of multiple WYSIWYGs to edit content. The problem with this approach is that many elements within the templates called for customized class names or markup that were not easy to recreate within a WYSIWYG. A client would initially receive a working version but would find it difficult to update without removing those needed attributes.

In an effort to fix this issue, I independently sought out advanced training within our CMS, Cascade Server. In the end, I was able to create an interface that only needed text input rather than HTML. After the interface was completed, I also created documentation about the interface that clients could reference later. This documentation included:

• step-by-step directions for common edits on a site
• screenshots showing expected views and locations of referenced controls
• general explanations for concepts such as how Cascade interacts with Purdue servers, SEO, and best practices

The new user interface and documentation resulted in decreasing the amount of support needed of our team.

Adding Gulp.js

Originally, SASS was implemented using using Koala, a GUI application that can compile SASS. While this made jumping into SASS much easier, I still wasn't receiving the full flexibility and benefits of a task runner.

In order to further improve our development workflow, to took it upon myself to learn and implement GulpJS. During this training, I decided to start simple and implement GulpJS to handle the following tasks:

• HTML templating — most sites we built were implemented into a CMS, so I used a simple library that allowed including HTML files. This allowed the team to create small snippets for various elements used throughout a site
• SASS compiling & minification — compiling our SASS files within the task runner allowed us to have more customization in how our files output and automate other features, such as autoprefixing
• live reload — this tool was one I didn't know I needed. Having GulpJS watch your files and reload a page when it notices a change is a huge time-saver.

Each of these tasks would run dependent on the environment they were built for. For example, minification of CSS would only occur if it was building for the production environment.

Implementing Git + Github

While multiple issues were addressed with the 2015 updates, most of these fixes affected our immediate team and end-users of the CMS; however, a complaint we often received came from other developers on campus.

Most template updates we receive come periodically and in large chunks. By the time I finish implementing these updates, it feels like there is another batch to implement.

Often we'd receive a request to provide a preliminary version of the update, so they could start before our upcoming release; however, this meant that we would need to manually track any changes made afterwards.

After training myself in using Git and Github on the Boiler Life site, I believed it to be the solution to this problem. With Git, there would be no need to manually track changes, and with GitHub we could easily communicate upcoming releases. Other benefits included:

• easier developer collaboration within our own team
• feature requests or issue submissions
• more simple external developer contributions

Throwing our code on GitHub wasn't enough though. We needed a set of standards so that we understood how changes would be developed and how they would be batched into a release. The workflow I decided was best for our situation was one coined "Gitflow" and first outlined by Vincent Driessen.

Using this workflow, I documented our branch naming conventions and how the branches interact.

Since it's implementation, we've been able to successfully implement multiple minor updates/patches and easily communicate them to the rest of campus.