Real-World Organic Web Development

Cell Cleavage and Site DevelopmentAs an initial manifestation of my post on the potential of CSS to open up possibilities for cross-platform institutional Web publishing, I am in the final stages of developing a “skin” for WordPress that is identical to the the UMW Web site. It also allows for two- or three-column layout.

I’m sure to many folks this is a big snooze. The NOT big snooze part of it is that it was so darned easy. With the exception of footer content and some plugin customization I am working on, it was a snap to re-skin a theme called “ET-Starter” and make it look just the way I wanted it to in a few days.

Why would I do this when we are embarking on a new design for the site? There are multiple reasons. First, because it’s a great proof of concept. Second, because I can :). Third, the SACS Re-Accreditation committee needs a public Web presence right now, and it has to live for about 3 years. I didn’t want to create that in our aging Contribute/PHP environment — we’d have to re-create it when we move to WPMU for the public site. Rather, the idea here is to allow the SACS committee site to appear as anotherĀ  part of the official UMW Web site, but to live within WordPress Multi-User in a production environment.

This approach will be a great way to protoype functionality that this site is going to need and that our current public Web infrastructure can’t deliver in a scalable way: internal logins for private documents, easy Web publishing without a local client, rss aggregation and consumption, discussion forums, etc. When we are ready with a new graphic design, we simply skin this theme, port the SACS site over to the new server maintaining the same URL, ask IT to update the DNS, and voila!

What “skinning” and CSS allow us to do is to take advantage of the separation between content and presentation allowed by accessible, standards-based Web design. It lets us test, in a real-world application, much of what we will need in the live site without having to re-do tons of code when the institution decides on a look and feel. My fantasy is to have all the kinks so worked out on the backend so it will take a week to get us into full production after a new design has been chosen.

In the long run, and Jim Groom will kill me for blaspheming against the gods of WPMU, I see the possibility to roll this approach out to multiple platforms, not just WordPress. The goal of the Web for communications is to respond quickly as communications needs and goals change. By porting a skin from our home-grown environment to WordPress so quickly, we are proving that anything is possible moving forward.

Hey, I can dream. Even if it’s longer (like a month, probably), this is vastly different from the way we used to do the web with endless, amorphous wish-lists of functionality, creation of non-functioning prototypes, followed by months of development, testing, and then presentation design.

This is the kind of thing that gets me up in the morning, when my kids don’t do it first.

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.