The Curation of Open Source Websites
I’ve recently spent quite a lot of time trying to improve the TiddlyWiki website, and thought this made an interesting case study – so I’m sharing what I’ve learned here.
Two things made this particular case interesting;
- The product (and, by extension, the website) is curated by an open source community. So there are no face to face meetings, no project team, and an intellectual group of people to persuade.
- Where TiddlyWiki is concerned, the website IS the product – and a sophisticated product at that. This affects every element of the experience. So we have to mitigate the potential confusion that can arise from using the product in “website mode”, to then downloading something that behaves differently to the site (e.g. allowing saving).
The best way to improve the website was to treat it as a community artifact, just like TiddlyWiki itself; the development process would be kept as open as possible, I would make sure there were opportunities for feedback, and that all of this feedback was given due consideration and response.
When considering how TiddlyWiki.com looked a few months ago, I first considered recommending a complete overhaul. But given the above complexities I was persuaded to identify some quick wins, and implement those first, as a path to later improvements.
This turned out to be an effective approach. The quick wins I focused on were search, navigation, download, installation and content. I tried to see the site through the eyes of a new user going through the process of evaluation, download, installation and experimentation, while also allowing for experienced users who might be returning for advanced requirements.
As the site was developed, I shared these improvements with the community, and those interested in giving support stepped up to the plate. The feedback was intelligent and very helpful. Together we’ve worked towards a version of the site that has just gone live (yay!).
In my agency days, we’d always warn clients against the perils of designing by committee – a slow route to a messy solution…and one could say that an open source community is the ultimate committee! But the subtle dynamics and conventions at play within the community helped keep the usual problems in check. For instance, there was little or no posturing. And I received a lot of encouragement and support.
And it’s interesting to consider the feedback from the community supplanting the kind of feedback one receives from focus groups and traditional user testing. Most people in the TiddlyWiki community have well-above-average technical skills. I remained cautious about developing a site for these users at the expense of less capable visitors, but still the quality of feedback was very high. I’m hoping I can persuade Julie Starr (of TiddlerToddler fame) to give the site her honest feedback….
If you’d like to deep dive into the artifacts:
- Competitor analysis
- Round one of changes (group discussion)
- Round two of changes (group discussion)
So where are we now?
So far, we’ve only implemented a number of quick (but significant) wins on the website – as mentioned; search, navigation, content, download and installation are all much improved. The end result is much cleaner and, I believe, much less intimidating to the casual visitor. My hope is that we can now observe these improvements in the wild, and take further feedback into account moving forwards.
And talking about moving forward, some of the subjects coming onto the table will be pretty interesting, I think…we’re talking about things like branding, the logo, creating a sandpit area, improved evaluation (playing with different verticals such as GTD), extended download options, and more. There’s still heaps of room for improving the end-to-end experience, and some great suggestions from the community to consider. Watch this space…!
I couldn’t have done all this by myself, and thanks are due to everyone in the community who provided feedback, plus my colleagues Phil, Martin, Jeremy and Fred who chipped in at key moments. Thanks, y’all!