Fuzzy Content

Rebuilding a higher education Web site is always a significant endeavor. It takes months, it involves so many people across campus, and it can seem never ending. Much like a new building opening, more universities need to have a “ribbon cutting” of the new Web site.

Why, you ask? A few reasons:

• Any publicity is good publicity. That’s not necessarily true, but launching a new Web presence is positive for the institution, the campus community, and the general public. If you have built the new Web site correctly, a site visitor should be thrilled at how much easier the site is to use, how much more they can do, or how much stronger tied to the institution they are.
• It’s taken blood, sweat, and tears. Through committee reviews, content revisions, design changes, navigation nightmares, and just sheer length of time, the launch is a cause for celebration. Everyone involved deserves a pat on the back…make it official.
• You’re proud of what you’ve done. In the end, the new site is better. Let people know.

How, you ask? A few tips:

•  Plan early. How you are going to launch the site should be decided during early phases. As you are setting site goals, resources, and timelines, decide how the message is going to get out about the new site. Look for an event to tie the launch to. Look for a time to launch that won’t disrupt significant activities (Fall registration, for example). And pad your time accordingly.
• Log the development process. Many institutions have started to do this as a collection for all documents, processes, and resources. It is not only a great way to keep on track, but also a great way to look back at all that was involved. Make this as public as you are comfortable with.
• Let the dust settle. With any significant Web redesign, there are bound to be a few bugs found after you go live. Flip the switch, get some user testing in, then make it official 2-4 weeks later. We call these “quiet launch” and “loud launch”.
• Throw a party. There are two reasons a party should be thrown. First, there are several people that gave their heart and soul to bringing the new site to life. Publicly thank them. Second, you are moving into Phase II, which is maintenance. All the content authors, bloggers, image managers, developers, site stakeholders, and central managers should understand that the next step is to keep the site as shiny and new two years from now as it is today. Motivate them.

These are just a few ideas in getting the site launched with the most bang. If you have a launch story, please share in the comments section. I would love to hear.

For those in marketing (me being one of them), I hear many stories of frustration in building a visitor-centric Web site. You can control the message and presentation, but you will never be able to control where site readers enter the site, what sequence they move through pages, and when they decide to leave.
Web 2.0 (I know, I know) means that now I have even less control. Not only did I lose control over visitors on how they used my site. But now, I will see many visitors get information without even entering my domain. Syndication has allowed site content to become a collection of information that I, as a reader, review in the comfort of my own RSS aggregator (newsgator, myYahoo, etc).

As microformats continue to take hold of consistent content, this will even become more of the case. Sites and software are beginning to format their information (profiles, blog entries, events, and eventually course catalog information) following standard structures. This practice gives visitors an even wider platform to find information related to you.

The secret is to understand where people find information about you, then participate. In the “real” world, prospective students find information and build impressions of your institution without stepping foot in your admission office. But the more active you are in advertising, printed material, and high school visits, the better chance the information and impressions are accurate.

So, if you haven’t already, actively participate in Facebook groups. Submit your events on upcoming.org, and look for tools that help you gain exposure outside your .edu. You won’t have complete control over what your visitors are reading, seeing, and acting on, but you will better understand who and where people interact with you as an institution.

In helping colleges understand how a Web site should be managed day-in and day-out, I am sometimes surprised at how closely Web content is held by a select few. It is also surprising how many departments want nothing to do with keeping their site up to snuff for visitors.

I just read a short book, QBQ, that talks about personal responsibility and providing a positive atmosphere…two concepts built for the Web. Without going into a full book report, I decided to apply these concepts to you and your site.

• It’s Not My Job. The Web is everyone’s job, since it affects every department. If you are in the Biology department, and that site is out of date, you need to either change the content or alert the proper channels. You may not be an official “content author”, but if you find a mistake, get it fixed.
• I Don’t Understand the Web. In this day and age, the Web has become a major (if not the) communication and marketing tool for key audiences (parents, prospective students, alumni, campus community). Don’t shy away from the opportunity to tell your story.
• Why is Our Site So Bad. The saying goes, “It takes a village to raise a child…” It also takes a community to maintain a Web site. If content is out of date, put in some elbow grease. If the navigation is chaotic, get the right people together. If the message is missing the mark for your story or your audiences (or both), you’d better get to work.

