
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. Click here to continue reading





Demo | 





