A few months ago I had the distinct pleasure of sharing some of my experiences and thoughts on outreach and community building for scholarly software projects with the One Week One Tool team as part of the first two days of the summer institute. I was excited at the prospect of sharing my experience, but intimidated by the fact that so many of the participants had already done a considerable amount of work in this field. I like to think our outreach conversation went well!
With a little bit of time distancing myself from the actual event I thought I would work through some of the ideas I put forward to the group. My goal here is twofold, first I would like to share some of our discussion of software and community with folks who were not a part of the event and second I would be interested to hear from the participants about how my ideas did or didn’t resonate with the work they engaged in on anthologize. So below you will find 5 principles and 5 roles I see as critical to scholarly software outreach. I don’t by any means claim to have invented anything here, just trying to share my thoughts on practices. If you’re interested in a more extensive run down of the project I would suggest Tom’s interim report.
Trevor’s 5 Outreach Principles
- Outreach sounds like it starts at the end, but it should be a bit more ever present. It starts with a conception of audiences. Who are the end users? Who can I get to promote this to those end users? Make this part of your upfront planing process.
- Understand outreach as a value proposition for your end users. The more time and energy it takes to get your tool to do whatever it is supposed to do the better it’s payoff should be. Your competing for the end users attention and time. Those are scarce resources. Your tool’s site should establish the problem the tool solves and why this is a great way to solve that problem in as concise a way as possible.
- If possible, leverage existing communities. At this point, whatever you are trying to work on has already been worked on. Are there some interesting open standards that have some solid work behind them? Are there some abandoned tools who’s users you could pick up? If you can offer a clear value proposition to an existing group you don’t need to start from scratch.
- Spending time convincing people who convince people to use your tool can be far more effective than spending time convincing people to user your tool. This has always been the strategy on Zotero. The most effective parts of our outreach have been developing workshops to train folks to use the tool. There is a value proposition here too. If a tool really makes it, being able to teach someone how to use useful software is a credential.
- Look more reputable. People are scared that software will eat their data. Aside from making sure that doesn’t happen, you should try your hardest to make people feel like you are going to stick around for a while. This means that the design of your site matters. Things that look slick, that have active news feeds, that identify who funded them and what the plan for the future is are going to make folks more comfortable. Having a solid reputation is a great goal, but you need to start somewhere, you might even consider connecting the project with things people trust.
Trevor’s Five Components of Outreach
I like to think about outreach as building and engaging with existing communities of software users, evangelists, and potential code contributors. In this view outreach involves at least five very different roles/tasks. Other folks might cut these up and organize them differently, in a big project there could be a range of folks taking on these roles, in a small project they might all fall to the same person.
- Usability: If people are going to use the software you need to get a sense of how folks understand it. In my experience, starting with something like user personas in the initial design phases and pushing out functional software for public use and testing is great. In other cases it might make sense to do much more extensive testing.
- Marketing and publicity: This part is what a lot of folks think of as core outreach activity. Spreading the word about your tool, trying to get it mentioned in the right places, giving talks at the kinds of meetings and conferences your potential users go to, getting coverage of your tool in the kinds of publications your potential users read. This is great stuff, you can’t ignore it. On the most basic level its about crafting a message and getting it out there through a blog or news section. If you pitch your story right you could get picked up by some real big deal blogs and generate some traffic to your tool.
- User Guides and Documentation: After taking a quick look at your homepage the next stop for a lot of users is going to be your documentation. I think one of the biggest problems I see in different projects is that folks think of documentation as technical information and not as part of their outreach efforts. No matter how much you invest in getting people to visit your site, how much you put into getting an attractive homepage, it can all be for naught if you don’t make it as easy as possible for people to figure out how to do what they want to do with your too. The key point here is that documentation is not about describing what the software does it is about telling people how they can do what they want to do with your tool. While you might think the homepage of your site is the front, remember that web search means any page could be the first page someone sees.
- User Advocacy: Once a project has users it also has people outside of the development team that want the tool to do something. Now, a lot of tools don’t ever get here, but when they do it is critical to try to role their interests and voice into the project. If you want users to stay around and become advocates you need to need to have someone advocating for their needs.
- Sustainability: It’s a great word, and in the world of grant funded work it is, for good reason, THE big idea. If anyone is going to fund your project they want to know that they are not signing up to provide you with funding till the end of time. It is easy to gesture toward a user community as part of a sustainability plan, but it is much more difficult to turn people into users, users into promoters and coders, and those folks into a network that ultimately ensures a sustainable future for a tool.
So what do you think? Is this a reasonable way to think about outreach and scholarly software? Are there things missing from the picture? Are there things in here that you think shouldn’t be viewed as part of Outreach? For folks who participated in the One Week event, how did or didn’t these ideas come into play with Anthologize?
Works that shaped my ideas on users, software and community
- Brown, D. (2006). Communicating Design: Developing Web Site Documentation for Design and Planning. New Riders Press.
- Garrett, J. J. (2002). The Elements of User Experience: User-Centered Design for the Web. Peachpit Press.
- Jin, L., Robey, D., & Boudreau, M. C. (2007). Beyond Development: A Research Agenda for Investigating Open Source Software User Communities. Information Resources Management Journal, 20(1), 68-80.
- Krishnamurthy, S. (2005). Launching of Mozilla Firefox – A Case Study in Community-Led Marketing. URL http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.687
Thanks for the great post, Trevor, and for playing a key role in the first few days of One Week. I might have more to say about your post after digesting it a bit more, but off the bat I'll say that the decision to build Anthologize as an add-on for WordPress was directly influenced by your Principle 3. In the same way that being built on the already-popular Firefox probably gave Zotero a leg up, we hoped that building on WordPress would mean a larger potential user base.
Glad to hear that you thought my manifesto was of some value! I would whole heartedly agree with you that Anthologize's use of WordPress is brilliant. It was clear in the early Anthologize conversations I had the pleasure of overhearing that piggybacking on an existing community was a priority and I think that paid off for the team. Your point on Zotero is also well taken.
In both cases, one of the neatest parts is that they each take an existing platform and extend it, but not simply in a way that is useful for folks that use that already use that platform. For Firefox users Zotero made sense as an extension, and we ended up getting some great cross promotion from Firefox itself with the campus edition. With folks who didn't use Firefox, installing it was simply part of installing Zotero. For them, Firefox was effectively part of the Zotero application. The same works with Anthologize. WordPress users can simply install the software, but if someone wants to use Anthologize with blogger, or something else, the just install WordPress as part of the Anthologize application and ingest the feed from whatever platform they are interested in.
I'm glad you captured this, Trevor. I hadn't ever heard outreach summarized like this before; with a healthy dose of usability, information architecture principles mixed in. It actually makes me better able to talk about what I try to do, so yeah, I kind of owe you a beer…or two.
#2 really hit home for me during Anthologize. There are great products/ideas out there. What specialness is your product/idea doing that others don't? How will it make potential end users' lives better/easier? That better be on page 1 of your website and up front in everything you communicate. Before building whatever it is, if you spend time thinking about the challenges that your audience has and making sure your software nails it, "marketing" is so much easier after that.
I just might take you up on that beer! I am really glad to hear that this might help you to better explain what it is you do.
On some level my list of outreach components is a bit of a laundry list of roles. But the more I think about it the more it makes sense. I think what holds all of these roles together in my mind is the idea of the user at the center of user centered design. There is a lot out there for how user centered design changes the nature of the development process, but I haven't seen much that deals with the extent to which the idea of user centered design should change the outreach process.
Now if the primary purpose of outreach is about getting users then all of the things we have learned from user centered perspectives on the design process are now critical elements for outreach to happen.
I am a website designer and online marketer working with an academic institution that is trying to find a way to use Zotero to share material online.
I see you talking about “community” but I am honestly confused about who the “community” is that you’re talking about. When I look at Zotero’s training tools and read some of the enthusiasts who are writing about it, they are distinctly talking about how it has replaced index cards for organizing their citations and treat it like EndNotes on steroids. That’s a very individual process and benefit and from my way of looking at it has zero “community-building” implications for the end user.
How is Zotero a community-building tool or what benefit does it have for a community of users? What are the case studies or tutorials on how to share or otherwise use Zotero in a group?
Sorry to be struggling here, I am hoping you have some advice or thoughts for me on this as I try to help my client help widen the base of Zotero users.
Hi Sara, I don’t work for CHNM anymore, so you are probably best to go visit the Zotero forums to discuss this with folks currently working on the project. With that said, there are a lot of folks using Zotero’s groups for classes, to share and organize references for organizations and professional associations.
To clarify, I don’t think and wasn’t trying to say that Zotero is a community building tool. This post is primarily about the user and developer communities that have emerged around the tool.