People say that if you don’t vote, don’t complain about politics. And unfortunately, this feeling has made its way into Web site maintenance. Many colleges and universities work very hard to get the right people and publishing processes in place. With this effort, those not given responsibility automatically just leave it up to designated users. Stop it! A smooth running Web site benefits all.

Now get in there!!

I recently caught a Webinar from x-pubs, which discusses the necessary changes that go into moving to full content management across campus. Emma Hamer discusses some of the problems and opportunities out there when changing to content management. Watch it all on YouTube.

For higher education, I work with many institutions that can underestimate the impact of a change to content management. To be done properly, please consider the following points:

• Start with goals and expectations. Many projects I am involved with are tied to a redesign of the entire .edu. Not only is content management being implemented, but also drastic navigation changes, a new interface design, and exciting new features. All this change at once can overwhelm users as well as authors and developers. Start with identifying what is not working on the existing site, what institutional initiatives impact the Web, and what the organization expects out of the Web in one, two, and three years. Without this understanding, it is difficult to determine success of the site, let alone how to fix a problem.
• Content management is not technology. I find myself saying this often. Besides a CMS being selected, an institution needs to identify who’s involved, what they will be doing, and what publishing and development processes need to be put in place. Also, all CMS providers are not created equal. Know what you want out of a content management solution, then seek CMS providers that match that criteria. Without a clear understanding of content management as a whole, no one CMS will succeed.
• Understand the hidden costs. CMS unfortunately is not a silver bullet. Once software is installed, the site does not build and manage itself. There is still initial training for authors and administrators, as well as periodic workshops to ensure all authors across campus(es) are on the same page. There is server installation and maintenance. And there are always new features and uses that can be incorporated to improve the user experience of your Web site.
• Get people involved early. With site redesign projects typically being on the “massive” side, those currently managing portions of the site will be impacted greatly. Whether site management is already decentralized or you are moving to distributed authoring, the people managing the site at the page level need to understand what is changing. They need to be able to provide direction, since they are the closest to site users. And especially if you are giving them ownership of the content (ability to directly publish), they need to have some say in navigation and interface changes. Don’t wait until all the big decisions are made. Bring them into early focus groups to share user stories. Involve them in changes to navigation. Ask them what they think the tone of the site should be. Trust me…they know.
• Understand your minimums. Content management works wonderfully, as long as there is central control of key aspects. The closer you get authors to only controlling content, the more successful your site will be. But there has to be a strong foundation. This includes navigation schemes, branding elements, and user resources that appear on every page. Understand what those are and who manages those elements.

As always, review site performance at least once a year, and don’t be afraid to make changes. A site redesign and content management implementation brings on so much change, you must keep what’s working and cut bait with what isn’t. You’ll be better off for it.

Dimitri and I just got back from Rochester, NY for this week’s highedwebdev conference. With over 400 attendees and five session tracks, there was plenty to soak in.

The first thing that caught my eye was that many of the sessions (at least in title) were focused on the very thing that we love…fuzzy content. The sessions were not as much about what you do to your site, but more of how your site is a bigger piece of the Web puzzle.

I also found that sessions were focused on the front-end how-tos. With the potential for this to be a nuts and bolts conference, I was delighted to see usability as its own track. And content management as a separate track. I thought the “design and strategy” track could have been sprinkled a little more throughout the other tracks, but just the fact that there were sessions dedicated to “planning before investing” brought a smile to my face.

All in all, a good week spent with an army of those moving toward a similar goal. Now if we can only get VPs to drink our Kool-Aid, we’re in business.

To relive (or to live vicariously), goto del.icio.us or flickr for more. And follow Dimitri’s (and others’) guest posts on collegewebeditor.

In one time or another in my life, I have made a big deal out of something fairly insignificant. I’ve made bad decisions based on this error in judgement. I’ve even delayed the bigger picture based on this error. I am here to tell you that I am stopping this behavior.

I know that I’m not alone in this. I’ve helped many colleges and universities develop the structure of their site. I’ve sat through meetings to discuss what users want out of a Web site. At some point in a lot of these meetings, we run a list of every activity and piece of information audiences are expecting when they come to the site.

