The local authority problem - seven maxims for web design

Local authorities are the Kevin Bacon of the not-for-profit world. You're never more than two or three connections, at most, away from them. If you're working on a charity website (large or small, local or national), it's overwhelmingly likely that a significant subset of your audience is on local authority premises: funders, commissioners, regulators, purchasers, or professionals seeking inspiration, information, education or somewhere to refer a member of the public to. Quite likely, a combination of the above.

This presents a challenge. The computers deployed in public-sector organisations are, frankly, not like the ones the rest of us use. A combination of draconian security policies, antiquated equipment and never-updated browsers can mean your message doesn't reach its destination intact. Now, another organisation's IT policy isn't your problem. Furthermore, the web would be a much worse place to be if we were all still fully constrained by the whims of IE5. It's right that we periodically say "enough" and move towards modern approaches at the expense of older ones. But nonetheless, if your message isn't reaching the people it needs to reach, this stuff is worth a thought, especially since you may not have access to such machines to test your work on.

In which spirit, I'd like to speed you on your way by sharing a few rules of thumb I've picked up over the last couple of years.

1. Anything that's hosted on a social media service is potentially risky. Users may well be entirely blocked from seeing anything whose URL ends in .wordpress.com , for example.

2. Weirder still, I've seen a WordPress site rendered useless because the filtering algorithm allowed the HTML through but blocked the CSS. Never underestimate the wide-ranging potential of corporate content filters to wreak unexpected kinds of havoc.

3. Like washing your hands after a bodily function, this one's schoolboy-simple but easily forgotten: always begin your CSS with the trusty
    * {margin: 0; padding: 0}
You'll avoid a lot of cross-browser inconsistencies with that one alone.

4. Keep CSS floats and clears to the most straightforward of tried-and-tested combinations. Life's too short for that particular hassle.

5. If there's a minimum screen resolution you'd normally take into account, it may be worth thinking again. A combination of old hardware and the widespread use of thin terminals (the ubiquitous Wyse boxes and the like) can mean your users are working with a screen resolution that hasn't looked impressive since 1990. Your site, therefore, may end up unintendedly bulbous.

6. On a similar note, animated or video content may not look its best. I've seen embedded YouTube videos appearing at around half a frame per second, because the content was being loaded at a central server end and being sent to a thin terminal over a slow connection.

7. Keep client-side scripts and applets to a minimum. They'll almost certainly be blocked or impaired by security filters. Even if a script can run, if it's anything like a Twitter badge, Facebook integration or embedded chatroom, it may well be unable to load what it needs because the client computer is forbidden from connecting to them.

Taken together, the above issues seriously stifle what you can do. They shouldn't necessarily take priority over other considerations - but when choosing between two approaches they're worth a thought. At the very least, they're a starting point in troubleshooting the dreaded "Your site isn't working" phone calls.

Good luck.