Saturday, 29 October 2011

Website maintenance issues

Website maintenance is yet another area that has developed into a business segment of its own in the iMedia industry in the last few years. We used to remind you to check with your clients how and when they might want maintenance done, so that you could cost it into the deal for the initial project, but maintenance issues have grown as businesses have recognised the value of regularly updating their content and services because their users expect this.

It used to be recommended that companies take notice of their websites more seriously for updates on look and feel factors every 6 months. However, as web access has become the first point of interaction with a company, the onus on updating has increased too. Therefore, maintenance means more time, more costs, and more resources.

What then does website maintenance cover? If you are offering a maintenance service you would have considered this carefully. It might well cover the following:
  • Editorial updates for content
  • Changes to services/products offered
  • Advice to users in the form of newsletters, blogs, announcements, offers, calendar of events etc
  • Seasonal promotions etc
  • Redesign of look and feel
  • Changing images to give update appeal
  • Review of search engine optimisation
  • Checking on submission terms/timings
  • Analysis of web logs and recommendations
How many people will be involved? Well, that depends on the site, of course and the type of activity needed and how often, but, you'll find this resource from Shane Dillily useful; an abridged Chapter 2 from his book, The Website Manager's Handbook 2006, called Website Maintenance, very useful in answering that type of query.

Have you researched how your competitors are offering their maintenance services? You need to keep an eye on what's being offered and how much it costs. The Websiteaday company have split their maintenance offers into three: Pay-as-you-go, Basic, and Advanced packages.

This might make you think how you are offering maintenance services. Do you give an SLA (Service Level Agreement) to your clients detailing what you will and won't provide for the money? Do they ask for one? These are recommended at Small Business Website Maintenance so you may well get asked for them.

It is hard keeping on top of everything in this business but to survive you do need to charge fairly and offer the type of service the clients want. Lots of food for thought then...

Friday, 21 October 2011

Website content clearance issues

We've all had the client who delays giving us their content for their web pages, mobile pages etc, and faced the knock-on effects of this on development. We have warned against this and recommend that you make it clear upfront that the client has certain responsibilities in project development; such as providing the content when indicated and taking responsibility for ensuring they have the right clearance to use the content electronically worldwide. Actually those both relate to legal issues of ownership and rights in material - very contentious issues at the moment.

The BBC Technology news covers a story around these issues, Websites should carry libel risk for anonymous posts 20th October 2011. You see, although you might well try to advise your clients' on their use of content prior to development, any social websites where the content is generated on-the-fly by users is beyond such control. Usually, unless the web site owner (who is legally the publisher) monitors and removes contentious postings themselves - reactive monitoring - they will respond when someone else points the material out to then. This is known as 'notice and take-down'. There hasn't been any difference between posts by people who give their name and anonymous or pseudonymous ones ... not until now!

A joint parliamentary committee has come out against anonymous postings that breach defamatory rights of individuals. This ruling extends the responsibilities of the website to posting complaints next to an identified offender with take-down rights upon application of a court order. If the offender is not identifiable - has used a pseudonym - the website can take these down immediately unless the author agrees to be identified. There are more details in the article, but, this means more editorial onus on website maintainers.

If any user of social websites posts illegal material - and illegal can mean a range of issues other than rights infringement, who is responsible? For copyright infringement and libel it is generally the 'publisher' (as well as the person who posts the material). It's worth noting that a web hosting company or the postal and telephone services are not seen to be the publishers of content that flows through their channels.

The guys who have been sentenced for inciting public disorder during the UK August riots when they posted Facebook pages urging people to riot, have had their lengthy sentences upheld by the court of appeal recently. See 18th October news article by Owen Bowcott. In this case it was the poster who was responsible, not the 'publishers' like Twitter and Facebook, however, the use of social media and Blackberry messaging came under scrutiny as a result of the unrest. So watch this space.