The reason we go through these steps is to get in the mind of our visitors. Why do people come to the Web site? The problem is that all tasks, when listed out, are all equal. Applying is just as important as getting a parking pass. Some tasks are significant, some are minute. Why do we choose to treat them as equals.

What happens from there is an architectural nightmare. Avoid this with these steps:

• After you outline tasks, prioritize them. This will determine which are the key actions and which may be 4 or 5 or 6 clicks in. I don’t need to get a parking pass unless I am visiting campus. Put that task only on the “Visiting Campus” page.
• Understand the difference between tasks and information. Apply is an action. The biology department is information. Group these appropriately in your navigation sets to avoid long lists. Again, see Evergreen State’s admission page.
• Watch people using your site. A usability test is not as complex as you think. A Web cam, tracking software, and 10 visitors will give you an afternoon worth of invaluable site structure recommendations. Easily more than your committee sitting in a room for a couple hours staring at the long list of information and tasks. Ask site visitors what information they look for, then have them show you. You now know what is important to an audience member and how they complete the task. AMAZING.
• Always keep the visitor in mind. When the Director of Facilities says that his page needs to be a link from the home page, ask him who benefits. When the Director of Admission says that her page needs to be a link from the home page, ask her who benefits. Every link should be driving visitors to information or a task. If your link doesn’t move the ball forward, make room for those links that do.

I have to say it one more time…test your site structure with actual visitors. Get feedback. Don’t build your site in a vacuum. Nobody can identify minutia better than your visitors. Bubble the important stuff to the surface and don’t fight over the less significant.

Well, you know me — big fan of analogies. Can’t help it. So here it comes: working with web sites is kind of like airplanes. Yeah. Never saw it coming, did ya? But stay with me. The analogy seems to work well to describe basic roles in Web development.

First, there is the plane. Well, duh. The plane is your Web site — a sleek, wicked technological creation, built with the latest (hopefully) technology, safe, sound, fast, and beautiful.

Then, you have the passengers. Obviously, passengers are your site visitors. They are the end customers of the industry, sitting in their comfy (hrmph) chairs, stretching their legs (yah-huh), looking forward (blech) to their point-a-to-point-b experience. Everybody else’s goal is to get these pesky passengers to their destinations safely and in largest quantities possible. Okay, I may be mixing too much painful reality in this analogy — let’s not get carried away with realism. Never helpful in analogies.

To aid the passengers, there are pilots and onboard crew. Web sites have theirs — content managers, admins, and authors are here to take the passengers to their destinations. Professionally trained and well-staffed, they are one lean, mean visitor-serving machine. They are bright-eyed, cheerful, all forward-facing, eager to help, shuffling back and forth through the aisle, handing out drinks and cookies (get it, cookies?) Naturally, failure to carry out their mission brings a full pallette of hazardous events, from mildly annoying to more or less catastrophic.

To make sure the plane’s uninterrupted (don’t want to run out of gas in mid-air, y’know?) and smooth operation, mechanics, or IT professionals, work tirelessly to keep your plane-site up-to-date with the latest and most securely greatest, with bandwidth and space to spare. Should the mechanics abandon their duties in favor of mid-afternoon matinee, they jeopardize the (virutal) health and sanity of the passengers just as much as the onboard crew.

Finally, there are aircraft engineers. It is their job to build better, faster, safer, and more efficient planes, erm… sites. The goal of an engineer is to excel at anticipation and balance. They must anticipate, plan, and build the entire system, from the optimal experience for passengers, to easy flight controls for the pilots, to handy grips on hatches for mechanics. And they also must balance this anticipation with existing constraints, such as time, budget, and laws of physics. They are site architects and engineers, charged with the task to visualize the success. Tough job, eh? That is probably why you don’t see too many of them around. Or do you? Wait, that’s another topic.

In a large airline, these roles are neatly separated by the organization hirearchy. But if you are a small mom-and-pop shop, the same guy gets to wear many hats. And it’s ok. You gotta do what you gotta do to survive. What’s not ok is to think that being small or low-budget gives you an excuse to forego the separation of the roles. Believe me, no passenger is pleased to see the pilot wearing greasy coveralls or the flight attendant running to the back of the plane with a wrench muttering something about “them darn turbines” being out of alignment. You’ve got to keep a good track of what you’re doing and what are the responsibilities and constraints of your current role. So, wash up and change after refueling your Cessna. It’s good for you. It’s good for your business.

