October 2008 Archives

If you've read this blog before, you know I make my opinions very, very clear. There's more than one reason why I call this blog In Clear Text.

My second post of reflection from HighEdWeb 2008 is a reaction to a presentation and a personal discussion that help bolster my own personal cause, and--just in case I haven't made it clear enough in previous posts--a clear statement the following opinion:

We should be using wikis for internal documentation and training unless there is a good reason not to do so.

Rather than frame my arguments in why to use wikis, let's take a look at some reasons you may have for not using one and I will argue against them against them:

Poor Reason #1: A wiki is a "new" tool. We can't move our whole Intranet and/or internal training documents there.

Wikis have been around for much longer than you think and been proven as an effective method of keeping information updated.  Don't take my word for it. Look at how some of the following academic institutions are using wikis:

• The University of Minnesota Libraries' Intranet is a wiki.  (Thanks to Jane Klobas' Wikis: Tools for Information Work and Collaboration.)
  
• The University of Maryland, Baltimore County's Library is also using a wiki as an Intranet--Confluence, the same platform as Penn State WikiSpaces. (Thanks to May Chang's HighEdWeb 2008 session on Wiki + Shared Drive + DocMgmt = Our Intranet. May is the Head of Library IT services at UMBC.)
  
• Rice University's IT Tutorials are on a wiki--also on Confluence. (Thanks to a discussion with Katy McKinin, Senior Web Designer/Client Relationship Manager, Enterprise Applications at Rice during the Networking hour of HighEdWeb 2008 for sharing the site.)

Poor Reason #2: My audience is internal to my department. I could just use a departmental Intranet site.

Internal documentation and training on your own Intranet site may be fine if your department is a complete silo unto itself, where you have no reason to collaborate or share information with other departments or institutions. But before you decide to use an Intranet, ask yourself:

• Do you ever need to work on internal documentation/training projects with people outside your department? 
• Do you ever need to share a single document or training project on your site at with attendees from another institution?
• Would you like some training materials and/or documents to be made available to prospective employees and/or new hires to sample before they are hired and the account permissions are finally granted to your site?

If there is ever a single possibility of answering "yes" to one of the questions above, consider a wiki for its granular permissions structure.  Permissions to Penn State WikiSpaces can be set for the entire wiki and for each page.  You can manage viewing and/or editing permissions by individual user, user managed groups, or make your wiki page/space available to everyone.  (See ITS Training Services Handout on Penn State WikiSpaces and the Confluence 2.8 User Guide for more information.)

Poor Reason #3: It is important that our content is accurate. We don't want to lose control of the authorship.

• Sometimes locking down the source material too much has the opposite effect. Users create duplicates that you have no control over. For example, how many Web pages related to setting up and/or troubleshooting email do we have at Penn State. (See my post called "This Will Kill That".)
• You should consider a Wikipedia model where the old Intranet author/gatekeepers are now monitoring submissions. They devote less time to creating content, and shift their time to reviewing it. In the previous email example, if all email pages were combined, any content that was department-specific could be moved by the wiki editors into a special table or linked area from the main page on email.
  
• Permissions could be set on content that absolutely must be centrally controlled. (See my arguments under reason #2.)

Poor Reason #4: We have many users who are uncomfortable sharing their work and many users who won't want to learn a new tool.

I've encountered this problem, and it is not insurmountable. Prior to working for Penn State University Libraries I moved Penn State World Campus's Instructional Design & Development internal training site into a wiki.

If populated with useful information and heavily promoted, a good wiki becomes more user-friendly than any other tool you put in front of a user. Here are some tips:

• Understand why your department's culture resists collaboration and take steps to change this. (See my post on why people resist change.)
• Consider getting a pilot group of evangelists (5% of the population). (See my post on how to initiate change.)
• Consider changing the layout and color scheme of your wiki to match your institution's existing Web pages.  Users can rely on their spacial memory of the existing sites to help learn the wiki space and are less aware that the wiki is a new tool. (See pictures of our Penn State University Libraries' Website and my Penn State WikiSpaces Libraries theme below.)
  
• Don't release an empty wiki.  Start with information that needs frequent updates, is not documented, is in demand, or is many-to-many in nature. (See my post on "Wiki Wading".)
• Don't worry about defining the structure ahead of time or getting in turf wars over structure; you'll never get started that way.  If your wiki has a search tool, use it.  You'll find what you need without a preordained structure.
• Create tags/labels for "Newbies" and "QuickStart", so that you can create automatic pages for new hires and frequently accessed information based on items that use those labels.
  
• Nothing on a wiki is missing or wrong; you just haven't contributed to it yet.
• Put important information on the wiki and then email the URL to the group, thus leading them to the wiki.
• Don't tell them what they need to know; tell them where to find it. Repeat the phrase, "It's in the wiki."
• Distribute the documentation workload (and get them to use the wiki) as you train: teach them, but ask them to add it to the wiki. Edit their work as you check for understanding.

Rather than Chronicle HighEdWeb 2008 in minute-by-minute accounts, I thought I'd extract two themes relevant to me from my entire experience.  Today, in part to continue with my previous post comparing "Lost @ Penn State" to "Sesame Street Simple", my theme is simplicity.

I attended a variety of sessions across Applications & Standards; Marketing, Management, and Professional Development; Social Applications and Content; Technical: Propeller Hats Required; and Usability, Accessibility and Design.  One message that popped up across several of these, from presenters of all backgrounds, was the message that less is more.

Jeff Veen's Keynote, talked about the power of visualizing data, "to stop thinking about the numbers and see the patterns".  Data has real impact on us, not when we relay all the complexity of raw figures, but when we find a story we want to tell and "remove everything that isn't telling the story."  He talks about filtering our content for clarity.

In "Colors on the Web: Few Things, Great Results", Martha Carrer Cruz Gabriel, Professor, University Anhembi Morumbi noted that "perfection is taking away".

In "Getting Them to The Table and Keeping Them There: Campus Web Redesigns", the presenters, Susan T. Evans and Joel W. Pattison of William and Mary, discussed how authors become attached to their content want to include everything noting that very few people know how to communicate effectively.  Their advice was to remind people who needed to improve an existing site was to keep reminding existing authors that this clutter is why users were critical of navigating the site in the first place.

Even one of the books recommended in "Get a Clue: Shift Happens" (presented by Gordy Pace, Director of IT Communications, The University of Montana) advocates simplicity.  "Made to Stick" suggests the following for making a message stick: Simple, Unexpected, Concrete, Credible, Emotional and Story.

These lessons in simplicity go beyond Web content, Web Design and data visualization. In any process that faces a customer, internal or external, your goal is to find your central message and remove everything that distracts from it.  Your work is done when there is nothing else you can take away.