Congratulations : ye have overcome the wiki one*

26 February 2008

Task 19 of the 23 Things program requires me to put a photo of my pet on the library staff wiki. My lilac Burmese cat Lily is already there, in excellent company with 77 other pets:

Lily

I regret that this was quite a difficult task for those who don’t have pets, those who have recently lost their pets, and those who struggle with the wiki software.

I’m not going to go into too much detail about the origin of the wiki; my colleague Dana gives an excellent linguistic rundown on her post so I’ll save myself the time. But I think I’ve made it clear in a previous post that I like the idea of wikis as a means of keeping as much of our corporate work accessible, transparent and current as possible.

There are many reasons why wikis are better than intranets in our setting. For starters, intranets tend to be a top-down method of communication where senior levels of management deposit policy documents and statements to trickle down to their underlings. There is usually little or no encouragement for contributions from further down the food chain. That’s not how we want communicate in a library. Libraries are spaces for learning, creativity and collaboration at all levels of scholarship; that should include the library staff.

Secondly, intranets are usually maintained by a single administrator who uses complex HTML and stylesheets to build pages. While our web managers are quite capable of running a system like that, it defeats the purpose of a horizontal communication tool if we have to email them every time we want to make a change. Documents on intranets tend to go out of date very quickly and become redundant when an administrator has to see to other tasks; staff members are unlikely to pay attention to an internal method of communication if it’s perceived to be constantly out-of-date.

Many of my colleagues seem to have found using the staff wiki quite stressful. I agree with Dana that remembering the special wiki markup language is actually very difficult for those schooled in the HTML encoding used in websites; it’s like learning Dutch after learning German — the languages are similar on the surface, but sometimes their similarity is actively misleading.

For me, learning to use our Swinburne Library MediaWiki software has been a process of trial and error (lots of errors and quite a trial at times). I’d never used a wiki before June last year, but I found many of the help manuals on Wikipedia very useful for both basic and more advanced skills.

Library staff will have noticed that it’s particularly difficult to upload documents to a wiki. This is because wikis can’t really compute the concept of a word processed document; the software makes the assumption (whether good or bad) that if you’re adding textual content, you’ll do it in wiki markup. Uploading images is not an easy task, either.

I was disappointed that my idealistic viewpoint on democratic flows of information is hampered by my pedantry. I found it difficult to search for specific pages on the wiki; no matter which keywords I used, I often couldn’t find the page I was looking for. So I made a decision to introduce categories to our wiki, so that it’s easier to browse by topic, unit or campus for pages of interest. Every time someone adds a page to the wiki, the software sends me an email so I can log in to add the page to a category. This might appear a little intrusive, so please let me know what you think in the comments or on my talk page.

The other problem I discovered with wikis is that attempting to navigate around them can lead users into a bit of an abyss. It’s especially difficult to go backwards. You can click the Main Page link on the left-hand side panel to return to the homepage, but if you’ve come across a page purely by chance you’ll struggle to ever find it again. My response to this problem is to add breadcrumbs to each wiki page in the hope that it’s easier to feel my way around. On our Online Services and Strategies pages, I’ve also added a section for related links at the base of each page to help users find more information or return to an area of interest. If you’d like to do this to your own pages, please feel free. I think it’s a handy trick. Again, please let me know what you think in the comments.

*’ I write unto you, young men, because ye have overcome the wicked one.’ (1 John 2:13)

Advertisements

Feeding time, or why I won’t bother you for weeks

18 January 2008

I wanted to start this post with a quote of unknown origin:

Give a person a fish and you feed them for a day; teach that person to use the Internet and they won’t bother you for weeks’ (QuoteWorld).

For librarians, researchers, business people, students, teachers and gamers alike, the Web is a gift from God. (Well, OK, Tim Berners-Lee—and he’s a very humble man who would despise my comparison!) Australians first saw the Web in 1994; I remember huddling around a computer in the school library watching in awe for half an hour as we loaded a single page. It was magnificent.

