together, in a sense : cscw

{ Category Archives } cscw

8 November 2008

wikis in organizations

In early September, I attended WikiSym 08 in Porto, Portugal, so this post is nearly two months overdue. In addition to presenting a short paper on the use of a wiki to enhance organizational memory and sharing in a Boeing workgroup, I participated on the WikiFest panel organized by Stewart Mader.

Since then, a couple of people have asked me to post the outline of my presentation for the WikiFest panel. These notes are reflections from the Medshelf, CSS-D, SI, and Boeing workgroup wiki projects and are meant for those thinking about or getting started with deploying a wiki in a team. For those that have been working with wikis and other collaborative tools for a while, there probably aren’t many surprises here.

Consider the wiki within your ecosystem of tools. For CSS-D and MedShelf, the wikis were able to offload many of the frequently asked questions (and, to an even greater extent, the frequent responses) from the corresponding email lists. This helps to increase the signal to noise ratio on the lists for list members that have been around for a while, and increasing their satisfaction with the lists and perhaps making them more likely to stick around.
Another major benefit of moving some of this content from the mailing lists to the wiki is that new readers had less to read to get an answer. If you’ve ever search for the answer to a problem and found part of the solution in a message board or mailing list archive, you may be familiar with the experience of having to read through several proposed, partial solutions, synthesizing as you go, before arriving at the information you need. If all of that information is consolidated as users add it to the wiki, it can reduce the burden of synthesizing information from each time it is accessed to just each time someone adds new information to the wiki.

In addition to considering how a wiki (or really, any other new tool) will complement your existing tools, consider what it can replace. At Boeing, the wiki meant that workgroup members could stop using another tool they didn’t like. If there was a directive to use the wiki in addition to the other tool, it probably wouldn’t have been as enthusiastically adopted. One of the reasons that the SI Wiki has floundered a bit is that there are at least three other digital places this sort of information is stored: two CTools sites and an intranet site. When people don’t know where to put things, sometimes we just don’t put them at all.
Sometimes value comes from aggregation rather than synthesis. In the previous point, I made a big deal out of the value of using the wiki to synthesize information from threaded discussions and various other sources. When we started the MedShelf project, I was expecting all wikis to be used this way, but I was very wrong. With Medshelf, a lot of the value comes from individuals’ stories about coping with the illness. Trying to synthesize that into a single narrative or neutral article would have meant losing these individual voices, and for content like this, it aggregation — putting it all in the same place — can be the best approach.
The importance of these individual voices also meant that many more pages than I expected were single-authored.
Don’t estimate the value of a searchable & browsable collection. Using the workgroup wiki, team members have found the information need because they knew about one project and then were able to browse links to documentation other, related projects that had the information they needed. Browsing between a project page and a team member’s profile has also helped people to identify experts on a given topic. The previous tools for documenting projects didn’t allow for connections between different project repositories and made it hard to browse to the most helpful information. But this only works if you are adding links between related content on the wiki, or if your wiki engine automatically adds related links.
For the wikis tied to mailing lists (CSS-D and Medshelf), some people arriving at the wiki through a search engine, looking for a solution to a particular problem, have browsed to the list information and eventually joined the list. This is certainly something that happens with mailing list archives, but which makes a better front door — the typical mailing list archive or a wiki?
Have new users arrive in parallel rather than serial (after seeding the wiki with content).

The Boeing workgroup wiki stagnated when it was initially launched, and did not really take off until the wiki evangelist organized a “wiki party” (snacks provided) where people could come and get started on documenting their past projects. Others call this a Barn Raising. This sort of event can give potential users both a bit of peer (or management) pressure and necessary technical support to get started adding content. It also serves the valuable additional role of giving community members a chance to express their opinions about how the tool can/should be used, and to negotiate group norms and expectations for the new wiki.

Even if you can’t physically get people together — for the mailing list wikis, this was not practical — it’s good to have them arrive at the same time, and to have both some existing content and suggestions for future additions ready and waiting for them.

