Website updates – you really must do them

Website updates: do them or pay someone but do them

Website updates don’t follow the logic a lot of us inherit from the era of software updates that arrived in the mail on a disc of some kind.

Before there ever was broad public access to the internet, going forever without updating your software was a  point of pride for most people who did a lot of computer-driven communications work.

Or it was a mark of world weary wisdom because we’d arrived at the point where we knew that the X.0 release of anything was going to suck rocks. We’d wait. Until X.1 or .2.

The updates were expensive, disorienting, and if they did cause a problem, the solution could be months away.

So trying to get a personal best time and distance between updates made sense.

But you cannot transpose that logic onto your web application.

Because your web application — be it WordPress, Joomla, Drupal or any number of others out there — is not safe and sound in your office.

It’s on a computer on the internet which is, for all intents and purposes, the equivalent of leaving it on the counter in an all-night convenience store off a freeway where the counter clerk is asleep.  Only worse. Because unlike the convenience store, your server gets all the traffic in the world coming through it.

And unlike your computer, which accepts input only from a keyboard, your website is on a server, which accepts input from anywhere. By definition.

But I don’t have anything important on my site

Maybe not credit card numbers, bank account information or medical histories, but you have your reputation and/or your brand. And if someone gains unauthorized access to your site and starts abusing it (which it almost goes without saying they will) these will suffer.

You will have to apologize to clients, prospects and anyone who was coming to your site for any reason about the fact that your site was hacked. You will have to insist that your inability to maintain a website has nothing to do with your competence generally.

And you will lose time. Possibly weeks. You will be restoring your site from backup or recreating it if you didn’t have a backup. You’ll be trying to track down the vulnerability and check the whole attack path to determine if the attacker left any other back doors or malware that might allow them back in. You will be visiting all the security websites to ask that your site be removed from whatever spam or phishing blacklist you’ve been put on.

Or you’ll be paying a security consultant or company at overtime rates to do all of the above.

But no one would want to hack my website — I’m not the CIA/Microsoft

You’re assuming that the hackers are actually human. And you’re mistaking media coverage of famous hacks for what happens in everyday life on the internet.

Most website break-ins are perpetrated by robots which scan the internet for sites that might be vulnerable. They find a site that has the vulnerable application, run the exploit against it, and, if they succeed, install the malware and get straight to work. At some point some human put this process into play and will be interested in the results, but they have no idea who you are, what you do or what a nice person you are.

They’re not interested in defacing your site to show how cool they are or to denounce you for being a tool of the capitalist class or whatever. They want your site as a platform to send spam, serve porn, collect passwords or phish other data from unsuspecting visitors. And for that, one site is as good as the next.

What if I don’t have time to do all this?

Self-hosted websites do indeed take time and expertise to run smoothly. The skill required to apply updates, do backups, and tweak performance can be acquired if you have a bit of time and some curiosity. But if you don’t you can get someone, like me for example, to do it for you. For a small site it’s generally about an hour a month. Plus you get my advice on improvements, best practices and life in general. A bargain at twice the price, really.

Or you can move your site to a software-as-service setup like or Wix, or Weebly where the service itself looks after security, updates and backups. The monthly hosting cost ends up a bit higher, and it may limit the sorts of things you can do with the site, but if you can fit within those constraints and aren’t bothered by an extra $10-20 per month, it might be your best bet. That will be cheaper than paying me or someone like me.

Content strategy rethink – I don’t design like I used to either

Content strategy

My first ever content strategy happened in about 2000. I had this crazy idea that if you made a simple cut paste and post system and hosted it on the web server, anyone could be a web content creator. I had just started a new job and in talking to my co-workers and to people in other parts of the organzation, it was clear to me that the time it took to get stuff put on the website was a major problem.

And the source of the problem was the fact that it all had to go through The Webmaster™. Because that person was the only one who knew which buttons to push.

So why not, I reasoned, make everyone web content creators? After all – we were all grown up, professional type people. We were well-compensated and entrusted with the well-being of the organzation. This would remove the bottleneck and whatever bias The Webmaster™ had due to their situation within the organization.

Content strategy goes from Webmaster to Wild West

And I wrote an embarassingly bad set of scripts in ASP. It took input from forms, stored it and organized it in a database, dressed it up in a template and served it to the visitor. I trained people on how to use it and gave everyone an account and a password.

