No "Thing" this time. I spent the whole evening looking at the blogs of all the Nebraska Learns 2.0 participants.
Yeah. All of them. Four and a half hours on a Saturday night. I can't promise that I read every single post on each blog, but I did visit every blog, and I did read at least a couple posts from each participant. For the handful I'd already been following via RSS, I re-read my favorite posts.
It's sad, but not surprising, how many folks made it only through the first couple of things, then dropped out. I was almost one of those, with my month-long lapse. I'm really glad I decided to pick it up again and run with it. I am determined to finish by the deadline.
It was definitely worth the time to visit all the participants' blogs, and not just because of all the pretty Flickr pictures or the fun YouTube videos. I really enjoyed reading everyone's comments on Things 11 and 16. A lot of folks wrote deep, thoughtful essays about technology and Library 2.0. I plan to add my favorites to the Nebraska Learns 2.0 wiki later, when I'm at a computer with a browser that's compatible with PBwiki.
Well, it's way past my bedtime, so I think I'm going to call it quits for tonight.
Showing posts with label wiki. Show all posts
Showing posts with label wiki. Show all posts
Saturday, January 24, 2009
Tuesday, January 20, 2009
Thing #18: PBwiki
Somehow it seems cosmically wrong to be working on Thing #18: Playing around with PBwiki on the auspicious day of President Obama's inauguration. Nothing can compare to the power of that event, but I must work on these things whenever I have the opportunity. The deadline is near for Nebraska Learns 2.0, and I need to keep moving.
After looking at the discovery resources for PBwiki, I was very excited. It looked so very easy compared to Wikipedia and the Confluence wiki software we use at my library. I was thrilled by the promise of simplicity, a wiki easily accessible to all.
And then I clicked on edit, and discovered that PBwiki is completely incompatible with my computer (or at least my browser) at home. After numerous retries and reloads, I eventually got something other than a blank page. But the page I got was filled with strange code and odd blocks of color--definitely not a friendly display. So I gave up. (Side note: This was rather a surprise. I have no trouble editing Wikipedia articles from home, and I did not expect PBwiki to have higher browser requirements than Wikipedia.)
Now I'm at the library, using a decent computer. I went to PBwiki and clicked edit, and I got exactly what I should have: a simple, user-friendly, editable page. I edited a couple of pages on the Nebraska Learns 2.0 wiki, and it was easy and intuitive in a way I would never have expected from my previous experience with other wiki software. By hiding the markup code behind a rich text editor, they really made their wiki friendly and nonthreatening.
PBwiki would be great for a public wiki that a library wanted to share with its patrons. It would also make a very nice internal staff wiki. It's very nice. If I ever need to set up a wiki in the future, I would seriously consider using PBwiki as the platform.
After looking at the discovery resources for PBwiki, I was very excited. It looked so very easy compared to Wikipedia and the Confluence wiki software we use at my library. I was thrilled by the promise of simplicity, a wiki easily accessible to all.
And then I clicked on edit, and discovered that PBwiki is completely incompatible with my computer (or at least my browser) at home. After numerous retries and reloads, I eventually got something other than a blank page. But the page I got was filled with strange code and odd blocks of color--definitely not a friendly display. So I gave up. (Side note: This was rather a surprise. I have no trouble editing Wikipedia articles from home, and I did not expect PBwiki to have higher browser requirements than Wikipedia.)
Now I'm at the library, using a decent computer. I went to PBwiki and clicked edit, and I got exactly what I should have: a simple, user-friendly, editable page. I edited a couple of pages on the Nebraska Learns 2.0 wiki, and it was easy and intuitive in a way I would never have expected from my previous experience with other wiki software. By hiding the markup code behind a rich text editor, they really made their wiki friendly and nonthreatening.
PBwiki would be great for a public wiki that a library wanted to share with its patrons. It would also make a very nice internal staff wiki. It's very nice. If I ever need to set up a wiki in the future, I would seriously consider using PBwiki as the platform.
Thursday, January 15, 2009
Thing #17: Wikis Ahoy!
Because I have experience with a couple of different wikis, I didn't expect to learn much from Thing #17: So what's in a wiki? To my delight, I was wrong. The Book Lovers Wiki didn't fit my mental model of what a wiki "looks" like. Also, on Library Success: A Best Practices Wiki I noticed the "Random Page" link on the left sidebar. It turns out that this also exists in Wikipedia; I just never noticed it because there is so much other stuff in Wikipedia's left sidebar that my eyes just gloss over it all. But the Random Page link is fun! It's wiki roulette! I believe I've just found my next source of entertainment.
One of the core tenets of wiki wisdom is that "anyone can edit" a wiki. While that may be true, I submit that wiki markup can be intimidating. I've edited in two different wikis: Wikipedia and the Confluence wiki we use at work. Their markup languages are completely different. Not only is neither one like html, neither one is like the other. This lack of standardization means that there is a learning curve not just for wikis, but for each wiki platform. Sure, if you just want to type in a line of text, it's no problem, but if you want to add a link or make a table, you have to learn the markup.
Our Confluence wiki has the option to edit pages in rich text, which does make it much more accessible, even if the rich text editor is a little on the buggy side. Everyone at work is encouraged to use the wiki. In fact, it's almost required. We use it for news, policies, procedures, meeting minutes, projects, discussions, and more. Even so, there are a few people who won't edit the wiki unless specifically told to. And there remains the perception that it is difficult, and some of my colleagues routinely come to me for help whenever they need to edit a page. I'm always glad to help. It's one of my official duties as a SpaceRanger, which is what "wiki power users" are called in my library, but also, I enjoy it. It's fun and interesting. And I always work directly in wiki markup rather than rich text, because I feel like I have better control over what the page will look like.
My library's wiki is strictly staff-only. It's not available to the public, and anonymous edits are not allowed. From Using Wikis to Create Online Communities, I do like the idea of using a wiki as a subject guide, especially if truly anyone could edit. The subject specialist librarian could moderate/shepherd it, to keep it accurate.
As for using a wiki to edit catalog entries, I think that might have to wait until OCLC comes around and makes WorldCat truly open. If all catalogers could edit all bib records, regardless of the encoding level, the bibs would become better. And while the general public should probably not be able to edit the MARC data or the authority-controlled fields, I think it would be great to let users add notes and summaries to records, not just tags and reviews. If a "vandal" were to add false or highly biased information, I'm sure the next cataloger to see it would take care of it. Or perhaps a passionate user might beat the catalogers to it.
One of the things people seem to fear about Wikipedia and other wikis is the threat not only of outright vandalism but of bias and unverified information being added to articles. Having read Wikipedia's content criteria in depth, I can say that such shenanigans are not tolerated on that site. The core Wikipedians are hypervigilant of any such abuses, and any malicious edits tend to be discovered and reversed very quickly. I don't mean "days" quickly, I mean "minutes" quickly. Yes, it is possible that you might see an article before it gets fixed. If you see something that just doesn't seem right, the simple solutions are to a) look at the history pages, and b) check back later to see the next version.
In Wikis in Plain English, when they showed the example of a user starting a page that said, "Pups are cute!" followed by someone changing it to, "Pups are messy!" I burst out laughing and thought, "And now the edit war begins."
Looking at a wiki's history pages can be very enlightening. Edit wars can be educational, if librarians and teachers use them as examples. Oftentimes, you can see both sides of a hotly-debated topic bared in a way you'd never observe from reading static articles.
But the most important thing to remember about wikis is that they are tools. Fabulous and awesome tools, and incredibly useful, but still tools. As Kate Sheehan said, "It’s easy to become enamored of social networking sites and Web 2.0 toys to the point where they seem like a panacea for everything that’s wrong with your library or your job. Slap a wiki on it and call me in the morning." In the end, it's not about the wiki; it's about the people.
One of the core tenets of wiki wisdom is that "anyone can edit" a wiki. While that may be true, I submit that wiki markup can be intimidating. I've edited in two different wikis: Wikipedia and the Confluence wiki we use at work. Their markup languages are completely different. Not only is neither one like html, neither one is like the other. This lack of standardization means that there is a learning curve not just for wikis, but for each wiki platform. Sure, if you just want to type in a line of text, it's no problem, but if you want to add a link or make a table, you have to learn the markup.
Our Confluence wiki has the option to edit pages in rich text, which does make it much more accessible, even if the rich text editor is a little on the buggy side. Everyone at work is encouraged to use the wiki. In fact, it's almost required. We use it for news, policies, procedures, meeting minutes, projects, discussions, and more. Even so, there are a few people who won't edit the wiki unless specifically told to. And there remains the perception that it is difficult, and some of my colleagues routinely come to me for help whenever they need to edit a page. I'm always glad to help. It's one of my official duties as a SpaceRanger, which is what "wiki power users" are called in my library, but also, I enjoy it. It's fun and interesting. And I always work directly in wiki markup rather than rich text, because I feel like I have better control over what the page will look like.
My library's wiki is strictly staff-only. It's not available to the public, and anonymous edits are not allowed. From Using Wikis to Create Online Communities, I do like the idea of using a wiki as a subject guide, especially if truly anyone could edit. The subject specialist librarian could moderate/shepherd it, to keep it accurate.
As for using a wiki to edit catalog entries, I think that might have to wait until OCLC comes around and makes WorldCat truly open. If all catalogers could edit all bib records, regardless of the encoding level, the bibs would become better. And while the general public should probably not be able to edit the MARC data or the authority-controlled fields, I think it would be great to let users add notes and summaries to records, not just tags and reviews. If a "vandal" were to add false or highly biased information, I'm sure the next cataloger to see it would take care of it. Or perhaps a passionate user might beat the catalogers to it.
One of the things people seem to fear about Wikipedia and other wikis is the threat not only of outright vandalism but of bias and unverified information being added to articles. Having read Wikipedia's content criteria in depth, I can say that such shenanigans are not tolerated on that site. The core Wikipedians are hypervigilant of any such abuses, and any malicious edits tend to be discovered and reversed very quickly. I don't mean "days" quickly, I mean "minutes" quickly. Yes, it is possible that you might see an article before it gets fixed. If you see something that just doesn't seem right, the simple solutions are to a) look at the history pages, and b) check back later to see the next version.
In Wikis in Plain English, when they showed the example of a user starting a page that said, "Pups are cute!" followed by someone changing it to, "Pups are messy!" I burst out laughing and thought, "And now the edit war begins."
Looking at a wiki's history pages can be very enlightening. Edit wars can be educational, if librarians and teachers use them as examples. Oftentimes, you can see both sides of a hotly-debated topic bared in a way you'd never observe from reading static articles.
But the most important thing to remember about wikis is that they are tools. Fabulous and awesome tools, and incredibly useful, but still tools. As Kate Sheehan said, "It’s easy to become enamored of social networking sites and Web 2.0 toys to the point where they seem like a panacea for everything that’s wrong with your library or your job. Slap a wiki on it and call me in the morning." In the end, it's not about the wiki; it's about the people.
Subscribe to:
Posts (Atom)
