On this page:
  • Information gardening tasks
  • Wiki information architecture thoughts
  • Wiki organization challenge – thinking out loud

Information gardening tasks

A large part of my work involves capturing and organizing information. It takes a surprising lot of time and thought. Here are some of the things I do:

  • Capture and file information, relevant mail, work in progress, final output, etc.
  • Help people find information and improve the findability along the way
  • Create and refine navigation (links, new pages, etc.)
  • Move information from private spaces to public spaces
  • Facilitate and summarize online discussions
  • Coach people on tool use and answer support questions
  • Document and refine processes
  • Set up communities, discussions, and other sub-sites
  • Recommend processes and improvements
  • Correct obsolete links and assets

I do that across multiple tools (Wikis, Communities, TeamRooms, Activities, e-mail), with a team of mixed early, mainstream and late adopters and changing communities of learners.

I think of this as information gardening. I can’t architect a beautiful information structure from the beginning. I don’t know what the final result will look like. All I can do is support, organize, water, tie, and prune. I have to find out what paths people use, then pave them to make finding things a little easier.

It’s not easy. It’s less engaging or measurable than programming, where you can track your progress by the defects you close and the features you build. But it creates a lot of value and helps scale up the effect of our group’s work. Why do I do it?

  • I’m building an example of how social computing can support a team.
  • I’m learning more about emergent information architecture.
  • I’m developing and documenting practices that other people might find useful.

How am I learning about this? Mostly through inspiration, practice, and reflection. I collect examples of well-organized wikis and I talk to other teams who use combinations of tools. I handle my team members’ requests and questions, and I think about how we can organize things better.

If you want your team to get more value out of social tools and knowledge sharing, you’ll probably need someone doing work like this.

Anyone else doing this? Want to share notes?

Wiki information architecture thoughts

Even though a wiki is a free-form, unstructured, organic information repository, it needs to be organized so that users don’t get overwhelmed by information. So, how do you organize information on a wiki?

Wikipatterns is a great site for people and adoption patterns, but it doesn’t give tips on how to organize the information. So here are some tips to help you organize your wiki:

Visual identity

A banner, customized colour scheme, and a sidebar may seem unnecessary. When you’re creating lots of pages, it’s a pain to copy-and-paste the template. But a visual identity for your wiki helps people recognize when they’re looking at one of its pages and it gives them a consistent way to navigate to the major parts of your site. Tip: If your wiki allows you to include other wiki pages, put template segments on separate pages and then include them. This saves you from editing hundreds of pages whenever your navigation menu changes.

Homepage

Write the homepage content for a general audience instead of for specialized roles. Provide information about your team and about the wiki. Save the detailed links for other navigation pages that are linked to from the homepage. Link to other resources people might find useful, too.

Multiple navigation pages

Create multiple ways to navigate through the same information space. For example, if project managers need to access certain kinds of information quickly, create a page for them with shortcuts to the resources they need.

Contact information

Always have a contact person for the wiki. Encourage people to edit the wiki themselves if they feel comfortable, but provide a way for them to contact someone else with changes or new resources if they’re not comfortable working with the wiki themselves.

Related resources and the big picture

Link to other resources your team or community uses (other websites, file repositories, Lotus Notes teamrooms, communities, etc.). Show the big picture: when do people use the wiki, and when do people use other resources? What’s stored where?

Workspace

If you need to store information that doesn’t have a proper home yet, have a area on your wiki where you can store snippets that are still being worked on. That way, the rough drafts don’t confuse people browsing through the rest of the wiki. Use this space to store administrivia about the wiki as well, such as snippets for the sidebar.

Handling information requests

When people ask you for information that’s on the wiki, ask them where they looked for it and what they searched for. After you send them the resource, build the missing links so that people can find it easily.

Duplicate information

If you need to copy and paste information instead of including it, pick one place where the latest information will be, and provide links to that place when you paste the information into other pages. This will help you resolve conflicts in the future. If you can, provide backlinks to where the information has been copied, so that you know where you need to update it.

Meta-information

Document what you need to do in order to update the wiki, where things are, and how information is organized. This helps you teach other people how to use the wiki.

Automatic lists

Many wikis can automatically list the children of a page, pages in a given category, or pages with a given label. Use this feature to save you from manually updating lists of pages.

Pretty vs. editable

Pretty layouts tend to be difficult to edit without breaking. Simple layouts tend to be plain. Depending on your target audience, decide where your wiki will be. Do you expect lots of participation? Keep the page layout simple and avoid advanced macros. Do you work with a finicky group that will only use polished resources? Invest in styling, and accept that you might be the only one adding to the wiki.

Internal vs. external links

When linking to other pages in the wiki, try to use internal wiki links instead of copying and pasting the URLs. Most wikis indicate external links with icons. If you use internal wiki links, you avoid the visual clutter and show people that they can expect to have the same navigation when they click through.

—-

There are more things to share, but this braindump is a good start! Have you come across something like this (preferably with more detail)? I’d love to learn from what other people are doing.

Wiki organization challenge – thinking out loud

I’m working on organizing the training material for three workshops that we’re bringing together. Our goals are to share common practices and tips, while making it easy for people to find workshop-specific information. I should store the information in a Lotus Connections community wiki, as WikiCentral is deprecated. Lotus Connections wikis don’t have the {include} macro yet, so I can’t reuse chunks of material easily. My challenge is: how can I organize the information so that people can easily find what they need?

Here are a few options I’m considering:

  • Create lots of individual pages with links. I can create pages for common information and other pages for workshop-specific information, tying them all together with links. I can create multiple pathways through the information by using links, and I can create navigation pages too. Colour-coding the links makes it easier for people to pick out which link they want to follow. When Lotus Connections adds support for includes, I can use that to create master pages that include all the relevant information. Advantages: Each page is simple and short. Editing is easy. Linking between pages is easy. Disadvantages: People have to view at least two pages in order to get the information they need for a single workshop. Browsing will require a lot of clicking.
  • Organize information by common steps, and put workshop-specific information in sections or tabs. The main organization would be the common steps in the process, which works best if there are lots of common steps. Each page would start with common tips, followed by hyperlinks to sections on the page with the workshop-specific information. Advantages: People see both the common tips and workshop-specific information on one page. They can browse through steps in chronological order. Disadvantages: Including all three workshops on a page makes the page longer. Navigating to the right section still requires more clicks.
  • Organize information by workshop, and provide links to common tips. There would be one page per workshop, with links to additional information and common resources. Advantages: It’s easy for people to see all the workshop-related information. Disadvantages: The pages will get really, really long. People don’t like scrolling.

Fortunately, I don’t have to do things correctly the first time around. I think I’ll experiment with creating lots of individual pages with links. It feels more wiki-like for me. It also makes it easier to grow the wiki as we add more material. If we find that this involves too much clicking, then we’ll have a good idea of which pages we need to combine.