Bellevue College Web Presence

Bellevue College is the third largest institution of higher education in the state of Washington and it’s web presence has more than 120 official websites




Overview

This is a story of a collection of iterations on multiple products over the span of 2.5 years that affected the entire college web presence by

  • Embracing a culture of iterative design that can adapt to user research and changing priorities
  • Integrating services of historically disconnected systems to improve findability of content and services
  • Adopting a content management system that balanced the needs of the college and the needs of academic departments
  • Creating centralized assets and patterns to create a consistent look and feel across the entire web presence (affecting public facing websites and web applications)
  • Adopting a mobile-first responsive web design mentality (including elements of performance) before CSS frameworks and other colleges were doing it (I’m still proud of this)
  • Creating clarity over the purpose of the college’s main website



My Role

I articulated most of the overarching vision and led most of the efforts I’ll mention below. I wore many hats, including lead designer, front-end developer and a bit of product manager.


PROBLEM

There were a series of problems that we were trying to solve.  On a high-level, all web-based services were disconnected, but our process worked well enough as to not create a noticeable impact on services provided.

  • Over 120 public-facing websites (with over 6,700 web pages) were being managed as static websites without the help of a content management system. This made making global changes impractical, at best, and was cumbersome for content managers to maintain.
  • All web applications and web-based services were disconnected from each other.
  • We wanted to adopt a ‘best tool for the job’ approach to engineering, but were concerned that doing so would force us to adopt a series of subdomains for different products and websites which would negatively affect SEO and URL naming conventions.



The Team

Team members included a web specialist lead (me), front-end developer, web specialist, a software developer and a systems engineer.  We were a group of passionate peers coming together to solve problems while holding each other accountable to make a better service.  Although I was the face the most of what was delivered, there was leadership happening across the entire team.  The underlying technology that made this possible would not have happened without the innovation, collaboration and leadership from our systems engineer.


CMS Concerns

We knew we needed a content management system, but we had some concerns about how to proceed:

  • We were a Microsoft development shop. The CMS options were expensive and bloated. We wanted the flexibility to make changes to our solution without having to hire consultants to do the work.
  • We were concerned about the transition to a CMS. Most systems would require us to go all-or-nothing and stage all of the content before flipping the switch. This would require us to maintain a large quantity of content for an extended period of time.
  • We also needed to make sure that whatever option we chose balanced the needs of academic department autonomy with the college’s needs to oversee the overall effectiveness of the web presence. Many solutions assumed a more centralized and coordinated approach to content management, which wasn’t the reality at Bellevue College. To all stakeholders, the option needed to feel like a slam-dunk decision, otherwise the entire project was at risk of failure.



Server-side Flexibility

One day our systems engineer came to me and asked me about some of the issues I mentioned above.  During the conversation, he mentioned that he thought he could create an environment that could seamlessly display content from different web servers as sub directories of the www.bellevuecollege.edu subdomain.  I asked him if anybody had done this this before. He said he didn’t think so.  But if he could, this would eliminate two of the bullets I mentioned above.  We wouldn’t be limited by the Microsoft stack and we could phase content migration without having to stage all the content ahead of time.

He ran a proof of concept and he got approval to move forward. He’s amazing and the rest is history.



Pilot CMS Program

Now that we knew we had some options from the server-side.  We started experimenting with open source CMS solutions. Another peer suggested WordPress. I wasn’t convinced. I wanted to look into Drupal.  Our department ended up looking at both options during the pilot.  WordPress seemed like something that could lend itself well for department websites.  We experimented with a few dozen websites and learned a lot through the process and realized we could likely do the entire website in WordPress using single-site solution.

As we started looking at these options we also started noticing that WordPress could be a natural solution for hosting unofficial websites: faculty websites as a well as student organization websites.


Mobile First

bc website breakpointsThe design for the home page was implemented using concepts from Luke W’s Mobile-First Responsive Design.  I took careful consideration in making the design respond based on the content rather than pre-canned breakpoints.   We also paid close attention to site performance.


Improved Performance

We made several efforts to make a noticeable improvement to performance.  Much of this work was with the help of our Systems Engineer.

  • We hosted all assets from a cookieless domain. This allows browsers to download and and those items faster and keep them in cache longer, while at the same time increasing the amount of http requests that web browsers could do simultaneously.
  • CSS and JS assets are concatenated and compressed to reduce http requests and reduce download speeds.   (although some of this went away since I left the college)
  • All WordPress sites are hosted from a NGINX server and paid close attention to caching to reduce database calls.