We’ve come a long way since then. But the truth is, as much as we love the Web, it’s just another time guzzler. At a personal level, I have enough trouble keeping up with friends and family; at a professional level, the constraints of time are even worse. I’m so far behind in my library journal reading I don’t know if I’ll ever catch up now. And since so much of the literature on our profession, from Lorcan Dempsey to Jessamyn West, is presented in new media, it’s even more critical than ever that I keep up with my blog subscriptions.

A feed reader (aka ‘aggregator’) makes this task a lot easier. In fact, I’ve been using Google Reader for nearly a year now, and I honestly don’t know what I did without it. At last count, I had 110 library-related blog subscriptions, 13 technology blogs and 23 leisure blogs. As soon as everyone signed up for 23 Things, I added their blogs to my subscription base, so now I have … well, over 200.

So, what’s a feed reader?
For that matter, what are feeds?

Right back in the early stages of the 23 Things program here at Swinburne, the blogger known as Trees from the Wood asked a very sensible question: What’s the use of blogs? My response was that, in isolation, they probably aren’t very useful at all. Who has time to keep returning to a webpage just to see if it has been updated?

In the early days of blogging, there wasn’t a solution to this problem. But now we have RSS.

RSS is (yet another) acronym with a disputed meaning. It originally stood for ‘RDF site summary’, which makes technical sense, but most people now maintain in a Web 2.0 context that it stands for ‘really simple syndication’. There are a few others who consider the middle S stands for ‘sexy’. I don’t want to make judgements on what kind of people they might be.

Whatever it’s called, RSS has the potential to make our lives easier, and that defines it as a great web technology. Without getting too technical, here’s a quick rundown on how blogs are converted to the text that appears in your feed reader.

Blogs, like most simple webpages, are encoded in hypertext markup language, better known as HTML. HTML developed as a way to present text in a web browser that would define both its appearance and its structure. Every early webpage was written like this:

<a href=”http://www.toothpastefordinner.com/”><img alt=”toothpaste for dinner” src=”http://www.toothpastefordinner.com/010808/your-genome.gif&#8221; width=”650″ height=”427″ border=0></a>
<a href=”http://www.toothpastefordinner.com”>toothpastefordinner.com</a&gt;

HTML is very logical; the basic concept is that what you start, you have to finish, in this case using opening and closing tags. Most blogging software doesn’t require you to know how to markup your text; you just type your content and the software automatically converts it to a colourful HTML page. The problem with HTML is that it’s ambitious, but not powerful enough to achieve everything we need from the Web. Extensible markup language (XML) is one of the general-purpose languages we can use to make HTML work better for us. XML is less concerned with presentation than HTML; it’s a perfect language for libraries, since it’s more concerned with content than with style.

RSS uses XML to pick the eyes out of HTML.

The news headlines that appear on sites like Yahoo use RSS to strip away the formatting in their HTML, and just present the core content. It does the same to blog posts, providing a snippet of the full post to help you make up your mind whether you’d like to continue reading. In short, if blogs were scholarly literature, we would call RSS an abstracting service.

To make the most of RSS, you need a feed reader. For sheer ease and the ability to integrate with other services, I recommend Google Reader, since it’s Web-based and you can log on anywhere to read your feeds. However, many people prefer desktop feed readers, in which case I’ve seen RSS Bandit come highly recommended.

Whenever you see this sign on a blog to which you’d like to subscribe, click it:

(‘Really, REALLY BIG RSS feed button’, from photopia/HiMY SYeD’s Flickr photos and reproduced under a Creative Commons License)

You’ll be asked where you’d like to feed the content, so choose your feeder and then you’ll be cooking with gas. My only advice is not to subscribe to Digg, as recommended in Task 10, because it’s rubbish. I did, and I regretted it. Two days in, my aggregator was filled with over 200 stupid videos, the content of which was hardly age-appropriate and frequently NSFW, which hardly suits the purpose of this program. If you want something a bit silly but also geared to technology, try BoingBoing.