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.

When is Simplicity Simplistic?

Vignelli's Doomed MasterpieceIn the early 1970s, Massigmo Vignelli re-designed the NYC Subway maps, making them beautiful abstractions of streamlined simplicity. The idea was based on a notion that the existing maps were too complicated to read, and that riders wanted simplicity.

Unfortunately, the Vignelli maps were pretty quickly scrapped because they were so divorced from user reality (the streetscape was completely out of scale) that folks had trouble locating where a street they entered from in their neighborhood actually was located on the map. They didn’t want streamlined. They wanted clarity. Dumb designers (actually, Vignelli was one of the 1970s greats, and the maps ARE beautiful.)

As with the NYC subways, University cultures and processes are difficult to understand and navigate. What is it about navigational design for a University site that makes it almost impossible to find anything? I wish I had the definitive answer, but in this space, I will begin to unpack this issue. For now, I’d like to address the issue of overanticipation.

This phrase came up when we were designing the TeachUMW Web site last semester. Our group (The Provost, DTLT, Teaching Center Advisory Committee members, and myself) was designing a site that preceded the actual program for which it was to be the initial online communications vehicle. As a result, we really had no way to anticipate information architecture when there was, well, little information to go by.

The structure of the site had to address the possible architecture of a conversation that had not taken place. This included not only which tools to provide (wikis, blog posts, event calendars, etc.) but how to structure access to them to enable new conversations to begin and branch out. Sounds like social networking, right? Right. So we used Drupal, a content management system that enables social networking. Since much of our conversation on campus is done within committees, task forces, and the like, Patrick Murray-John tweaked the application to allow these tools to be deployed based on membership in, or participation in discussions with, a particular group.

This all seems fine, but there was a piece missing, and we kind of knew there would be. There is no tool for users to create static Web content in the form of traditional information architecture: sections with sub-pages. An administrator can do this if they want, but we avoided it for the masses, at least at rollout. Why?

After much debate over this issue, we had to face a hard reality: How could we anticipate information architecture for static page content when the structure of the program was not yet in place? If we were to have a capability for static content, we had two choices:

Let the users develop their own static information architecture
We had seen how the UMW site had become like the wild west, with an information architecture so byzantine as a result of democratizing these decisions. One person’s “registration” is another person’s “academic catalogue” is another person’s “course listing.” The one who gets to make the decision is the person authoring the content. This person is an expert on their content, but completely unaware (nor should they be) of where that content fits into the overall architecture of the University. As a result, folks go to the search box. It’s kind of amusing to note that, during the design process, Jerry Slezak sarcastically suggested that the home page for TeachUMW simply BE a search box. That sounded great, until we realized that Google already exists.

Anticipate the information architecture as best we could
Never does the term “the best laid plans” seem to play itself out more than in over-engineered information architecture. The entire discipline is about anticipation of the user experience. When the user at a University is not only a consumer (like at Amazon), but one of MANY stakeholders with a wide variety of relationships with the University, this is almost impossible. People visit the site for hundreds and hundreds of reasons, representing students/prospective students, faculty/prospective faculty/retired faculty, parents, administration, staff/prospective employees, alumni/benefactors, Forum attendees, Gallery visitors, etc. And each of these groups breaks down by further granularity in their relationships with the University. Residential student or commuting student? Full-time faculty or adjunct? Administrative Faculty or Classified? State resident or out-of-state resident? If you are able to unpack that into a single information architecture that makes sense, I’ll call the Nobels and you are a candidate for the next Peace Prize.

The classic solution to the above is to have what’s known as a hybrid information architecture. We categorize by audience (alumni, student, etc.), and also by topic (Academics, Admissions, etc.), and sitewide supplementary navigation (directory, AtoZ index, search). What if I don’t want to take a second to determine if I am a student, faculty, staff (I may be more than one), or if what I’m looking for is within any of the topics that have been presented as the top level appropriate topics? Lots of folks don’t want to take the “beat” it takes to determine that. It’s cumbersome. As a result, the search is where a user will go. We simply cannot, at a single point in time, determine within what structure most users will be able to find where what they are looking for fits in.

So, let’s throw up our hands? No, but it fails so badly that I believe we should be willing to blow it up and start fresh. To that end, I offer the following possibilities if the University plans on taking the opportunity for the Sharepoint migration to mean more than simply a backend switch. Here are a few ideas:

1) Transactional Structure: When I go to a site, I kind of know what it is I want to be doing there: Research, purchasing, exploring, chatting, etc. What if there were a way to invite folks in based on the transaction they are planning with this visit?

