The Unfulfilled Promise of CSS at Universities

I made a suggestion at a meeting the other day that was met with “That’s impossible!” That’s when I know I’m on to something good.

CSS (Cascading Stylesheets) has the ability to separate presentation from content. At a University, with the multiplicity of content providers (PR folks, faculty, administrators), and the heterogeneity of content and Web missions (teaching, information, transactions, development, etc.), you’d think that the current more favorable state of the browser world would have everyone clamouring for Web standards. And, to a certain extent, they clamour. However, the notion of what Web standards can do is frequently discussed within the realm of a chosen technology environment.

Here’s how it goes: We want to purchase Ingeniux, or Sharepoint, or Documentum, or fill-in-the-blank CMS, or we are adopting Drupal, or WordPress, or SAKAI or some other open source tool. One of the ways that we evaluate them is adherence to Web standards. We go in and edit our style.css, home.css, main.css, or the other standard stylesheets and we are using CSS to control the environment.

But, I’m here to tell you, that is SO February 2009.

CSS gives us quick ability to manipulate presentation without touching the code that actually displays the content. Heck, you can point to a CSS file on another server, which means a central pool of designers doesn’t even have to touch the systems themselves. Add to this the democratization of content management through the open source movement, and lots of faculty members using WordPress, Drupal, Joomla and the like, why, oh WHY do we ask them to use a central system?

The “It’s impossible!” comment I got was from a mindset rooted within that old framework. “We’d have to support multiple systems!” Yet, resistance is, over the long haul, increasingly futile.

Well, branding is important to recruitment, and University Relations folks need not be viewed as the long arm of the law if they are willing to think long-term. It’s the at times coercive and inelegant way that PR and IT folks (myself among them) go about standardizing the brand on the Web that I have a beef with. How about, rather than proposing that folks to come to YOUR party where you may not be serving what they need, you meet them where they are already comfortable. Creating and managing CSS files centrally for disparate systems solves many problems in terms of branding, and allows for systems to scale on their own.

There are only so many technologies that a single University employs on the public Web. And there are only so many pages or sub-sites that are critical to branding. So, if a Webmaster needs to skin WordPress, Drupal, Django, Joomla, Moodle, Ingeniux, even Web-enabled ERPs like Banner*, or any other system that our users want, they are now empowered to do that freely. The technology chops come in how to get that accomplished on the backend in terms of possible Web services, chron jobs, and scripts to ensure availability of central design elements and sharing of CSS elements across systems, keeping up with upgrades. The need to be an application administrator (SO September 2008) goes away, freeing up time for this new cooler stuff. That’s the Webmaster. Then, the design chops come in how to make it all look good, look the same, and support that brand. That’s the Web designer. Outsource the occasional “cool” stuff to crack Flash and multimedia developers rather than keeping them on the payroll until they find something that pays better which they will — trust me.

This would take out of the Web shop all other geeky skills like managing applications and developing content at the same time, and trying to recruit folks with a ridiculous range of skills that never occur in one organism (I saw a job post the other day that had Flex, Flash, Multimedia Design, Adobe CS, and UNIX 🙂

This notion of a centralized CSS control across disparate systems fundamentally changes the role of the Web communications office and the Webmaster. Now, their role is to figure out how to “skin” multiple systems, how to give folks the ability to link to the institutional stylesheets, how to structure the presentation of multiple systems. It gives central University Relations folks the ability to reach into systems heretofore unavailable to them, but not have to manage multiple technologies. It accepts that the current democratization of technology comprises a horse that has left the barn.

In short, it encompasses how to use CSS as it was meant to be used: the way to definitively separate design (one set of competencies within University Relations) from content and functionality (multiple sets of competencies across the institution).

Impossible 😉

* I’ve skinned 3 of the above systems so I know what I’m talking about. It ain’t rocket science.