By Meredith Farkas | March 22, 2006
Note: I’m going to put my own editorializing in italics to keep it separate.
Ok, so they said we wouldn’t be able to get a signal in the ballrooms, but low and behold I seem to be getting a good signal! Rock on!
Update: Ok, nevermind. Once they closed the doors I lost it.
Well, obviously I couldn’t miss a talk on wikis, especially ones that I can’t see online (Intranets). Michael Stephens is introducing the speakers (all 7 of them!). He is such a hottie!
Wikis@Binghamton by Abigail Bordeaux, Erin Rushton, Marcy Strong
One thing I’m surprised by is the fact that the speakers just jumped into talking about Wikis as if people knew what they were talking about. I’d love to believe that everyone in the room already knew about Wikis, but experience has told me otherwise. I think it’s great to talk about implementations, but it’s also important to actually explain what a wiki is.
They are talking about their staff intranet wiki, how it was planned, implemented and used.
They’ve had a staff intranet since 2001 that is a regular Web site with few collaborative features. They first started playing with hosted wikis like SeedWiki in early 2005 to collaboratively edit documents and to work in committees virtually. People were using lots of different types of Wikis and each implementation had different syntax rules. Decided they wanted something they knew would always be free that they could have some control over. So they decided to have a locally hosted wiki of their own.
First started using JotSpot to work on editing their strategic plan. People could add comments to the document rather than editing it.
Formed a task force in Aril 2005 to create a more permanent wiki intranet. They researched and reviewed open source Wikis. Wanted the ability to handle Unicode and mathematical stuff. They decided to use MediaWiki in May 2005 and installed locally in July. Added content from the Intranet and from some of the other Wikis they had been using. They created help files and style guides and will be developing templates. They are trying to decide whether they want a traditional intranet with a wiki or a wiki that is an intranet.
How the wiki is used – Wiki is linked from the Intranet and was announced in the news section of the Intranet. They have a vanilla version of MediaWiki and haven’t done much customization beyond their logo. Committees are using the Wikis to post agendas, edit documents, upload documents to have a repository of files.
It doesn’t seem like collaborative editing is the only thing they use the wiki for. They seem to use it also because it’s just easy to add info to it and to upload files.
People are using the wiki to post their conference reports, which they can easily do on their own on a wiki (as opposed to a Website which they might not have permission to do). People are starting to collaboratively create reports when more than one person attend the conference.
They are considering doing a wiki for the public, but are not sure if that’s something they could do at their library.
Help files – they took a lot of content from the WikiMedia foundation files and modified it for their own use. They have an intro to Wikis, how to read Wikis, and how to edit Wikis. They also have a link to the WikiMedia site where they can learn about some of the more sophisticated wiki functions.
Training sessions – Hour-long interactive sessions in the computer lab. Asked participants to bring a file to work on that might continue to live on the wiki. They look at the Wikipedia entry on University of Binghamton and looked at the revision history. This got people used to the wikipedia.
They have a Sandbox where people can play with the wiki without feeling like they’re going to break it. This is a really good idea. It might be less intimidating for people who may not use a wiki otherwise. I should add a Sandbox to the Wikis I’ve created.
There have been some barriers to people using the wiki. People are freaked out about editing other people’s content. People were concerned about breaking the wiki. People were concerned about having things changed that they put on the wiki – they wanted to protect pages, which they are not currently doing on the wiki. Some people have problems with the wiki syntax which allows some HTML but also has its own syntax.
From my own experience, I think these are very normal problems and usually people get over it with experience
What did they learn – hands on learning in wiki training is important.
Wikis in Action – by the folks at the Health Sciences Library at Stonybrook. I missed their names, though I know one of them is Darren Chase.
Oooh! They’re using Jessamyn’s slide template. OVERDUE!
They have 35 staff members in the health sciences library with diverse skills and knowledge. They are also working on a wide variety of projects that others may not even know about. So they recognized that they needed a communication device to keep up with each other.
Needs: a space for collaboration, documentation of policies and policy changes, FAQs and help files. They wanted in-house control, they wanted it readily available, easy to change, and easy to use.
They tried a few other things and explored other options including shared files, static HTML pages, CMS, and a blog. They actually had one shared Excel file that grew to over 14MB. Recognized that they REALLY needed a better way to share info. Static Web pages required that people know HTML and people have different levels of ability. I know from experience that too many cooks can really ruin a Web page I almost died when someone edited a page I’d created in MSWord and I ended up with 14 pages of horrible markup for a very small page when I’d created a style sheet for the page! UGH!.
They tried a bunch of Wikis before finding one they liked. Tried PHPWiki first, but it didn’t have security built into the wiki. Didn’t provide a WYSIWYG ability. DokuWiki and Kwiki didn’t provide the level of security they needed. WikiWikiWeb didn’t have an easy-to-use WYSIWYG interface. MediaWiki seemed like overkill to them and they didn’t want to spend a lot of time configuring it (hmmm… don’t know about that. I spent 45 minutes installing and setting up the ALA New Orleans wiki. But I understand that it’s probably not always the best option out there for every need).
They ended up with Twiki which was easy for people to edit and allowed them to easily control access. They have file locking so people can’t edit the wiki at the same time. You can set up different Webs to compartmentalize the wiki. Good version control. Lots of plugins to extend the functionality of the wiki.
I’m not familiar with Twiki, so I will definitely have to check it out after this. Though MediaWiki does have most of those features.
Twiki reaquires Linux, Apache, Perl 5.8, Perl Modules (which are installed automatically). Now I know why I didn’t want it. I’m just a PHP kinda gal. But it does look like a really nice wiki
Darren Chase is talking about how they populated the wiki. They pre-organized the wiki on the main menu. Good idea! Keeps things from getting totally disorganized. Had a projects menu where there is a list of different projects where people can describe what they’re doing and can use the wiki as a project space for collaboration. People can personalize their sidebars so that they can keep links to the most important things to them.
Darren is showing off the wiki in real-time. Twiki has a really nice WYSIWYG environment that makes it easy for people who are familiar with Word to use it. Must say, that is a lot nicer (easier to use) than MediaWiki.
Wikis make it easy to shoot off fast announcements. Their wiki is really well organized so that you can find a specific project in the projects menu or by looking at the menu for the specific division that is doing the project.
Access Services using the Wiki as a manual that is easy to update. People can easily add announcements about printers breaking at midnight when no one who can help is there. Therefore, it can be taken care of in the morning. They have info for student workers that they can look up when the staff isn’t there.
They are introducing the wiki in staff meetings and find that it only takes about 15 minutes to teach people how to use it. They are really encouraging people to add their knowledge to the wiki so that anyone can benefit from it. YAY!
I think the big difference between these two groups is the fact that Stonybrook staff had a need and discovered that a wiki would be a good fit for that need, while Binghamton was playing with Wikis even though there may not have been a specific need. And I think it’s obvious in how the Wikis are utilized. The wiki at Stonybrook is really well-organized and well-used. It really is an integral part of their daily worklife. At Binghamton, people seem to be hesitant about using it because they really don’t have a pressing need to use it.
Chad Boeninger – Wiki as a Research Guide
Chad is the Business Librarian at Ohio University. Chad talked about how students have asked him how they can reach him when he’s not at the library. He decided that he could create a wiki to have his knowledge out there on the Web so that students wouldn’t necessarily need him all the time.
Chad created three research guides for the business students (remember, there are A LOT of business resources out there in different sub-subjects). He also inherited a lot of the resources in the guide from an old Business Librarian. He found that Web-based guides were a real pain to maintain and make changes to. Much of the information in the guides was redundant, so if he had to make a change to one, he’d have to make it to all three. The guides weren’t searchable or interlinked. Chad realized a wiki would make life much easier for him and for the students. Interlinked articles and the ability to search would make things more finable. For him, Wikis are MUCH easier to make changes to.
Reasoning for choosing MediaWiki: if it’s good enough for the Wikipedia, it’s good enough for me. that was pretty much my rationale too.
For each resource in the wiki, Chad provides the format, the location, and a description of the resource. He also categorizes each resource (putting most into many categories) to make them easier to find.
Students often contact Chad when they have a business question rather than going to the reference desk. With this wiki, the reference librarians can also offer subject help. He’s come up with a lot of tricks to help the reference librarians and students find the things that he may have mentioned in instructional sessions. Prevents the “Chad mentioned a book and it was green” sort of issues.
Wikis make excellent teaching tools as they’re more permanent than a handout. They also can be added to or changed based on the discussion during the instruction session. He creates handouts on the wiki and then links to the resources described in the wiki. It’s so cool that he can link to things rather than just alluding to them on a handout. HOT!
Chad ads info on the fly to answer specific questions. When students have questions that he answers, he adds that info to the wiki since other students may likely have the same questions.
Chad tracks usage by looking at the number of people who have accessed each page (this info is shown on each individual page of the wiki). It can help him to know which things students are most interested in or are having the most trouble finding resources for on their own.
Chad isn’t really using it for collaboration, though he had originally left it open to be edited by students and professors (and no one else added to it). He’s using Wikis because they’re SO easy to edit and because the creation of categories, interlinking, and the ability to search makes things more findable. This is proof positive that Wikis can be useful for much more than collaboration.