10 Measures for Continuous Website Maintenance

Jens Meiert, June 24, 2008 / November 4, 2008.

This entry is filed under Web Development, Usability, Design, User Experience.

Website maintenance and quality assurance mean the backbone of high quality offers of information, and they represent the difference between an amateurish or professional approach to web design and development. Consequently, guidelines for quality web design define maintenance and quality assurance as important process ingredients which have to be applied continuously. But let’s see what this really means for our work.

Please note that the following list of measures does not target “initial” quality assurance. It assumes that websites are displayed correctly in popular user agents, and that HTML elements are used according to their semantics. Additionally, it prefers web-based tools over software that has yet to be installed.

Plausibility Checks

One of the most important aspects of website maintenance and QA is to check the necessity and “plausibility” of all website parts, be it certain sections of the site, certain publications, or certain widgets and gadgets. And even though it is advisable to have a clear picture in mind when creating and establishing a site, it pays off to regularly check if everything the website offers is really useful and does really provide value for the user. Questioning the use of a “Wallpapers” area on a personal website makes sense, as does checking the benefit of a prominent “Admin” section or the value of an imaginary corporate “Links” collection. Checking plausibility does not only help to avoid unnecessary work, it benefits your “face to the world” by sharpening its profile as well.

Tip: Ask yourself if you’d expect a certain feature on a similar website (unless you know it’s of special value).

User Tests

While tests with users are especially crucial in the early stages of website creation and revision, they are also important in operation, by providing important insight into the usability of a website. Continuous tests might not just reveal flaws in former tests – for example, when tested with only a few or very specialized people –, but also indicate changes concerning conventions or general perception. There is no alternative to testing with users, and testing is always helpful.

Tip: From time to time, ask friends or colleagues to e.g. contact you via your website, and observe how they perform.

Content Maintenance

Any content being published should not only be double-checked before release, it should also be checked continuously after release, as it is really important to keep content up-to-date. However, once an article or post truly gets “stale”, a quick update or comment might already suffice to inform readers about the development; as a last resort, you could (perceivably) note that the content in question is “probably outdated”.

Tip: Check some older articles if they still contain current information.

Proofreading

Copy editing might basically be seen as a part of content maintenance, but it can be separated because of two important reasons: On the one hand, orthographic mistakes can fly under the radar for a remarkably long time, on the other hand do spelling mistakes evidently have a negative impact on credibility. Usually you want to make sure that what you write is true and correct.

Tip: Print some of your articles and check if they contain any typos (they will).

Link Checks

Cool URIs still don’t change, but practice doesn’t necessarily embrace that. And even though external resources feel like it’s others who are responsible for these links when pointing into nowhere, it’s easy to take care of links by regularly firing up W3C’s Link Checker or Site Valet’s Link Service, among others. Don’t let your visitors get angry about broken links – or you.

Tip: Schedule at least a monthly link check, when possible automated.

Load Time Checks

Load time is an important factor of the experience a user makes with a website; speed is an attribute of good web design. Not all visitors are waiting for a truck full of decorative elements; observe yourself. Concerning continuous QA, load time and performance are especially interesting since they are – like user tests – necessary to be checked upfront, but are useful to be tested regularly as well (for example, via Pingdom or WSO’s Web Page Analyzer) to avoid inefficiency due to e.g. teaser image or code changes.

Tip: Try to find a machine with a slow connection (or eventually use your mobile) to remember the times where we had no broadband access.

Validation

Invalid documents and style sheets can often (not always, actually) be considered a result of sloppy, unprofessional work. Similar to a house, a website won’t necessarily collapse when there are a few bricks missing or not in the right place, but the web developer in charge should answer the same questions as the bricklayer. Quality assurance of websites explicitly includes validation. The more flexible maintenance of a site occurs and the more people work on it, the more often tests should be carried out, for example by W3C’s HTML, WDG’s HTML (including the option to validate 100 pages of a site), or W3C’s CSS Validator. As a matter of course, deficits should be fixed.

Tip: Make validation a routine, even with style sheets, and look for ways to automate this (probably you or your company already runs certain tests that could piggyback HTML/CSS validation as well).

“Change, Measure, Change Again”

As one of the key processes of web analytics, it is not just beneficial for “website monetization” but also for website quality to repeatedly change things and then measure these changes. For example, you might change the position of the login/registration section, track the results, and probably change again. Or you might add a “social bookmarks” widget, measure the outcome, and eventually change again. Or you might adjust some colors, confirm the impact on the element in question’s prominence, and probably modify again. Performing and testing little changes will mean huge benefits for both your visitors and your site, and this process can certainly mean the supreme discipline of professional website design – and maintenance.

Tip: Play with your website ads by modifying their position or layout for at least a week; compare the results and feel the power of “change, measure, change again”.

Additional Tests

The quality of a website can be evaluated and improved by a whole bunch of additional tools. Depending on technologies in use and site update frequency, this should be done regularly as well to avoid user frustration, technical issues, higher costs, as well as professional reproaches.

Tip: Explore the abundance of available optimization tools by e.g. taking a closer look at UITest.com, The Scrutinizer, or The Web Developer’s Handbook.

Rewards

The author just cannot share his experience with maintenance and QA without pointing to the fact that it is helpful to ask and reward visitors for pointing out mistakes in order to spot them and milden their effect. Even though Don Norman doubts the commercial capability of this approach anyway, encouraging and rewarding error reports easily increases the likelihood of noticing otherwise invisible mistakes by a factor of 10. (Donald Knuth must have recognized that even years ago.) Quality has its price.

Tip: Offer your visitors some kind of incentive for mailing you when noticing typos and the like, and observe what impact that has on both frequency and quality of these mails.

Enjoy the most popular posts, probably including:

Comments

On June 25, 2008, 4:51 CEST, John Faulds said:

On the one hand, orthographc mistakes can fly under the radar for a remarkably long time, on the other hand do spelling mistakes evidently have a negative impact on credibility.

Were the spelling & grammatical mistakes in the above sentence intentional to illustrate a point?
On June 25, 2008, 19:54 CEST, Ben Dodson said:

Maybe you should go to http://meiert.com/en/help/quality/ and list them.. then you’ll get a reward

Good article BTW.
On June 27, 2008, 18:44 CEST, Jens Meiert said:

John, not really (though it/they did, I guess), and I finally managed to fix the most obvious one

Ben, indeed, though I appreciate that John pointed the mistake out in a comment

Jens Meiert