Part of the job of a Hackaday writer involves seeking out new stories to write for your delectation and edification. Our tips line provides a fruitful fount of interesting things to write about, but we’d miss so much if we restricted ourselves to only writing up stories from that source. Each of us writers will therefore have a list of favourite places to keep an eye on and catch new stuff as it appears. News sites, blogs, videos, forums, that kind of thing. In my case I hope I’m not giving away too much to my colleagues when I say I keep an eye on the activities of as many hackspaces as I can.

So aside from picking up the occasional gem for these pages there is something else I gain that is of great personal interest as a director of my local hackspace. I see how a lot of other spaces approach the web, and can couple it to my behind-the-scenes view of doing the same thing here in our space. Along the way due to both experiences I’ve begun to despair slightly at the way our movement approaches the dissemination of information, the web, and software in general. So here follows a highly personal treatise on the subject that probably skirts the edge of outright ranting but within which I hope you’ll see parallels in your own spaces.

Before continuing it’s worth for a moment considering why a hackspace needs a public website. What is its purpose, who are its audience, and what information does it need to have?

Public or Private?

The  first and most important point to understand here is that there is a difference between a public website and an intranet. Both may be websites in literal terms, and both may be accessible from the Internet, but the former is aimed at the general public and the latter is aimed at insiders. So many hackspaces appear to blur this line or miss it completely, and create web presences so confusing and opaque that they might as well not be there.

Your internal project wiki, your membership system, your keyholder rota planning application, tool inventory and whatever other internal stuff you just have to put online are all intranet stuff. It’s not that they aren’t important, just that they aren’t relevant to your public-facing website even if they are public-visible. Do them as a separate project, and get something done!

If you ignore the previous paragraph and try to combine the two facets of hackspace web service there is a significant danger that when sitting down to plan your space’s web presence you will become stuck in a mire of different software services. Somewhere along the way the project will turn from a straightforward web site refresh into an intractable schism between hackspace factions, and nothing will be done. I have a feeling that this will be familiar to many readers of this piece, and that it lies behind the somewhat dire quality of so many offerings in the hackspace sphere.

Why?

We should now be in agreement that we are talking about public facing websites. So what does a hackspace need a website for? The answer is simple: to convey information that anyone who is not an insider might need to know. Those outsiders might be prospective members, but they also might include commercial or institutional donors, potential customers for your tools and services, and other revenue opportunities.

So as well as basic info such as contact details, opening hours and location, you need to present a compelling picture of what a prospective donor, member, or visitor could expect. A regularly updated blog featuring the work being done in the space, the events the space attends, or other matters of interest. This does require some commitment to keep updated, but it should not be beyond the ability of most spaces to produce content at least once or twice a month.

The Great Software Trap

Right, we’ve got to grips with what constitutes a hackspace’s public-facing website, who it’s for, and some of the things you might put on it. Your hackspace board or committee of interested parties are about to sit down and plan how it is all going to be implemented. Watch out, you’re now hovering on the brink of the Great Software Trap.

The Great Software Trap is an inevitability in any arena when those making the group involved in the choice are software developers. This is my area of expertise, software, they say, I know about this, I can solve this as a software problem!

The result is that you will have an array of competing views on what is the right tool for the job, some of which involve writing bespoke software and others of which will be heavily influenced by the speaker’s pet project. None of them will remember that a website is in fact a content problem rather than a software problem. In fact the needs of the website itself will be almost forgotten. Someone will inevitably then champion their own piece of content management software written in Brainfuck that runs on Contiki for PowerPC on a machine safely hosted in their basement. Violence against your fellow hackspace members is illegal, and it would probably cause ructions were your committee to ban the speaker, forthwith. But you know you’ll want to.

There are plenty of cases where writing your own software makes a lot of sense. When your task has not been adequately attempted before, for example, or when you have a completely new platform. But for a task that has already been covered by hundreds of thousands of other developers and for which a host of battle-hardened freely-downloadable packages exist, you need to have a really good reason to write your own. To pick an off-the-shelf package and host it professionally is an easy choice to make, though sadly the final choice conceals a host of further pitfalls.

Round Up the Usual Suspects

Here’s the thing: just because a piece of software can do something does not automatically mean it should do it. GitHub can serve web pages, for example, and MediaWiki is a fully-fledged website engine. Both pieces of software have been used as the sole front end for public-facing hackspace websites, and both have given disastrous results. A software repository which can serve markdown documentation is no use to your web content person who is not a command-line git-wizard, and a wiki platform developed for an encyclopedia is a disaster when it comes to serving an easily-digestible front-end web site.

Both have their place in a hackspace web offering: GitHub in publishing the space’s software repository and MediaWiki in providing the back-end for its project wiki, but that’s where they should stay. There is a whole gallery of Usual Suspects to choose from when it comes to content management systems for front-end websites, why go for anything else?!

You may by now have wondered who the real-world examples are, but to link to hackspace websites when ranting about their software would be unfair. Take a look though at the websites of some of the hackspaces whose projects have featured on these pages though, and you’ll start to notice some of the better offerings. This isn’t because writers favour projects based on the website software choices of their hosts, more that well-presented projects are more likely to catch our attention than those hidden away in an impenetrable project log archive on a wiki.

And in case you’re asking whether I should be eating my own dog food and making a better offering for my own space, we’re just as capable of falling into the Great Software Trap as any other space. (On that subject, lest my fellow members think this is all about them it’s probably as well to remind them that members of nearly all hackspaces will read this and see elements of it that are relevant to their space. Hackspaces are all doomed to follow the same paths, it seems.)

Whichever route your hackspace website takes, remember this: If you want to catch our eye with a project, make it easy to find, give it a good write-up, and please, Please, give it some decent quality high-resolution images that work in both landscape and portrait modes!