I review hundreds of new and existing open source software (OSS) for inclusion in the OSLiving archive, and so inevitably I get to experience a wide range of websites. More often than not, the website experience leaves alot to be desired. Aside from the very large-scale projects for which money (and therefore custom design and usability testing) is no object, the majority of Open Source project websites are either community-built or left to the program developers themselves. While instances of good practice can be found in both large and small-scale projects, problems tend to arise more frequently in the latter group. All too often the website is the last “chore” in a taxing software development process. This is problematic since the success of your software depends very much on how you present and contextualise it.

In this article, I highlight some of the recurrent issues and offer some common sense suggestions for an improved OSS experience. My purpose is to help remove as many barriers as possible between your open source application and your potential audience. This is particularly important in thinking about attracting first-time and novice OSS users. The good news is that it really doesn’t take much to improve accessibility other than simple planning, realistic goals and some solid resources. The following notes are part of a forthcoming project for the main OSLiving site, a guide to getting started with open source. Accessibility, usability and ‘findability’ (see above diagram) are the 3 core criteria that Paul Veugen uses in his micro usability tests. I’m going to borrow these terms (somewhat out of context) to inform our discussion here.

Note that all of the elements I’m about to describe could be included in a single presentation page – the landing page of your site.

1. The Three-Line-Intro

The first thing I look for when visiting a new OSS website is a succinct, jargon-free description of the application. A 3-line-intro that explains what the product does and what its immediate applications are. This is possibly the most important feature on any OSS website since it allows the user to gauge the relevance of the software in a few seconds and determines whether or not he/she sticks around.

The 3-line-intro is a fairly widespread practice, but you’d be surprised at how often I find myself having to navigate to “about” pages, scrolling through impossibly long presentations, or even sometimes doing a separate google or wikipedia search for a clear sense of what the program actually does!

Do’s: Keep your intro text short, precise and informative; write it with the end-user in mind; display it in a prominent position on the landing page; offer a link to a more detailed introduction to the product.

Don’ts: Make sure there are no spelling mistakes (have a friend check your copy); steer clear of unnecessary jargon;

2. The Feature List

Once the user has decided that the app is relevant to his/her needs, the second thing s/he will be looking for is evidence as to why your particular program is better than the competition – open source or otherwise. So if you got your audience hooked with your 3-line-intro, here you need to reel them in with a clear overview of what your app excels at. This is where you lay your goods out in the shop window, so to speak. Needless to say, if the presentation is not clear and immediate then you’ve lost their attention.

One of the most common ways of doing this is to include a bullet point list of the main software features. In theory bullet points are an efficient way of conveying snippets of important information. In practice however, many of the lists I encounter are far too long and unordered. On a text list of 10-20 items, I tend to switch off after the first 5.

So how can you make your feature presentation more effective? Well the first thing to do is to cut your list in half. If you have more than 10 items on your feature list, ask yourself which of those are REALLY crucial to the user’s understanding of what your software can do. Anything that is not essential, get rid of it, or include it in your detailed overview page. The second thing is to think about how to make the remaining elements desirable and credible. A good way to think about this is to borrow the model that Premium WordPress theme sellers use to explain the features of their latest wares: a combination of thumbnail graphics and brief explanatory text. See here for a good example. The thumbnails provide small “windows” onto the actual application and the text helps contextualise the feature in question.

Do’s: Keep your list to a minimum; consider using a combination of thumbnail images and text; highlight the features that set your product apart from the competition.

Don’ts: Avoid dense, text-based lists; randomly combined features; jargon without explanation.

3. Demos & Showcases

So far, the potential user has landed on your website’s front page, found your program relevant to his/her needs, been impressed by its feature list, and now wants to see it in action. The user wants proof that your sales pitch lives up to the standards you’ve just layed out. Now this step can take a number of forms depending on the type of software you’re developed. Ideally you would be able to offer your visitor a working demo version of the software, both front and back ends, with a clearly labelled demo username and password. Needless to say that if you do run a demo version, all parts of the demo should work.

