Monday 22 December 2008

The shop metaphor

It's generally difficult to get points about web management across to people who are not web experts themselves - and that, unfortunately, likely includes all the people with any kind of power over the web in your institution. Whether you're dealing with complete novices ("Can you explain what you mean by 'home page'?") or with power users who have latched on to a particular concept as the solution to all things web ("But having more pages will help our search engine optimisation!"), you'll find it distressingly difficult put across what you *mean* when you talk about the web.

That's where metaphors come in useful. If you relate the web to something more familiar, and then get people to think about that instead, suddenly the expressions of confusion or of mulish determination are replaced by - joy! - understanding . Unless you're dealing with complete idiots (and I haven't yet).

The metaphor I find myself using most is that of a shop. People understand shopping. They know that shops are there to sell stuff, and that people go there to get what they want and then get out. All of which makes this a great metaphor for a website.

Sample uses:
  • Case for collecting web stats beyond "how many hits did we get on our site": say we have a shop; measuring hits is like measuring how many people look at the shop window. There's some use to it, but what we really want to know is how many people came in, and how many bought something.

  • Reducing use of explanatory text: if you ask the shopkeeper where something is, do you want him to tell you, or do you want him to spend five minutes telling you why the thing you want is so great?

  • Calling things what they are: which makes you think less, an aisle called "tea and coffee", or one called "variety of hot beverages"?
I'm sure you can come up with your own exampes, and I am equally sure that my metaphor breaks down at some point. But I haven't found that point yet!

Any advances on good web metaphors to use?

Friday 19 December 2008

Things I've learned that make life easier #1: Don't put things right - yet

When you're dealing with information, it's easy to focus on the job at hand. You're the information expert, after all, and chances are that, from your perspective, *everyone* else is doing information the wrong way. Heck, leave out "from your perspective".
It's very easy to want to put things right, straight away. So you feel you've made a difference. Out of a sense of professional pride. In self-preservation - you're the one who gets the stick if someone else realises how rubbish the information is.

Resist that urge.

If you start putting things right straight away, three things will happen. One, you will find that putting things right is a *lot* more work than you would have ever thought possible. Two, it will be difficult to get help for the stuff you need help with, because no one sees there is a problem. Three, you will get nothing like the recognition you deserve for the work that you do.

At the start of a new job, take some time to get to know the problems that are there. Write lists, critiques, action plans; anything that will document the work that needs doing in a way that your managers can appreciate. Depending on the environment you're working in, you may have months, weeks or days to do this in - but make sure you do it. And make sure, before you start putting things right, that your managers are aware of what you're going to put right, how much work it is, and what help you will need.



Tuesday 1 July 2008

First day at conference

Conference is very exciting. Yesterday's sessions were not vastly great - one was a sales pitch for a product, and the other was fairly technical on the DLHE survey, which I don't have a hand in running. But what's great is being around a load of other people who do the same work you do, and being able to have totally random conversations but also talk about work stuff without feeling like you're imposing on others for "talking shop". Since I get most of my ideas sorted out in my head by bouncing them off other people, it's a great atmosphere to be in.

And because of the wiki, I already knew a few names so I had no trouble finding people to talk to. Just for that it's worth having done it. Which is just as well, because I have a feeling that with all the good will in the world it will die a death after the conference - I can't see people signing up after the conference even if we do have some of the presenters updating their pages. We'll see.

One gripe: a conference about the impact of technology, and you don't arrange for conferece-goers to have wi-fi access in the conference areas?

Thursday 26 June 2008

A few things I learned from setting up a wiki

Bringing together the learning points of my foray into wiki creation and administration (note: I'm (clearly) not an expert or anything, so my learning points may not necessarily be examples of absolute best practice):
  1. If you need to compare wiki platforms, you could do far far worse than consult WikiMatrix. This tool lets you compare your choices from roughly 100 platforms across a range of attributes. It even has a handy Wiki Choice Wizard which helps you narrow down your choices.
  2. If you're going to make test wikis, create them as test wikis and give them test names! You will inevitably find that you want to experiment with settings, and for certain fundamental settings (e.g. whether it's a business or individual wiki) you can't do so without deleting the wiki and starting over. For some services, PBwiki amongst them, once you delete a wiki the name becomes unavailable forever; so if you need to delete your test wiki, you don't want it carrying the name you were going to use for the real one!
  3. Make sure you get in touch with any relevant Marketing and Communications or IT people to check that your wiki does not contravene their web marketing policy. This could be within your institution or, as was the case with me, within the organisation running the conference the wiki was for. Some talk beforehand about what you can and can't do will save you the hassle of re-writing later.
  4. Consider giving freedom of writing access to your wiki. My wiki requires people to e-mail me (the administrator) to enable writing access, and it's turned out to be a real barrier to people editing and adding pages. Also, it's been extra work for me administering this aspect of the wiki (though I have enjoyed getting in touch with new users).
  5. Don't just assume people will get in touch on the wiki - offer them reasons to interact with others, and make it easy for them to do so. I added a "Travelling together" page to the wiki to encourage users to club together for cab rides from the closest train station - it's been quite popular! I also added a template for creating a personal profile page.
  6. Participate yourself if you want others to (that probably goes without saying). Comment, write, and add, and others will soon follow your example!
I could probably write a deal more, but for now, that's all, folks!

Wednesday 25 June 2008

Creating a wiki - details of the process

I'm going to a Careers Information and Employer Liaison conference next week, the topic of which is the impact of technology on our roles in careers. Given the topic, I had assumed there would be some sort of conference wiki along the lines of this one, and I was looking forward to contributing to it and getting to know some of the conference attendees beforehand.
I asked, and there wasn't one, and you can see where this is going. You are reading the blog of the administrator for the conference wiki. Admire it.

Setting up the wiki wasn't too difficult. By far the hardest part was choosing what platform to host it on - I was basically looking for a free, web-hosted product with no adverts and the ability to make the wiki editable only by people who signed up. I looked at quite a few platforms and created test wikis in three, and in the end decided on PBwiki. I wouldn't say it was perfect, but then, a lot of the extras that would have been nice are in the paid edition, and I guess they have a right to charge for the extra functionality.

Then came writing the content. How much to write? What would interest people? How much time could I realistically afford to spend on the wiki? How could I encourage people to add their own content? I know I haven't got the answers completely right, but I guess it's a learning experience. I thought of things I would find useful pre-conference, and tried to get those going - e.g. a page to arrange to travel with others, and personal profile pages for people to introduce themselves. Others may add their own pages, though this close to the conference I think that's unlikely.

I interrupted work on the wiki when I was told that the Marketing and Communications people of the organisation running the conference wanted a word with me. Cue nightmare visions of wiki being taken down because not brand-compliant. Fortunately, they turned out to be really nice people who just wanted to make sure that I was linking to their site where appropriate rather than duplicating content. I did take down a few pages I had written - but it could have been so much worse. That'll teach me not to check with people!

Now I'm at the stage of encouraging people onto the wiki. Ideally this process would have started earlier - the wiki was only really ready to be advertised about a week before the conference starts. But you take what you can get. I have e-mailed conference goers to alert them to the wiki; the e-mail gives them some idea what they can do that would benefit them. I am also building in the option to use the wiki after the conference for post-session discussions and networking. Fingers crossed!