2) Welcome Boostrapping: Attack the site design issue as an interative one. I’m not talking about “tweaking” so much as an annual, systematic analysis of analytics resulting in a well-researched plan of attack for upgrades and improvements deeper than cosmetics. Be open to wholesale change when indicated and be willing to “kill your darlings” if they don’t work.

3) Customer Service vs. “Design”: We like to have Web committees to talk about Web design. We are better served to have customer service committees to talk about ALL University transactions and relationships, and determine where the Web site fits into that initiative first. That way, any Web design changes and improvements are based in more than anecdotal preference, are coordinated sitewide by Enterprise Designers, and are part of a bigger picture that serves the University community.

4) Tagging Content: Let’s stop asking departmental Web managers/authors to anticipate fitting the content into a structure. It’s too overwhelming a task, and has led to the “wild west” phenomenon we see now. Let them do what they do best: Author accurate content, have it vetted, and publish it to the Web. Enterprise designers should develop a taxonomy for tagging, and templates to contain, aggregate, and display content based on tagging. Authors should be asked to select from a pre-determined taxonomy a list of tagged content based on its transaction type, audience, concerned offices, processes, etc. The CMS will present it as the Enterprise designers intend, based on the University’s customer service initiatives.

5) Expiring Content: Authors should be asked to set a beginning and end date for content so that old content GOES AWAY when it’s no longer needed.

Keep in mind that I say all of this knowing how instrumental I’ve been in creating the mess that’s now there. But the mess is a sign of progress. There is so much content by so many people, and that’s a mixed blessing, not a curse. In the long run, that’s a very, very good thing. We have just come to a point where we need to re-address not just the scalability of the technology, but the scalability of a dynamic information architecture based on solid information and a customer-centric focus.

In short, it’s not just about streamlining entry points based on aesthetics and anecdotal notions of simplicity. We saw how that worked for Vignelli. It’s not about shying away from complexity. It’s about embracing it, and making it work for you. With current CMS solutions, that is now a very real possibility, if the University has the will to start anew.

The Visible University

Every time a University Web site is re-tooled, there is this tug of war between those who see it as a marketing tool, and those who see it as a part of their working environment. A couple of years ago, when implementing the portal, we debated whether internal policies and forms should be taken off the public web site altogether and placed in the portal, behind authentication.

There were two arguments against this, one philosophical, the other pragmatic. Philosophically, the notion of a public institution having its policies available for the public to see, and for colleagues at other institutions to refer to, seems to be philosophically correct. I know when I’ve worked in drafting or re-drafting policy, searching for other institution’s policies is a big part of that process.

Pragmatically, folks on campus set the UMW Web site as their home page out of habit, and may not want to sit and parse the difference between what is considered internal vs. external. What seems obvious to communications or IT folks may not be obvious to an administrative user who just wants to access something “off the web.”

As we discuss re-tooling the public site within a possible Sharepoint framework, a big part of that discussion has brought up this topic again. Once again, I am torn because of the considerations stated above. So, I have to wonder, if we are to fulfill both the philosophical and pragmatic concerns for keeping it all public, what is NOT working in the current environment to make it all seem so cluttered?

I believe it’s a matter of information architecture and presentation more than anything else. Keep in mind, I built the system that’s now a big blob of burgeoning content. Of that, I am quite proud. Visually, we absolutely achieved the questionable “Holy Grail” of design standardization, with every department page on the site looking, with little difference, identical.

There are two reasons for the lack of variety: Lack of time and resources. I was given two months to achieve full conversion of the new design throughout the ENTIRE SITE. All that was in my office at the time was me and one part-time PHP programmer. Second, I reported to IT and as a result did not have the official “authority” to advocate for distinction of design based on content. The University Relations position at the time was that EVERYTHING was to look the same. A rather literal interpretation of standardization, but I was not organizationally positioned to reason why.

The mandate for standardization was met by the solution, and the limits of standardization, as a result, are pretty obvious: There is no real visceral distinction that tells someone we are in a different universe of content now, a universe that pertains to your needs in the workplace vs. you visiting our site to learn about us.

So, I’m wondering if these divergent needs of clean marketing tool and public policy-wonk transparency can be addressed using a middle-ground approach. Does the “internal” environment as we are discussing it, need to necessarily be protected via authentication? Can it merely break off and be another public Web site (visually and navigationally) populated by internally-relevant content?

There is bound to be content that is relevant to both internal and external audiences. Matter of fact, it’s kind of mathematically impossible for that NOT to happen: a 50/50 chance over 20,000 unique URLs? I think it might happen once or twice…Where do we tell folks to go when it’s in a gray area?

