Defining 'web-ready' content

The green light.
Photo by lovesonic on flickr,
and used under creative commons

You should not - cannot - blindly accept every request to publish. Web teams act as guardians and gatekeepers to ensure only high quality content that makes sense in the broader organisational context is published online.

For me, ‘web-ready’ means:   

• If there are PR implications to publication of this information, it has been cleared with the relevant communications or press office lead, and appropriate arrangements for post-publication publicity have been made.
• The website is the most appropriate place for this to be published (rather than, say, the intranet,  or a newsletter).
• The content is yours to publish. Who wrote it, and who owns the copyright? Is it already available on another site you can link to? And if yours is an official website, such as that of a government organisation, an additional factor might be whether your organisation or department is obliged to publish this information. If not, why are you publishing it?
• Any technical content (clinical or scientific, for example) has already been checked by the appropriate expert or authority.
• Written to house style, with correct spelling, punctuation and grammar.
• If it is a publication or designed document, it conforms to branding policies, and ‘gateway’ requirements if your organisation has them (a series of checks performed by your publications or communications team, that may result in the issuing of a unique code or publication number).
• If it is a webpage, a suitable page template has been followed and a location for the content has been identified in the website structure.
• The content is accessible – for example, all images have appropriate alt text.
• Any supporting information, such as author details for metadata fields, has been supplied.
• There is a plan in place for keeping the information reviewed and updated, where appropriate, and a contact for any queries that arise after publication.

These checks can become second nature over time, but every now and again it's worth reminding yourself - and the people supplying content - about what you should be checking for and why.

Emergency preparedness for web teams

Should web publishing staff be actively involved in emergency preparedness training?  

 

I’m not talking about social media – I think it’s becoming more mainstream to include SM in emergency response, and therefore in training exercises. Just think of Twitter Gritter, or look at the way BTP tweets to let people know when there’s a ‘one-under’. In this blog I’m thinking of the day-job web officer who may be uploading the press releases (you’re lucky if your press officer can do it themselves), and is certainly publishing the supporting pages - FAQs (*shudder*), detailed professional guidance and pithy public advice. 

 

Of course a lot of this depends on your organisational structure; this is another argument for close integration between the press office, social media and the corporate website. But too often the web team are still seen as the dumb, mechanical tool of the organisation – no more responsive than a typewriter being used to bash out the latest media statement.

 

While it’s important that the web team shouldn’t hold things up in an emergency by querying every misplaced comma, they do have a significant and enduring contribution to make. They’re not just there to provide something for your tweets and Facebook pages to link to, or to generate a ‘further information’ URL to add to your Notes to Editors.

The supporting pages that your web team publish are the ones that are going to be pored over, not just during the crisis, but in future when people look back to see how you handled the situation. It’s not much good if you can’t find them through Google or your own site search, if they break when you look at them on a Mac or mobile, or if it’s hard to navigate to them logically through your IA. A naff little homepage ‘quick link’ can’t stay there forever, and won’t help with future SEO.

Your web team must be able to stay calm in a crisis and have the tools to do their job. This means: 

• They need to understand the organisation’s processes for responding to a major incident (What’s the target response time for this? Who needs to sign off before a page is published? Who should be told if someone spots an error or ambiguity? Who needs to be sent a link as soon as the page is live?).
• They also need to have experience of working under pressure, so that they can anticipate their own fallibility (Does this need a second pair of eyes?) and perceive errors in judgement in others who are stressed (Do you really want to move that web page now? You do realise it will break the link that you’ve just sent out in a press release?).

So next time you’re planning a major incident exercise, think about your back-office webbies as well as your PR team.

Managing contributors in a devolved content management system

One of the toughest parts of a web manager’s job is dealing with the groups of authors who have access to your content management system (CMS).

Not every organisation has a CMS, and the question of whether or not to devolve any element of editing in the first place is quite another blog post. But if you use any kind of devolved system you will probably have come across some or all of these challenges:

• People who insist on access ‘just in case’ but actually never use it
• Regular users who simply can’t – or won’t – take on board house style, web best practice, or anything else you regularly end up correcting
• Managers who want to have final sign-off and don’t understand why communications / the web team want to check their work
• Profligate uploaders who have no idea about version control, putting on multiple versions of the same document
• Tweakers who just want to play with the code or use every colour and heading and clip art image they can find

And there are plenty more. But rather than make this post a moan, here are my top tips for reducing the pain. 

In fact, you might even reap some benefits and save some time and energy.

• Make it a prerequisite that editors must use the CMS regularly. It is the once-a-year users, and those who try to use it for the first time six months after their training, who cause the most problems. It will usually be genuinely quicker and easier for them, and you, if they simply email you their updates.
• Provide more than just technical training, whether that is running workshops, a blog or providing one-to-one support. Help editors understand style, accessibility, writing for the web; share your expertise. Make sure they know how to get help.
• Keep editors informed of changes and ask their opinions – making them feel valued and part of a community will help your relationship with them.
• If you can, adjust CMS settings to restrict the amount of freedom your editors have. If possible, prevent them from being able to get into the code, or make simple changes such as removing the ‘italicize’ button from the style options in your WYSIWYG editor.
• Don’t just rely on your CMS though - use a workflow to approve or reject content centrally. This enables you to ensure consistency and uphold standards. There will always be someone who uses bold instead of an H2 style, or insists in writing all in caps.
• For those who oppose you approving their pages:
• Demonstrate the value your editorial hand can add, for example by re-working a section of their content and providing evidence of improved usability.
• Suggest a trial period to allay their fears.
• Ensure you really are adding value; you may have no need to approve committee papers, policies, financial statements or press releases. Considering allowing this kind of content to bypass the workflow.
• When rejecting items, explain what the editor has done wrong and why and ask them to make corrections. If you always do it yourself you can’t expect them to learn.
• Regularly review the list of CMS users and don’t be afraid to disable accounts of those who haven’t used it recently or who are unresponsive to training.
• Work with key stakeholders to enshrine your principles in formal policy.

Do you disagree with my list? What rules work for you?