Yesterday I had a message from Jonathan Hassell, Head of Usability and Accessibility at the BBC, to let me know about the 2nd draft of the much publicised BS8878 British Code of Practice on Web Accessibility. Rather than paraphrase Jonathan, I’ve just copied his message below:
As you may or may not know, the British Standards Institute have now published the 2nd draft of the BS8878 British Code of Practice on Web Accessibility.
When considering some of the recent online surveys that I’ve seen or been involved in setting up, I’m reminded of the saying:
Never assume. It makes an ass of u and me.
Anon
It may be hackneyed, but it does ring true for many of the observations I’ve made around surveys. Here’s my list of the 10 most common assumptions to avoid when conducting an online survey.
HUWY
Earlier today I went along to the e-Science Institute in Edinburgh to attend the launch of a new project aimed at getting young people talking about policies and laws which affect the Internet, to channel their ideas to the policy makers.
According to the delegate pack, the HUWY (Hub Websites for Youth Participation) project believes that young people are valuable expert stakeholders in current Internet governance issues like:
Biased results are a risk of online polls
I’ve just updated my list of social media lessons learned the hard way with details of an online poll which appears to have backfired.
In summary, part of a multi-million pound advertising campaign by Christian charity Alpha International has potentially backfired when an online poll on their website, asking whether people believed in God, showed an abnormally high 98% saying ‘No’ (source: The Register).
I’ve had cause to think about this subject recently when we had a bit of a palaver over the public deadline for our online school enrolment forms. Released in mid-November, the deadline was set at December 24th. A bit tight, I thought, but it’s not my position to question such things. Christmas came and went, and I asked if it was appropriate to now remove the forms, given that the deadline had passed. Oh no, I was told, as by law we must accept applications until 15th March. I was then asked to amend the deadline date accordingly. The December deadline was a fake.
Although I can understand that it is useful to receive submissions as early as possible, to allow staff to manage their workloads, it seems a bit unreasonable to present a false deadline which is then discretely extended. Many people will have put themselves to great inconvenience to complete this form in time, especially given the time of year, and to find that the deadline has been extended by almost three months will no doubt cause annoyance. There is also the risk that citizens will stop taking deadlines seriously, and may miss the window of opportunity in the future, where stated deadlines are genuine.
Far better, perhaps, to give the genuine deadline, but state that early submission is recommended. In some cases (for example, applying for grants from a limited fund) you could even suggest that early submissions will receive preference – that should get people moving!
Similar issues have dogged some recent consultations that we’ve held, with deadlines being pushed back and back to try to squeeze out more responses. The problem here is that those who aimed for the original deadline may not have given themselves sufficient time to compose a full and accurate response. Those who replied early on are likely to be those who feel strongest about the subject of the consultation, and therefore the kind of people you want to listen to carefully and not annoy.
Of course, there are some instances where extending a deadline is sensible. In a consultation where new information has come to light, for example, or where there has been a technical problem preventing people from completing the process. In such cases, the reason for the extension should always be made clear. Otherwise, the organisation risks looking unorganised and unprofessional.
The same applies to project deadlines. I recently finished a job which had to be completed by a certain date. No problem there – I’m used to tight deadlines. But when the delivery day arrived, the client came back with a few tweaks and some new requests, and it turned out the original deadline wasn’t as crucial as first made out. These fake deadlines don’t do the developer any favours – many things may get rushed or dropped entirely as a result. Also, it’s usually a lot harder to change a final product, rather than factor in any modifications as part of the build process. It’s therefore far more productive to set milestones, where you deliver certain things by certain timescales. This allows for a far smoother progression from planning to the final product.