When we launched the home page in WordPress, it loaded faster than when it was static site hosted in our old IIS servers.  The credit on improving performance goes almost entirely to our systems engineer. My only role in this was to encourage him and to continue selling his work as a valuable investment.  As you may know, you can spend a lot of time and resources at improving website performance.



User Research

Conducted first-click analysis and tested a variation of the main college navigation against the current navigation before making changes in the navigation. I did other research in the process and while working at the college.  You may also want to check out my blog post on user research in higher education.



Realigned Website Purpose

We began thinking of the Bellevue College main website as a living document of the Course Catalog.  Essentially if the Course Catalog is the print representation of the offerings and services the college provides, then the college website is the same for the web.  There is no need for a student or community member to know what the ‘Course Catalog’ is to find information they need.   I ended up making a proposal to make the switch, I took it to Educational Services Cabinet, which is the entire cabinet of the college president and all all the heads of the academic divisions.   This was a big change, mainly in mentality of how the college thought of a key document that every college and university publishes for legal (in the state of WA) and accreditation purposes.

So we mapped out the content we were publishing via the main website and compared it with the content we published in the course catalog.  There was already a lot of overlap.  A coworker conducted the content inventory, I assigned offices that would need to be content owners of particular content.  When we executed the changes, we had to adjust the second-level navigation of a portion of areas.   But we knew we needed to make larger changes in the college-wide navigation in the future.

This idea started after a committee I was part of was looking into not printing the Course Catalog, then we got a strong hunch about students not know the document by name, and if they did, they likely didn’t know all the content it contained.  We talked to multiple support offices and found similar findings.


Flattened site structure

I decided to flatten the entire site hierarchy of the college web presence. By this, I mean, we took every academic division website and broke it up into multiple websites. One for each academic department and one for the academic division. There were a few benefits on this change:

  • It’s easier to publish and type a shorter URL: bellevuecollege.edu/math/ vs. www.bellevuecollege.edu/sciencedivision/math/
  • If a department moved between divisions, we didn’t need to change the URL
  • It would improve search engine optimization of all academic departments because the sites were now all directly off the root of the site.
  • It was easier to assign permissions and keep track of who had access to each site.


Site Consistency

We came up with a default site hierarchy for all the most common types of website: academic departments, academic divisions and service departments. This consistency would make it easier for students when visiting multiple websites in finding the information they need in a consistent structure.   We tested this structure during the pilot program and made modifications in the process.


Removed Subdomains

Now that we had a content management system and the flexibility to host any site as part of www.bellevuecollege.edu, we decided to remove all subdomains for public facing websites and applications (with a few exceptions due to ROI).    There were two reasons for this:

  • Improve SEO
  • Consistency with other sites

The first site we migrated from a subdomain was the Continuing Education website.  We didn’t change the site structure or the design during this step.  After about 2 months all the keywords the department was tracking improved.  One moved to the top search results, others to the top 3 search results and another key phrase moved from the second page to the first page of search results.

This solidified that it was important to move content to the main domain and make it content rich.  Every site would then help the rest of the domain at being a dominant authority on higher education and the services and subjects we offered.


Improved SEO

I paid close attention to Search Engine Optimization as I made decisions on site hierarchy and theme development.   Here are some highlights:

  • Moved all sites into the bellevuecollege.edu domain name (for example, a site living at sitename.bellevuecollege.edu moved to bellevuecollege.edu/sitename). This change allowed sites to take advantage of the SEO rankings of the www.bellevuecollege.edu domain name to elevate their own rankings
  • Flattening site site structure so department content moved to a root directory. Example: a site that lived at www.bellevuecollege.edu/parent/departmentname moved to www.bellevuecollege.edu/departmentname.  This change elevated the academic departments content to search engines.
  • Improved WordPress’ title tag generation. All department home pages include the site name first, then the name of the college.  All sub pages include the title of the page, then the title of the site.  The themes also have a title tag override, so the website manager (or the web office) could improve the title tag on a case-by-case basis.
  • Improved HTML structure of all websites. Ensuring the templates displayed the content first (and navigation later) as well as ensuring sites used headings, semantic and accessible markup.
  • Improved site speed and mobile friendliness.


Mayflower Theme