Make your contributors feel appreciated. Wikis typically don’t offer the same affordances for showing gratitude as a threaded discussion, where it is usually easy to add a quick “thank you” reply or to acknowledge someone else’s contribution while adding new information. With wikis, thanks are sometimes rare, and users may see revisions to content they added as a sign that they did something wrong, rather than provided a good starting point to which others added. It can make a big difference to acknowledge particularly good writeups publicly in a staff meeting or on the mailing list, or to privately express thanks or give a compliment.

Tagged collaboration, conference, cscw, research, wiki

Comments (0)

23 September 2006

surveys and survey software

My group is doing a survey for SI682. I’d rather be doing all-interviews, because I like them better and because I actually know a bit about how to do them. Time is really very short right now, so we’re trying to supplement with the survey. I get butterflies in my stomach because, while I have taken many surveys, I don’t know a thing about writing them, but I suppose this is part of how to learn. You can help our group by taking it. I already realized I forgot to ask where people live (oops), so if you want to fill that in on the last question, that’d be swell.

In the process, I searched the Internet (well, mostly SourceForge) high and low for a tool that would do what I wanted. In the end, there were four that I really wanted to try, and only one that survived the test.

The first I tried, and most promising, was Web Survey Toolbox, from CMU’s HCII. It looked quite good, but unfortunately requires Tomcat, which my host does not support. I’ve also had some unpleasant experiences with Tomcat.

From there, I moved on to try UCCASS. It looked simple and straightforward. Install was quick, and I had created most of the initial survey before I realized it didn’t have a way to view individual responses (so there would be no way, for example, to correlate an answer to one question with that user’s answers to other questions). I could have written code to pull that from the database (I think), but I didn’t want to have to write new code to do this.

I next tried PHPSurveyor. This one gets used a lot. Aside from icons that are an eyesore and require you to mouseover them and wait for the ALT text to figure out what the link does, it looked like it had some good things going for it. Install was reasonably straightforward (though not without some .htaccess troubles), but what killed this project was the steps required to take the survey. Users must either have an email token inviting them to take it or sign up online and wait for a token to be emailed to them. While this is probably great for many situations, I didn’t want to make people deal with this, so it was time for the next application.

This happened to be phpESP. It’s pretty simple, and has limited answer types. With some concessions on my part, though, it could work for this survey. It has some serious shortcomings. For example, if you miss a required question, the page will just appear to reload with no message indicating why. This gets frustrating pretty quickly and it can take a while to realize what’s going on. Still, it’ll work for now.

Have you found something better? I’d love to hear about it. There were a number of apps on SourceForge, but these were the ones that seemed to have the most documentation online, and rather than downloading and installing everything, I tried to go with the ones about which I knew the most.

Tagged software, surveys, transit

Comments (5)

21 September 2006

oh calendar, where art though?

The School of Information is the first place I’ve been in a number of years that doesn’t have a community norm of using a calendaring system. From what I gather, the school’s administrators use MeetingMaker, faculty use nothing, and students use whatever they have with Google Calendar being the most common. Others in the University seem to use Meeting Maker or nothing, except for the lucky few on one of the Exchange servers.

I’m on three teams for courses, with three to five people on each. We’ve gotten pretty good about having regularly scheduled meetings and, when additional meetings are necessary, trying to schedule the next meeting at the end of the previous meeting. That process works okay, but still not as well as when facilitated by Exchange. This also leaves a number meetings which need to be scheduled outside of meetings, as the need arises. For those, we revert to seemingly endless chains of threads of messages.

On one team, we’ve started using a shared Google Calendar, but that’s really only good for keeping track of team meetings we have scheduled. When used as a scheduling tool in groups, the weaknesses — primarily having to seek out other users’ calendars and hoping for appropriate permissions, rather than having the free/busy information shown in context as you try to setup an appointment — quickly make it unmanageable.

I’m whining, I know, but I am going to have to figure something out. After years of taking Exchange’s services for granted, scheduling group meetings by emails back and forth won’t do.

Also: would it be going too far to say that a nontrivial amount of the success we had at Olin, both with involving students alongside staff and faculty in the administration of the school and with student teamwork, was faciliated by having Exchange in our suite of IT services?

Tagged calendar, cscw, meetings, si

Comments (4)