Usability testing for Wikimedia... right now!
(Worrying about) Usability seems to be all the rage in Wikimedia at the moment. I think it’s an important thing to worry about, but we have this problem that we are unable to tell and often even guess, how our projects are perceived by people not already familiar with them.
One quick answer might be Feedback Army, a recently created little service that employs Amazon’s Mechanical Turk workers.
I decided to give it a spin for some aspects of Wikimedia Commons. For US$7 for 10 responses, why not? I sent people to look at Image:Easter_Island_map-en.svg, which was yesterday’s Picture of the Day. Here’s the instructions I gave them:
This is testing the usability of the site, not your ability. If you can’t find the answer to any of the questions, that is itself a valid answer.
- What is this a picture of?
- Who created this picture?
- What file format is this picture in? Is there anything special about it?
- Has this picture been judged to be a good one or not? How can you tell or not tell?
- How many versions of this picture have been uploaded? By which users?
- Would you be allowed to use this picture to create a paper map for sale? How can you tell or not tell?
- What date was this page last edited?
And a few questions about you:
- Are you male or female?
- What is your age?
- Have you ever edited a wiki before?
#1 is a gimme to make sure they’re sensible people. #2 is asking people to find the “Author” field in the description below the image. #3 was partially just curiosity about people’s awareness of SVGs, although most respondents picked up on the template:translation possible.
#4 is about the FP (featured picture) and POTY (picture of the year) markers. #5, as a couple of respondents noticed, was ambiguous — unintentionally on my part. I was actually referring to different uploaded versions present under the “File history”, but different translated images are listed in a section called “Other versions” so that was poorly worded on my part. 5 people responded about the translated images, 3 about the file history section, 1 pointed about the ambiguity and 1 didn’t respond.
#6 was about the Creative Commons BY-SA license. Partly it tests if they can locate that information, and partly it tests if they know (or can quickly find out) what that means. So partly it is a test of Creative Commons’ marketing I think. :)
#7 is one that is intentionally a bit confusing. The last version of the image uploaded was at 23:43, 22 October 2008, which is available directly on the page, but the time the page was last edited has to be found from the History tab. (It is 22:11, 24 November 2008.) Exactly half of respondents picked each answer, October or November.
#8, 9 and 10 are just basic demographics.
You can read all the responses on Feedback Army, or better read responses as a spreadsheet that I put together in Google Docs.
So these are just some very quick checks. Other interesting things to check would be if people can navigate and understand history pages, navigating categories, and then obviously editing and uploading.
What questions would you ask? Would you change any of the above questions?
Video: Pia Waugh talking about Open Source Futures
VITTA keynote: Pia Waugh on Open Source Futures from blip.tv
This is a video that I took at the VITTA conference (Victorian IT Teachers Association). I was there giving a workshop about using Wikipedia in the classroom (session 1202), and Pia was there keynoting (1601 — the video above) and talking about OLPCs in Australia (1307)! She was also kind enough to let me license it CC-BY-SA.
While there I also caught up with Donna Benjamin (1207) and Pru Mitchell (1203) — we three had the bad fortune to all be scheduled in the same time slot. Although with 20 simultaneous sessions, it might not be avoidable.
By comparison with ACEC, this conference had a much better representation of open source software advocates amongst its speakers. The Linux Australia stand in the exhibition was getting excellent traffic throughout Monday.
My workshop went well; the first time I’ve done anything like that, but the participants seemed engaged enough. 50 minutes is not really long enough for anything substantial, and I think a better ratio than 1:20 would be more helpful, but it’s a start!
'Hacking MediaWiki (For Users)' video
(Hacking MediaWiki [For Users] on blip.tv)
This is a video of a talk I gave at the November Linux Users of Victoria meeting called “Hacking MediaWiki (For Users)”, talking about ways to extend and modify MediaWiki on the “wiki side”, without need admin access to LocalSettings.php (and everything else). Preparing the talk inspired me to write about why I love MediaWiki.
It covers subpages, links, templates, categories, namespaces, special pages, modifying the interface, skins (CSS & JS), magic words, the Gadgets extension and the “uselang” hack. It’s basically for power-users, I would say.
Many thanks to Ben for the excellent quality recording. The audio in particular is very good. He also cut it down to size and uploaded it which are those annoying things that nobody particularly enjoys doing, so thankyou.
The slides can be downloaded from Wikimedia Commons (direct link). When Slideshare wakes up I will put them up there too.
Wikimedia Commons manual on OLPCs
What is this interesting screen? It’s a page from the FLOSS Manuals book on Contributing to Wikimedia Commons that you may remember me writing about a while ago.
FLOSS Manuals’ head honcho Adam Hyde explains:
The One Laptop per Child (OLPC) roll out of 100,000 laptops has begun. The exciting news is that the laptops now carry the documentation created in FLOSS Manuals embedded within the ‘Help Activity’. […] The manual was written in FM and then remixed using our remix feature, output to HTML and included on the laptop. Since all chapters are written in a modular way it was possible for the OLPC crew to add chapters from other manuals in FLOSS Manuals.
The main exciting bit is the OLPC Laptop Users Guide, which is also available to purchase. The Wikimedia Commons material really got tacked on the end. But still: 100,000 OLPCs going out into the world inviting people to contribute to Wikimedia Commons! It gives me a little spine tingly. Thankyou Adam and FLOSS Manuals for providing the platform and encouragement to make this possible. :)
InstantCommons lives -- and why it matters
OK, my NaBloPoMo definitely failed. Nonetheless.
Something that was introduced to MediaWiki with little fanfare was wgForeignAPIRepo. This allows a MediaWiki install to specify another wiki to pull images and other media files from. Like, say… Wikimedia Commons!
This is an idea that has a long history under the name InstantCommons. One of the main reasons Wikimedia Commons is cool is that it can be used as a media resource as if the files were uploaded locally by all the Wikimedia wikis. So “InstantCommons” is about extending this aspect of Wikimedia Commons behaviour to any MediaWiki wiki.
I enabled it for the Wikimedia Australia wiki. All I needed to do was paste these settings into the LocalSettings.php file:
Now, on the front page, there is a colourful map. Clicking through to the image page shows the full image information from Wikimedia Commons, as well as a subtle hint as to the image’s origin:
I wrote to wikitech-l to ask about what the plans for future development of this functionality is. The response was pretty quiet, although Chad is planning to do some dev work on it which is awesome.
There are two big obvious gaps in the functionality at the moment. The first is that third parties using InstantCommons don’t have any way of knowing what happens to the images they are using. While wiki resources such as Wikipedia and Wikimedia Commons may look stable from the outside, editors know that they are anything but. Especially with images, as there is no straightforward way to move/rename images. This means images get deleted and re-uploaded under their preferred name. Copyright violations are also rife among uploaded files, much more so than contributed text I would guess. Not to mention that the community understanding of international copyright is constantly being negotiated and argued. It’s very tricky; not straight-forward at all.
So this is one thing. It is nice to know when images that you use are deleted so that you can remove the ugly redlinks from your pages. But you on your third party wiki have no way to find this out locally: deletions at the other location won’t appear in your local logs. There are a couple of choices:
- When first using an image from the central repository, copy it locally and from that point on only refer to the local copy.
- Create an automated log that you can follow that lists changes at the central repository, that relate to images that you have used.
- Allow a bot from the central repository to update/remove images for you.
The first option seems good but depending on what your wiki is and how you run it, you may well want to keep up to date and, for example, remove known copyright violations.
The second is a good option but may not be very popular. A similar concept was created for Wikimedia wikis, known as CommonsTicker. However my observation is that using the CommonsTicker has not been a very popular choice. Wikimedia wikis might get pissed when an image gets deleted that had been on their front page, but that doesn’t mean they’re prepared to drudge through the CommonsTicker log on a regular basis.
The third has been most popular in the Wikimedia universe. CommonsDelinker is a bot that runs over all 800+ wikis of Wikimedia and removes redlinks to images after they have been deleted at Wikimedia Commons (if the local community has not, in the meantime, removed the link themselves). CommonsDelinker also comes with a manual (the code is under the MIT license) and with some minor tweaking might be usable by third parties. It makes more sense for third parties to run the bot themselves, rather than Wikimedia Commons, due to configuration differences.
The other gap in the functionality is that there is no way for the central repository to know which of their files are being used and where. For Wikimedia Commons, we generally like to be able to find out what impact our actions will have — especially if, say, WikiTravel was using our content. Actually this problem is by no means well-solved even for the Wikimedia universe — we rely on a toolserver tool called CheckUsage. If the toolserver goes down, Wikimedia Commons admins have no way of knowing what impact their deletions may have. This still needs a MediaWiki-native solution.
Why is InstantCommons important? The Wikimedia Mission is to disseminate freely-licensed educational content effectively and globally. For Wikimedia Commons, what could constitute more effective dissemination than letting every MediaWiki wiki use its content so easily and transparently? Not a single thing that I can think of.