The mayflower theme was the custom wordpress theme we developed.  We ended up going with a single theme with two major variations.  One variation for the ‘home site’ look and feel, and one for department and academic websites.   This allowed us to simplify the development process and just flip a switch on the theme to make it look and feel like a site that was part of the Bellevue College main website.

There were a lot of team members that worked on the theme.  I set up the expectations on what I needed the theme to do and handle, I designed the general look and feel of both types of sites. The front end developer (who also had design chops) also helped out on the design of the department site templates and he was the point person for implanting the design.  I designed and coded the Bellevue College home page.  In addition, I designed and coded all the global elements (see “Globals”, below).


Globals

“Globals” was an initiative to centralize reusable content.  This includes content that would normally be part of a theme, but because we wanted web applications to share the look and feel, some of this style and images needed to be centralized elsewhere.  So, we centralized the basic typography (in CSS) some design patterns (which we planned to grow as a pattern library) and header and footers.  This would allow us to have a web application hosted in a Microsoft IIS server and the home page of the college display the same header.


Emergency Notifications

If a closure or an emergency is to happen, all employees and students receive an e-mail. If individuals have signed up for text messages, they will also receive a text message.  In addition all official and department pages display the emergency message and link to the Rave Alerts system for more information.  Although the emergency alert system we used didn’t have a direct system to do this, I came up with a method to get this to work globally on the website and just needed to do a quick change in the college procedure to have this work.


Integrations with Classes

A separate product I was working at the same time, was the Classes product. We designed the product to not only list classes and course descriptions in html but also provided an output in JSON.  We took advantage of this and now all academic department sites were able to display accurate course listings and descriptions.    Before this change, it wasn’t allowed because there had been a handful occasions where department websites were listing inaccurate course information, which was a risk to our accreditation.   This was a big deal for academic departments and an huge UX improvement to students or prospective students who wanted to see the courses offered by an academic department and not be able to see a list without leaving the page. In addition, unlike other academic institutions, this output handles not only the current listing of courses and descriptions but also lists changes for the upcoming academic year.  Learn more about the Classes Product.


Unofficial Websites

The college web presence doesn’t just have official college content.  We hosted faculty personal websites as well as student-run websites.  Since this content isn’t official college content, we needed to create a space where this content could be published.  Like all other web content, I mentioned above, it was managed as static websites in HTML.    The primary goals for these two products were to:

  • Moved the sites to a content management system so sites were easier to maintain
  • Make sure that they did not look or feel like official college websites
  • Allow college administrators to easily remove inappropriate content (if necessary) or even turn off sites.

The two projects were:

Faculty Commons: which allows faculty to create websites on the fly and set up the management structure to be owned by a Faculty-Run office called, well, the Faculty Commons. This is a Multi-site version of WordPress using BuddyPress to allow for some online collaboration.  I led this effort and did most of the design work and implementation with the exception of a few UI elements.

Student Web: This is another multisite implementation of WordPress. Much of this effort was originally led by our Web Specialist (who I led) and some of the graphic design work was done by one of my interns. Once the Web Specialist changed jobs, I took on the leadership on this project.


Iterations

There were many moving parts and many dependencies between these projects.  Folks, like myself were not just working on one product at a time.  So, we launched pieces when they were ready.   This also allowed us to make small tweaks to the website in preparation to the larger changes this way the changes were less noticeable.


Screenshots



Style & Color


Tools used

  • Design methods: analytics (google analytics, netInsight, google Webmaster tools, SiteImprove), content inventory, first-click analysis, surveys, focus groups, usability testing, road maps, SWOT analysis, competitive analysis,  stakeholder interviews, sketching, whiteboarding, taxonomies, navigation structure
  • Design tools: pen/paper, whiteboards, balsamiq, fireworks, illustrator, photoshop
  • Productivity tools: Excel, Word, SharePoint, PowerPoint
  • Dev tools: Sublime Text, Dreamweaver, Firebug



Sketches



Iterative Design

In 2009 I adopted iterative design practices on the Bellevue College website.   This change completely removed design-by-committee and slow approval processes on the main website while, at the same time allowed the website to take on needed changes over time.  Adjustments included: larger wider design, modular design, template (back end) improvements, tweak to global navigation, mobile-first responsive design. Thought the process, small UI changes were made to make the next change less noticeable to users so they didn’t feel like the website was redesigned.


Website over time

By the time I left the college, efforts were underway to migrate the entire homesite to the mobile-first WordPress theme I had designed.