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.

The Human CMS

Anyone who’s been involved in technology rollouts and training knows that there are not enough hours in the day to address every issue that will come up when the person finally sits alone at their computer using the system for real. As a result, you kind of take a chance and focus on the most critical skills: logging in, using basic features, finding documentation and help. In the world of Web training, the one thing that technology trainers lack both the time and the authority to do is to teach about understanding the nature of the content itself.

In the necessary rush to move University content online over the last decade, the issue of actual content in its meaning is probably the least addressed. Aside from the not-enough-hours-in-the-day phenomenon, there are other issues, to my mind, that complicate Web content creation and organization in the largely Web 1.0 world that is University Web communications.

The UMWBlogs project is a great indication of what happens when content is owned by the content creator and not the institution. Even pushing aside UMWBlogs inherent luxuries of the first amendment and personal expression, there is something else afoot in what makes UMWBlogs content more comprehensible than the stuff on the UMW Web site.

I would argue that it comes down to the motivation on the part of the person sitting at that terminal to post something on the Web. Posting to your blog involves understanding the nature of the post relative to the rest of a blog that you created. That’s a relatively small universe of content, and it’s content that you created, so you have a natural understanding of it. The result is a kind of narrative that builds over time, and the blog becomes bigger than the sum of its parts. It tells a story. The more personal investment that the content creator has in the blog, the more likely you are to want to follow the story over time as it unfolds.

When, however, your job is to post Web content within a container called “the University,” and you are only a small part of that universe, it is nearly impossible for the content creator to understand the context. We create organizationally-driven architectures with department Web sites simply because, for the individual author, that narrows down the context enough to be able to plan where content is going and when.

We all know the perils of organizationally-driven site architecture, and how difficult it can make finding things for the person navigating the site. It’s the kind of architecture that screams “go to the search box.” Indeed, Google’s home page may be the way every University site should look: One big search box with the organization’s logo. At least, that would be an honest response to user need.

The promise of content management systems is that, by making content, rather than pages, the focus, content can appear and re-appear in multiple contexts without being relegated to a page buried deep inside the organization. The problem with this promise is that those who have editorial control of the overarching site architecture are not organizationally positioned for an in-depth understanding of all areas of the institution. Usually, it is the folks in university relations and development that have ultimate editorial control over University Web sites. This area of competency is great for single-facing, targeted and mass media messaging to shape perceptions of the institution: talking to the press, news releases, public events calendars, development.

The trouble is that, at a community as diverse and complex as a University, the synergies that could possibly arise from all the things happening and being said at any given moment cannot be leveraged in any interesting way as long the University site is seen as primarily PR. So much of what happens at universities, from sales at the bookstore, to registration activities, to menus at the dining hall, to what-did-you-think-about-that-visiting-lecturer, live outside the scope of public relations. This is not a statement in any way on the myopia of university relations professionals. By and large, they are very good at what they do. However, what they have been tasked with doing vis-à-vis the Web is more complex than the print and media relations world alone. They’ve been asked to do an impossible task: taking an essentially modern approach (throw newer technologies at the problem) to what is in essence a postmodern problem: harnessing the collective by truly empowering understanding of the larger university context. That is, reaching in and creating meaning every time a person sits at their terminal to post something to the institutional Web site.

If we can define the problem as building meaning for the Web author, rather than selecting the “best CMS,” we can then begin to shape solutions to address THAT very human issue. When people feel as compelled to post and manage quality, relevant, and timely content on an institutional Web site, rather than throwing things up only because they were asked to by their supervisor, we will have advanced institutional Web communications further than any CMS technology, no matter how seductive and “robust,” can do alone.