More responsibilities equal more time and more cost – so just remember that for your next project where you'll be involved in monitoring any content provided on-the-fly!

Our iMedia responsibilities get more and more each day as the law catches up with technological advances.

Friday, 14 October 2011

Who are your key men and women?

You have probably noticed that the world of computing lost two important people during the past few days. One was Steve Jobs, without whom Apple just wouldn't be the hugely successful company it is, but also without whom computers may just possibly be still responding to typed instructions (OK: an exaggeration, but you know what I mean).

The other was Dennis Ritchie. Less well known than Jobs but arguably just as important, Ritchie (as you'll know if you followed that link) created the C programming language and co-created Unix. These two things took computers from being a disparate collection of rooms full of machinery attended by white-coated acolytes to the almost invisible devices that permeate our lives.

These two losses got me thinking about what is known as the 'key person' problem. While the loss of Ritchie is sad his death hasn't raised questions like the Quo Vadis Apple that some ask on the departure of Jobs. I don't want to get into a discussion of how Apple will continue without Jobs but the way he ran the company and turned it around make him an archetypal 'key man'.

Sometimes it is the charismatic and very visible head of a company, sometimes it could be the programmer who knows the password to get into a corporate system but hasn't yet got around to sharing it (I recall a possibly apocryphal story about a Norwegian programmer and a tram). What might happen if this person, to use the usual English terminology, 'goes under a bus' or, more likely, becomes unavailable, even temporarily, for some reason such as a hospital visit or a family funeral?

One the one hand there is insurance, which usually addresses business continuity issues for a fixed amount. On the other there are much simpler tactics such as documentation and planning. I have occasionally met programmers who boast that they never need to comment their code. Don't believe them. Comments don't slow down modern code and don't usually waste space. (Big JavaScript libraries like JQuery are a notable exception but even then you can get a long version and an optimised/unreadable one.) Get everyone talking about what they are doing. If you're a one-man-band then think about asking a friend to act as back-stop for you.

Your client will feel more comfortable if you have some system in place to cope with exceptional circumstances and, in most cases, a deal of a day or two while the backup person gets up to speed will not be a problem.

Thursday, 6 October 2011

Emotional responses to iMedia sites: an internal training session

In your scoping of the new client's sites we have recommended that you take some time to question the type of response they expect/want from their users. This should stand you in good stead for the look and feel aspects of the site. Perhaps you've found it difficult to get clear instructions here. That would be understandable. You might have tried getting the clients to look at previous iMedia sites you've designed and have noted their responses. Otherwise you might have asked them to tell you which sites they've liked generally and liked from their competitors. There are various ways to tap into what may be a hidden emotional reaction.

But are you applying the same probing to your own company and your employees? Are you educating your own staff by cross-fertilising their creativity and experience? It will be a complete eye-opener for you to find that the different specialists in your team will probably have a specialist bias in relating to what they consider 'good' iMedia sites. This emotional response will lie at the heart of the potential conflict between the members of your team. Give it a go for an internal training/awareness session, perhaps during one lunchtime.

Get several cross-functional team members together: design, build, project managers, marketing or whatever. Ask them to demo one of their favourite websites (not any of your own) and explain why it is – in 5-8 minutes. Note down the key words they use to describe why it is positive. These should indicate their bias/specialism. If there are common words used across the specialisms, these will be core essentials for website design that underpin your website developments. These in themselves might be surprising. But what about the other concepts that show bias and are mentioned? These might indicate the types of dissension that can happen across a team during project development. They may be 'good' in a narrow specialist sense but not in a general sense. However, a client may want a bias – say a marketing bias – in their site but they haven't been able to vocalise their wish. Then the leaning towards the specialist bias of what is 'good' in a website might become dominant for that project. And so on...

What's your favourite website then? Have a go yourself at this exercise. And to help maybe, here are a few links to what other people consider 'good'.
After your look at websites, repeat the exercise for other forms of iMedia sites too.