Supporting Editors' "Desire Lines" / Volunteer Toolkit
Supporting Editors' "Desire Lines" / Volunteer Toolkit
I am not exactly sure if this is the right place to post this, so forgive me if it's not :-)
One thing I have observed since joining Wikimedia in 2007, is that the editing community seems to have, over the years, created a ton of hacks and workarounds to support stuff it wants to do. These hacks developed organically in response to editor desires, but many of them are clunky and/or not very powerful, and/or not very user-friendly. It seems to me that there would be a lot of benefit to creating really good tools to make it possible for editors to do the work that they're currently trying to do, more easily and more powerfully. Essentially: taking what people are already trying to do, and creating tools that help them do it better.
An analogy from the urban planning world that I've shared with Eugene and Philippe: when urban planners are designing a park, they used to say “the path should go here,” and then build the path. Today though, they often build parks without paths, and then wait to see what paths people naturally want to take. Once the paths emerge naturally (and are visible via trampled down snow or flattened grass), THEN they know where people want the path, and they build it there. You end up with a better, more useful path, because it's based on what people actually want, rather than a guess at what people might want. The trampled down snow/flattened grass path is called a “desire line” or “desire path” http://en.wikipedia.org/wiki/Desire_path.
I have always loved the desire lines concept, and I think it's very applicable to us. So what I am suggesting here is that we consider the workarounds/hacks that have developed over time to be “desire lines,” and build tools so that editors can accomplish the same goals more easily.
- Editors clearly want ways to “sign up to receive” certain kinds of information that interests them – e.g. I want to read the Signpost, I want to know when there is a meet-up in San Francisco. Currently, there is no one-stop shop where I can see all my subscription options, and easily manage them.
- People are interested in doing some kinds of editing, but not all kinds of editing. I may be interested solely in copy editing and text smoothing. I may be interested in adding citations to fix up articles at risk of deletion. I may be interested in Persian literature. I may be interested in editing in Russian and English, but no other languages. Currently, there is no easy way for editors to self-identify as available for particular types of editing opportunities, and be notified of work that interests them. (E.g., “Here are forty articles that need copy smoothing. Here are a WikiProject related to Persian literature.”)
- People want to “watch” certain articles, and be notified when they change. There are probably ways we could make watchlists easier to manage, and offer more notification options.
- People want ways to self-organize around common goals (i.e., quality-improvement projects such as the Marxism task force and the WikiProject Israel Palestine Collaboration). Currently this is super-difficult because there are no real tools supporting it – it is hard to find new projects, it is hard to publicize the existence of a new project, and it is hard to do outreach to non-editors in support of a project. There's probably a whole set of supportive features/tools that could be created to better support editorial project work.
- People want ways to assess article quality, and they want the assessments to be publicly visible. Experienced editors seem to have developed good, rich, broadly-agreed-upon criteria for assessing quality, but the mechanism for assessment seems to me to be pretty opaque to outsiders, and the labelling isn't necessarily understandable to the general public.
- People want ways to label problems with article quality, and flag those problems to other people so they can help fix them. This is where templates come from – the desire to warn other people of problems (“this article seems biased,” “this article has no citations,” “this article has been nominated for deletion”), and to ask for help in fixing them. There are probably a lot of ways that labelling could be improved so 1) it is easier to label, 2) the labels are more understandable, and 3) the calls for help are directed to the right place.
Those are just some examples off the top of my head. But the basic concept here is I think an important one. I believe we (collectively) have a lot of editing experience – over time, we have learned what kinds of work we want to do, how to do it, and what kinds of tools we need to support it. I believe that energy dedicated towards creating user-friendly tools to make it easier to do the stuff people are already trying to do via hacks and workarounds, would be really powerful to 1) support existing editors, and 2) make it easier for new people to edit.
(This comment by the way has some overlap with http://strategy.wikimedia.org/wiki/Proposal:Volunteer_Toolkit.)
My intuition tells me that community health is really a usability issue. A lot of data confirms that. If the tools are complicated and brittle, we exclude new users. But also keep this in mind: if the tools are complicated and brittle, we also make things harder for our best contributors, and they end up wasting a lot of time and energy. I think that there's a huge opportunity here to improve the experience for new editors, while also making the experience better for veterans too (if they can stomach losing their old processes and switching over to new ones).
You listed a lot of good examples. I think research tools are an important gap. Most of our content policy is really rooted in verification, which can be annoying but necessary. Editors have made these elaborate citation templates, but imagine those were "What You See Is What You Get", or if we even had citation tools that could automatically produce a citation. Editors have made lists of reliable sources that they troll through one by one, but imagine how much easier it would be to verify something if you could just throw a word into a search engine that only goes through trusted domains.
Either way, I think a comprehensive volunteer toolkit will be one of our recommendations.
A meta-note about desire lines as they apply to Wikimedia: I love the analogy. Do we have the ability to actually watch where people are "walking" on our wikis? If not, what would we need to get this capability?
It would be really interesting to focus group this... from a research point of view, I'd love to have a virtual one-way-mirror to some opt-in participants....
Figuring out where people are walking offline is tricky, but not necessarily hard. Many offline tools have been legitimized:
- Google scholar, google news, and google books are linked right off of every AFD. Editors are constantly looking for sources.
- Link-checks and activity patterns are linked right off every featured article nomination. Editors are checking for technical issues, and also trying to understand who is contributing.
So even without knowing traffic patterns, the fact that they're so prominent gives us a good hint as to the "desire path".
But there are a ton of tools people have already made: Templates! A quick look at those will show you the kinds of tools people need.
- Citation templates are probably among the most used templates.
- So are infoboxes.
- Quality assessment templates.
- Various "problem" tags are up there too.
It's not hard to see exactly what the community is trying to do, but has a hard time doing with the tools they have.