In the comments thread after the post on reputation management last week, Sam Farrow made some excellent points about search engine optimisation (SEO) and public sector communications. During the course of the conversation, I realised that this was a topic that needed its own post. Unfortunately, this isn’t it. Why? Because while composing that post, a couple of other things started to colour my thinking on this issue.
The first thing that occurred to me as I began writing the post was that there isn’t much point trying to optimize your pages for search engine spiders unless they are also optimized for all the other User agents, ie., web browsers, handheld devices, screen readers, content aggregators and syndicators etc. In short, SEO is a subset of a wider field of optimization, and an understanding of web standards, particularly HTML, should precede that conversation.
This got me thinking about the level of understanding of HTML among public relations/affairs professionals. After all, it is our job to advise our employers or clients on how to best communicate using the various channels that use the Internet, so surely we should have at least a basic understanding of these media?
Maybe not. Two things happened this week that left me thinking that perhaps this is a naive or overly simplistic view…
First, I was in an agency presentation where a web development company were pitching to redevelop one of our websites. At one point, they showed us a slide where all the acronyms on the page were highlighted (this being a government site, they reasoned, you would want people to be able to understand the acronyms: fair point). However, when I asked how they intended to do this, they said with some javascript
. I asked why they wouldn’t just use the acronym element? And, honestly, they just stared blankly at me. They had no idea what I was talking about.
Here is a hint. If you are presenting yourself as a subject matter expert, at least cover the basics.
Then a couple of days later, I saw that another social media release had been put out, and judging by the case study, it was a success. Which is great. However, if you view the source of the release, you will see that the quality of the HTML is, well, quite poor. Invalid, no doctype, full of deprecated markup and meaningless classes.
Why does this matter? The release looks fine in most browsers and none of the other bloggers of media seem to be complaining about the quality (or lack thereof) of the HTML.
It matters because if you are a practitioner of public affairs/relations and you are working in the online space, how can you claim to be a professional if you don’t understand the basic language of the medium? Would you employ a builder that couldn’t read the architect’s drawings?
It matters because valid, semantic markup is accessible to both people and machines. It is optimised for search engines, for browsers and for people, irrespective of how they choose to access or repurpose that information. That is presumably what the author of the case study was aiming for when he said:
So we opted to make the announcement as an SMR, optimizing it’s format for maximum success.
Geoff Livingstone
I don’t want to be overly critical, because I think that it is terrific that people are experimenting with the social media release. Indeed, compared to some of the earlier SMRs that I have looked at, this one is a marked improvement. What I do find amazing is that so much of what communicators are trying to achieve on the Internet is done without consideration of the standards that support this medium.
So, if we are going to have a microformatted social media release, hRelease, then we can start by issuing releases that are valid (x)HTML. Validation is not an end in itself, but it is a pretty good indicator of a disciplined approach, and if we want to be considered professionals, isn’t that something we should all aim for?
Conclusion
If you are going to specialize in online communications or public relations (in the public or private sectors), then you owe it to yourself, you agency and your clients to – as a minimum – be familiar with the HTML 4.01 and XHTML 1.0 specifications. The HTML 4.01 spec was published eight years ago: have you read it? Do you think you should?
4 Comments
Actually, not sure how its done in New Zealand, but in the U.S. we’re not responsible for coding our clients’ web sites. We’re responsible for creating the message and outreach. But I think if you had read the original SMR (http://www.prweb.com/releases/.....527737.htm) per the actual case study cited in this somewhat wayward post, you would see that the HTML was fine.
BTW: If you are going to critique people’s work like this, you owe it to them to spell their name correctly.
Fair enough Geoff, I apologise for the spelling mistake.
The HTML in the original release is actually not all that fine, by any stretch.
Your point about coding client sites is, however, something we can discuss. Do you separate the creation of the message from the delivery mechanism? You obviously advised them to go with the SMR, why not advise them to, for example, mark up the quotes using the
blockquoteelement?Complete agreement here Jason. Poorly formed mark up is amateurish and impacts on important issues of accessibility.
Geoff does raise an important point about the distinction between the message and the medium, however, I think successful online communications must, by definition, be accross both aspects.
To me, this is the classic gap between the business and the technologists.
The business cares that its information is accessible. In the case of a media release, the more accessible, the better the outcome, more people get to hear the message.
The business relies on technologists to make systems, to help achieve its outcome. A gap arises because the business does not understand enough about the potential of the technology, to realise its full potential. Therefore it may buy an inferior system.
HTML is an example, but it will apply elsewhere too e.g. podcasts, RSS, SMS, flexible LCD displays, etc.
People like Jason, who understand both worlds, can reduce that gap, through describing the vision.
Ideally over time, a consensus will form over what is the best way, and the business will start to buy based upon a checklist of requirements, and the inferior systems will disappear.
If you care about a technology, in your business, then perhaps the question is “how do I speed up this process?”.