That’s about it. Coming up: Why Building Web Sites is Not Like Building Planes. Is it a self-rebuttal? Or a clever twist on the same story? The anticipation is killing me.

And… Choo choo! Did you think I’d forgotten about trains?

A recent discussion on the uwebd listserv centers around how you include key audiences in site planning. Do you pick a handful of key audiences and cater to them (hoping insignificant site visitors can still find information) or do you try to make the home page all things to all people?

As a college or university, the number of “key” audiences can be many. It is not just a label of current student that works in a lot of cases. You have adult students versus traditional students, undergraduate students versus graduate students, on-campus versus commuters…you get the idea. So, how do you build a site that could even match the needs of every category of key audiences?

There are three questions to answer before you build your site around anyone:

• Who visits your Web site? Make a list of all types of visitors to your site. Be specific. Be ready to sub-categorize.
• What primary sets of information do those visitors need? Keep them per audience (and even sub audience). Use focus groups, surveys, or one-on-one sessions to define these needs.
• What actions do you want those visitors to accomplish? You can’t track site success without action. Again, specify per audience. Again, use one-on-one sessions and a competitive analysis to outline these tasks.

From here, you can decide how to build global navigation (by audience, by topic, or a hybrid of the two). You may see enough overlap of needs and actions that you don’t need to be audience specific. You may see that each audience is very unique. But review the lot before you decide who are key site visitors. Tie in tasks before you decide on audience navigation. Build the site around those needs and tasks, and you can’t go wrong.

To start any Web project, I usually ask for a history lesson. I want to know how organizations got to the point they are now. Inevitably, the lesson centers around design overhauls and change in Web authority. When asked why they did a redesign before, typical answers include “it was pretty stale” or “so and so wanted a fresh look”, rather than to flatten the architecture, improve the publishing process, or integrate with other messages. And nine times out of ten, these projects are complete overhauls, rarely just improving content or upgrading the design (or as I like to say, “putting lipstick on a pig”).

So what’s the difference between redesignand redevelop? A redesign involves upgrading the presentation of the site. It is usually top down, meaning the home page is designed to match branding efforts. Redeveloping the site goes much deeper, looking into architecture, publishing, purpose, as well as design. With that said, a redesign can’t be done without a strong foundation to begin with. Or else, you will find yourself redesigning the site every year or two without much success.

How do you know if you are ready for redevelopment or a redesign? Ask yourself strategic questions. Are audiences finding the information they want. Is the institution coming across the way you want it? Is the level of functionality on the site equal to your competitors (and more importantly meeting your audiences’ expectations)? If you need to redesign the site and add features, you are ready for redevelopment. Features can turn out to be a losing battle, continually adding bells and whistles to distract people from the fact that they can’t find basic information. Get to the root of your site’s issues. That will tell you if you are ready for redevelopment.

Expect redevelopment to take a while. To get a campus to buy into content ownership takes time. To outline audience-focused navigation takes research. And a new look…well, that takes research, authority, and patience.

One of the first steps in rebuilding a Web site is to identify what your goals should be. Remember that these goals should not just be for the redesign, but should include development, maintenance, and long-term planning. Follow these rules and your Web presence should reflect what you worked so hard for:

• Be specific. Vague goals, like “more traffic,” do not help determine success. When you are establishing trackable goals, use current benchmarks of the site to compare to, then use trends to determine if the site is achieving these goals.
• Don’t include Web conventions. Nobody sets out to rebuild a site that is difficult for the reader. But every list of goals that I see include “easy to use.” Web conventions should become part of your everyday thoughts. If so many sites use these conventions, that should be a given for you, not a goal.
• Look outside the site. Your Web presence is only a piece of communications with your audiences. Use goal setting to establish parameters that are the result of the site. More instant messenging activity and email subscriptions can be a result of heavier site traffic. Don’t forget to benchmark, but use key activities to determine how the Web can help.
• Continually reevaluate. Most of these goals shouldn’t be launch-oriented. Set aside the first six months of log files to start trending, then see activity that dictates goals for the following year.

Goals are not only log-driven. Make sure you are conducting on-going usability tests to ensure that your goals match your site visitors’ expectations. Remember that your site is built for them, not you. And if your goals don’t reflect their needs, you are wasting your time.