It took a long time for the concept to take hold. In fact it didn’t really until three years later. By that point the server had moved to Linux/Apache/PHP and a different set of scripts. By that point I was calling it a content management system.

And a couple of years after that I was starting to think maybe this wasn’t working. See the site’s content was overwhelmingly lopsided, favouring press releases over… well… pretty much anything. The website was the creature of the communications department. That’s where the web staff were and that’s whose stuff got posted.

Self-publishing regimens don’t always result in more content

The whole “you can post it yourself” argument (said in that earnest, we’re-trying-to-empower-you kind of voice) worked to quell complaints but not to create content.

Then I made another kind of discovery (by reading someone smart on the internet): putting print content on a website sucks. The only stuff we had that was ‘web ready’ was the ‘fit for public consumption’ stuff – pithy press releases. For all the problems they entail. Shortly thereafter I had another eureka moment: maybe web content doesn’t have to be a 150 word chunk of text. Maybe it’s a listing. A table. Maybe even a video.

Maybe people weren’t feeding the site with content because I’d been asking them for 150 word chunks of text when what they needed was a table. Or maybe they needed a form so that they could listen instead.

Ah but the sands of time shifted beneath my feet and I found myself – two years ago now – in another organization. This lot seemed to have adopted the worst of both worlds: The Webmaster™ strategy but with everyone as a content creator and no curative or editorial role given to… anyone.

Should you be rolling your own web content?

So I’m often the bearer of bad news: “That needs a title that explains what the story is about”. “I don’t care if it’s already been translated, it can’t go up like it is”. We’re trying to provide supports of various kinds (templates, workshops, one-on-one tutorials and planning sessions) to help people produce web content. But the pace of change is slow. Possibly fatally so but that’s the subject for another post.

I’ve concluded that I think all the people we expect to roll their own web content really should not be doing that. They should be content sponsors, or executive producers. Their expert staff should be advising the people who do create the content where they’ve over-simplified, lost or changed meaning. But the job of deciding what form the content should take, and how it should be created properly belongs to people who… ah… know a thing or two about creating web content.

They’re not necessarily communications people or even writers either.

But that’s assuming infinite resources and a workforce that can be reshaped in an instant and populated with stars. I expect in many organizations reality is a tad more complicated and possibly disappointing in that regard.

So until some of the same energy and resources that we used to apply to producing paper communication gets applied to producing web content, it’s likely going to be templates and workshops for us to help people be their own web publishers, whether they want it or not, or whether it’s the best approach or not.

This post originally appeared on my blog,

Email in a bilingual land: evidence that language of choice is more effective

Canada is a bilingual country. The federal government (and many national organizations) operate with stringent standards on services and communications being available in english and french.

This is done to protect people’s right to access government services in either english or french, whichever they prefer.

I get that. What I don’t get is why people doing online communication think that means we have to give everyone both languages in the same message.

For bilingually mandated organizations – governmental or non-governmental – it seems that being seen to be bilingual is actually more important than being understood in english and in french.

That’s fine for government. I suspect the current government would make its program information available in Latin if they thought they could get away with it and it would keep costs down.

But for social change organizations, whose health and success involves public engagement, sending email (for example) in bilingue, Canada’s third official language, is bad news.

See, no one speaks bilingual and they’d prefer not to read it in email either.

I’ve always thought this. But now I have proof. Some proof anyway.

Where I work, we have serious religion about producing everything in english and in french at the same time and with the same quality, etc. I wouldn’t have it any other way.

But someone interpreted that to mean that bulk emails must always contain french and english in the same message.

This means both languages in the subject header and either english column/french column or english-follows-french email body. Both these are fraught with problems:

  • The second language in the subject is almost never read.
  • Hansard style messages don’t render well in many email clients – Blackberries? Hello!
  • Over-under messages must always put one language first.

And people who read both, or prefer to read in the language-put-second have more work to do and are less likely to open your message and less likely still to click.

As proof I offer the following.

We sent out a notice of an online survey (complete with juicy incentive) to a 35,000 or so member list. For some addresses we had a language preference. We sent them a message in the language of their choice.

For others, we did not, so we sent them a Hansard style ‘bilingual’ message. The results tell the story:

MessageOpen RateClick Rate
French only46.9%23.8%
English only48.6%23.8%

Language-of-choice emails got a 20 or 21 per cent higher open rate and a 16 per cent higher click rate than bilingual messages with the same content. They’re more likely to be forwarded and less likely to be the subject of a spam complaint.