The advantage of using Sharepoint with a public and private face seems to me to be that we can decide along a continuum of content which is absolutely confidential, to content which is most relevant to internal audiences, to content which is absolutely relevant to external audiences. But it’s a continuum, and I don’t want to draw the line any further along than the line of confidentiality — which is really what authentication is for. Authentication is about declaring yourself authorized to see something. It’s not a cheap fix for information architecture and intelligent, complex Web design.

Where I understand the “clutter” argument of keeping the internal content in a separate place, and even advocated for it years ago, I’m now converted to the other side. Not only am I convinced that making such distinctions is not scalable or enforceable, but I am convinced that we owe the Citizens of the Commonwealth access to how we conduct our business and spend their money.

In the 1980s, I worked as a Building Code and Zoning consultant in NYC. I became fascinated with how the zoning came to be, how the codes evolved, all the different versions, how some buildings got “grandfathered” and variances were granted. One of my favorite things was to be assigned to research the history of a building undergoing alterations. They NYC Department of Buildings kept everything on microfiche in those days. Anything older than 1978, and you’d get the original blueprints.

Aligning the construction standards with the prevailing codes at the time gave me a window into how the city was constructed (organically, really) and when things got SO out of hand in terms of density that the codes needed to be overhauled to keep the place from going up in flames.

All this is to say, even something as mundane as a travel and reimbursement form is some future window into how business is conducted in this day, this time, in the Commonwealth. I’m not sure it’s up to me to make a decision that I want to hide that from the public.

The University’s public Web site IS a marketing tool. But, the larger Web is a community, and the Web site of a public institution is part of government transparency, and, however mundane, part of history, just like those old microfiches and dusty building codes. Thinking of it another way, in the absence of all the “man behind the curtain” kind of day-to-day policy stuff, our public Web site will make us look like a product rather than a place. It’s subtle, but I think it would strip us of some of what makes public institutions so cool.

There is a way to have both. We just need more time this time to develop a more complex information architecture, and get away from the frantic, simplistic notion that design standardization is paramount. When it serves to confuse, it ain’t pretty anymore.

Day on the Death Star

We spent the day with a consultant specializing in MS Sharepoint. Yes, after a meeting about open source social networking tools, I climbed out of Luke Skywalkers X-Wing fighter into the heart of the Death Star.

My tongue is firmly in my cheek. The longer I do this kind of stuff, the more I realize that I can’t count anything out. The religious wars in which I’ve been a part — open source vs. proprietary environments — seem to be entered into with large blind spots based on myriad agendas.

I’ve spent two months having trouble accepting that an enterprise Web authoring and document management solution, much less one from Microsoft, could ever be a viable alternative to the PHP-based solutions we have now. But, I’ve come to a point to have to open my mind or feel shackled by my own biases.

Solutions like this seem more attractive when you’re dealing with a now-dated environment of manually-managed shared drive directories, an unrelated homegrown open-source Web environment, with a loosely-related portal/ERP frontend, and a completely unrelated totally cool academic and personal Web authoring platform where the stuff that IS the University online is happening.

And the answer is, it depends.

I’m more squeamish about Sharepoint CMS than the collaboration and document management features. I fear a lock-down in creativity that could result. I fear training and staffing continuity issues for proprietary platforms like .NET, programmers for which are highly paid in relation to folks who churn out PHP. I worry about vendor lock-in, about the ability to migrate in the future when the inevitable happens and a new tool is invented.

But, in keeping with the notion from yesterday’s post that the institutional Web site has to offer clarity, functionality, and easy access, along with creative charm, the locus for creativity seems to shift from the pride in the clever code backend/snappy graphics thing (which is always fun, in a narcissistic developer kind of way), to managing and delivering CONTENT. Imagine that.

Perhaps, then, the backend of the enterprise need not be super, duper open source, but rather stable and supported, able to read and serve RSS, which Sharepoint does. And it sure would be great to have ready documentation instead of spending hours debugging something that the last guy wrote. That kind of open-source, roll up your sleeves, we got the barn let’s put on a show is essential for creative, academic and personal authoring, and I love doing that stuff. Gladly, we are living in the end times for the FrontPage and Dreamweaver hegemony. Free open source, no coding needed unless you LIKE that kind of thing, is the ultimate barrier-reducer in the personal Web publishing context.

For most Universities, the content on the Web site begins and ends in the public Web environment. Now, I’m starting to be persuaded that enterprise Web site environments (organizing and delivering audience-aware content) no longer need to OWN the content. In that context, I’ll climb out of the X-Wing for a while, but, I want the keys back 🙂