If you cannot run a demo version, then the second best option is to provide screenshots. Here it’s important to think about the order and layout of your screenshots. Rather than present a random selection of images, try ordering them in relation to key software functions and split them between front and back end visuals. Consider using one of the widespread lightbox gallery scripts such as LightBox2 for example, available for free download.

Aside from the demo, consider including a selection of case studies or showcase examples that highlight specific usages and applications of your software. You really only need 2 or 3 showcases for this to work. If you do include showcases then be sure to provide a working url to the site, information on its author(s) and how this particular case uses your software. Opt for a range of case studies where possible.

Do’s: Provide a clearly accessible demo version of your software; make sure you offer front and backend access; if you use screenshots, arrange them in a coherent and accessible fashion; use poignant case studies to vouch for your software.

Don’ts: Don’t link to an incomplete demo site; don’t crowd your website with random screenshots; don’t present same-type case studies.

4. The Download

After viewing the demo and liking what s/he saw, your user is now ready to download the software. But where to get a copy and what platforms does it work with? Most OSS developers house their code on SourceForge, GitHub or Google Code, this means sending users to a separate website to download software. While all three code hubs provide excellent repository facilities for your code, they don’t necessarily offer the most user-friendly download and install experience for your users. It can be a barrier for first-time or novice users.

So think about ways to compensate for this gap. How can your site make it easier for the end user? The ideal scenario would be to include brief but clear instructions on how to download and install the software, and in the case of problems where to get support. This would all be on one page. Instructions might include the following:

- An clear indication of which platforms your software runs on.
- A step-by-step process from download to install.
- An explanation of the software license, and more importantly, what that license actually means to the end-user in simple terms.
- clearly stating who the software was made by and where the user can go to get support (see next section).

This extra information will go a long way to preventing the confusion that can arise when users are sent to a code hub to figure out the download and install themselves.

Do’s: Provide accessible download and installation notes for a wide user base; prepare your user for the download from a code hub rather than assuming s/he will know what to do on arrival; state which platforms your software runs on and what the license agreement is.

Don’ts: Don’t link directly to the code hub and assume your users will know what to do; don’t forget to state which platforms can be used.

5. The Support

The final step on your OSS website is to include signposts for support. Where can your users go if they have trouble getting the software to work? Is there a community forum they can use? A ticket support system? An FAQ section? A contact email address? And if there are all or several of these, what is the preferred order of priority in terms of action? All this including the names of the persons to be contacted and their specific areas of expertise within the project should be made clear to the end user.

Lack of support is often cited as one of the biggest barriers in winning over new OSS users. Showing up front that your program has exemplary support will go a long way to allaying fears and making your app a success.

It might also be a good idea to include a word or two about the frequency of updates. This is something very few OSS sites practice, partly because small-scale OSS development work tends to take place over a protracted period of time on an ad-hoc basis. Nevertheless, an indication as to how frequent software updates are likely to be and where and how they can be installed is worth bearing in mind.

Do’s: make it clear what support options are available; who is behind the software development and how to be contacted; provide info on update frequency including a link to the change log.

Don’ts: leave your users in the dark about support options, offer support if you don’t have the time or resources to honor the commitment.

6. Examples

Pitivi: this is a free, intuitive and featureful movie editor for the Linux desktop. While the site doesn’t opt for a single page user experience, the landing page contains a clear overview of the product with prominent links to an extensive feature list, demo and showcase.

Stellarium: a free open source planetarium for your computer. This site has perfected the 3-line-intro (or there abouts) and does an effective job of laying out its features, access and support on a single page.

Inquisitor: is an open-source hardware testing and certification system. This site excels at contextualising its product by offering a narrative-based “How Can It Help You” page. The site also makes good use of a screenshot gallery module.

Thanks for reading and please feel free to leave comments on points of contention or elements that I’ve overlooked. I’ll update the article with any appropriate reader suggestions.