Journey to an Accessible, Streamlined Campus Theme: Reference Guide

Back to the Presentation Resources Page

Lessons Learned: General Process

  • Include a trained project manager to help keep group on task and focused on key goals

  • Small baby steps are essential: don't try to bite off a complete redesign all at once

    • Start with the required components, then worry about other parts later on

  • Keep theme committee small, but do survey whole organization and keep all extremes in mind

    • Know your longest unit names, when considering site title space

    • Know if you have outside partnerships and other special use cases

  • Get leadership to clearly identify your constraints: colors, fonts, logo requirements, etc.

Lessons Learned: Theme Policy

While policy is the domain of campus leadership, the following can be kept in mind and passed on to leadership for consideration:

  • The key to new theme success is willing acceptance by as many units as possible

    • Even with strong policies in place, units will delay or avoid a new theme if they see it negatively impacting their image

  • The key to willing acceptance is a theme that makes units look good and feel unique

    • Unit branding is more important to unit leadership than university/institute branding

    • Win units over with a small theme footprint - dictate less, and offer as much flexibility as possible

    • Offer choices wherever possible - even choices between just two options

  • Clearly word the written policy and technical specs to avoid confusion

    • Clearly identify what is required and what is only recommendation

    • Identify when the theme does and doesn't need to be used

  • Provide a theming website what is built with the theme and offers well written documentation, style guides, and sample pages

Technical Lessons: Theme Structure

Build modularly, and assume that anything and everything might need to be changed on a per-site basis

  • Start with a static HTML or simple PHP website with no extra toolkits or libraries installed

    • JavaScript libraries (like jQuery) can cause clashes when applying theme to specific web content systems or applications that also use those libraries.  (pure Javascript is your friend)

  • Build mobile first to simplify and minimize your CSS rules

    • Minimize breakpoints if you can - if possible just one

  • Once you have your core design down, then try applying it to a content system, and always either create a new theme, or use a bare-bones theme base (don't build off of a ready-to-use theme package)

Technical Lessons: Managing Multiple Implementations

On a Ubuntu Linux server, I created a GT3 theme master workspace with these key components:

  • Core - key files needed for a minimal but complete implementation of the theme (e.g. for static HTML or simple PHP applications)

    • CSS, JavaScript, Images, Core HTML/PHP Code

  • Stubs - skeletal frameworks for content system or application implementations (e.g. theme packages).  This section includes custom CSS and JavaScript needed for the specific application.

  • Build Script - takes the stubs and the core files and merges them, producing ready-to-use implementations. The script supports several automation concepts:

    • 'makefiles' to indicate where core files should be copied to in the final package

    • token replacement with specific code and configuration file types

    The build script also packages them up into GZIP or ZIP archive files and copies them into a repository for public access, and also pushes them to my development sites on the same server.