Outsourcing

Introduction

If you are concerned about making your website accessible over low bandwidth connections and you don't have your own in-house web development team then you will be considering outsourcing to a web design company. Even if you ask your web designers to make your site globally accessible, will they know what that implies? How can you be sure they have created a design that will work over low bandwidth?

The purpose of this outsourcing guide is to help you write a tender document with clear acceptance criteria for a low bandwidth design. We will also show you how to verify that your website adheres to your criteria.

Iterative and Incremental Design

If you are outsourcing your website development, you may find it hard to know at the outset exactly what you want. Even if you start out thinking you do know, you will probably find that your views change as the project progresses. So, rather than aiming for a watertight technical specification at the outset, we would recommend that you manage the work as an incremental process. Specify in broad outline what you require and then refine your ideas as the development progresses, reviewing what is produced in an iterative cycle. This method of working — following an "Agile" methodology — is particularly well suited to website development and should make for a more flexible and efficient way of arriving at a result you are happy with. The interested reader is referred to the Agile Alliance [1] for more discussion of this.

User Testing

User testing is often seen as a costly, time-consuming process and so is often avoided. This is a mistake. Every site is unique and user testing is the only way to really find out if your design works. Testing with randomised selections of users, heavy-duty questionnaires and professionally run tests in a testing laboratory is costly, but you can get most of the benefit from a much simpler test. All you need is one or two users trying to carry out typical tasks with an observer sitting next to them taking notes. It is far better to test frequently throughout the project, when problems can be fixed, rather than once at the end.

Simulators and Analysers

Viewing your website through a simulator makes it possible for you to experience it as your users will who are viewing it over low bandwidth. This can be a very sobering experience and is an important part of the testing process. Analysers are also important tools, allowing you to see if a site conforms to recommended limits on such things as page size. For details and useful links see Tools.

The Use of Acceptance Criteria

One of the difficulties in outsourcing technical work is specifying what needs to be done. Really the most important thing to specify is the "What" — if the developers are competent the technical "How" is probably best left to them. Specifying acceptance criteria is a good way of saying "what" needs to be done, in other words what you will accept. The acceptance criteria that follow are designed to give a set of quantifiable requirements that can be put into a contract and can be used to measure the final product. After the criteria themselves we discuss why each requirement is important and how you can verify that it has been met.

Acceptance Criteria

The Final Website Should Meet the Following Acceptance Criteria:

  1. No non-incrementally loading page should exceed 25kB in size, including images, external JavaScript files and external CSS files.
  2. No incrementally loading page should exceed 75kB, including images, external JavaScript files and external CSS files. Incrementally loading pages should display useful content within the first 5kB.
  3. The main navigational links should load first to allow the use of the most likely link before the page has completed loading.
  4. All links to objects over 75kB should be clearly labeled with the size of the object.
  5. At least Internet Explorer 6 and 7 and Firefox 2 should be supported.
  6. Static content should be used where possible. Where dynamic content is used, scripts must set and check last modified dates to enable caching.
  7. The HTTP Expires response header should be set by the web server for every resource returned to requesting clients.
  8. Cache-control headers should not be used in such a way as to entirely disable caching.
  9. Pages should not auto-refresh.
  10. Compression must be enabled.
  11. The W3C standards must be complied with and the compliance of the final website validated.
  12. Formatting should not be embedded in the same file as the content but should be performed using an external CSS file or files.
  13. The site must still be usable if image viewing is turned off. A text alternative must be provided to all images and they must be scaled to the size they will appear in the page.
  14. All the functionality of the site must still be available with JavaScript turned off.
  15. Cascade high bandwidth media. If video is present also provide audio-only and text-only versions. If PDFs are present also provide HTML or text-only versions. If large images are present, link to them using thumbnails or low bandwidth versions.
  16. No page should require more than 10 HTTP requests.
  17. If PDFs are present then they must be optimised for low bandwidth. Vector-based graphics should be used to represent line drawings such as diagrams. If PDFs are large, alternative versions should be offered with different levels of image compression, or no images at all. Lengthy documents should be split into separate files.

Criterion 1: 25kB Limit for Non-incrementally Loading Pages

Rationale

This will mean that the page loads within an acceptable time (10 seconds over a 20kbps connection).

Verification

To check for compliance, each page of the site should be run through a web page analyser such as the Web Page Speed Report[2] service.

Criterion 2: 75kB Limit for Incrementally Loading Pages

Rationale

Where a page downloads incrementally users will be more prepared to wait longer (maximum 30 seconds) for the full page to appear, but it is important that useful content downloads relatively quickly (within 2 seconds).

Verification

The low bandwidth simulator [3] will make it possible for you to see the page loading as it would over slow connections. Set the bandwidth to 20kbps. Check that when viewed in this mode useful content is downloaded within 2 seconds, and that the whole page downloads within 30 seconds.

Criterion 3: Main Navigational Links Load First

Rationale

A user may not be interested in all the content on a page. If they want to navigate from it to another page they should be able to do so without having to wait for the page to load completely.

Verification

If your Internet connection is so fast that it is impossible for you to observe the order in which items download, the low bandwidth simulator [3] can be used to slow the process down so that you can check that the page behaves as it ought to.

Criterion 4: Links to Objects over 75kB Clearly Labeled

Rationale

It is important that users are given an indication of how large objects are before they start to download them.

Verification

This is initially a question of visual inspection. All objects that are linked to should have their size in brackets after the link, for example PDF Report (237 kB).

Criterion 5: Support for Different Browsers

Rationale

At least Internet Explorer 6 and 7 and Firefox 2 should be supported. Together, these three browsers account for over 90% of the market.

If possible, we recommend that you also test your site against other browsers: Opera, Safari, Internet Explorer 5, Firefox 1.5 and Konqueror which all have a small share of the browser usage market, and additionally older browsers such as Netscape 4 and Lynx.

Verification

You will need to download browsers that you don't already have so that you can test your website under them. For links to free downloads of a range of browsers see Testing Browser Compatibility .

Criterion 6: Static and Dynamic Content

Rationale

With static content it is easy for the system to make sure that pages are not re-downloaded unless they have changed since they were last accessed. This is not so simple in the case of dynamic content and it is important to make sure that the system is provided with information about whether pages have altered.

Verification

You will need to check that scripts send Last-Modified headers with each response. You should edit a page and then check if the date given in the header is as expected. Tools like Live HTTP Headers[8] will let you see your Last-Modified and Expires headers.

Criterion 7: Set HTTP Expires Response Headers

Rationale

Setting these headers makes pages load much more quickly.

Verification

Check that all web pages have a line of the form 'Expires: ' followed by a date.

Criterion 8: Caching not Disabled by the use of Cache-control Headers

Rationale

If done properly, caching can significantly reduce the bandwidth used by visitors to your site, especially regular visitors; however careless use of cache-control headers can disable caching. You should be aware that some Content Management Systems (CMS) and Wikis automatically generate cache-control headers.

Verification

Any of the following headers would break caching entirely: Pragma: no-cache, Cache-Control: no-cache, Cache-Control: max-age=0 (or negative).

Criterion 9: Pages Should not Auto-refresh

Rationale

If you want to have pages that auto-refresh it should be an optional feature that users must explicitly turn on. It is very easy for your users to accidentally waste huge amounts of their bandwidth and yours by having pages reload themselves automatically.

Verification

Check that neither Refresh: 0 is present in the HTTP Header nor <meta http-equiv="refresh" content="0"> is present in the HTML page.

Criterion 10: Compression Must be Enabled

Rationale

When enabled on both the web browser and the web server, compression can automatically reduce the size of text downloads (including HTML, CSS and JavaScript) by 50-90%.

Verification

The Firefox Web Developer Toolbar[4] lets you see if compression is turned on. Once you have downloaded the toolbar, clicking on Information > View Document Size will bring up a page of information that shows the size of the document. If compression has been enabled you should get two figures, showing the size of the page as it is and the size it would be if it hadn't been compressed, for example 7 KB (22 KB uncompressed).

Criterion 11: Standards Compliant

Rationale

W3C (the World Wide Web Consortium) is an international body working to establish web standards. Ensuring that a website passes their validation tests and complies with best practice will eliminate the problems that badly written code can lead to.

Verification

W3C provides validators for HTML[5] and CSS[6].

Criterion 12: Formatting Performed using External Style Sheet

Rationale

It is important to separate content from presentation for maximum efficiency of coding. If the content is written in a markup language such as HTML, rather than embedding formatting instructions in the code, the presentation should be handled by CSS (Cascading Style Sheets). Often the most efficient approach is to use a single external style sheet for the entire website.

Verification

Check for an absence of style tags in the web page and look for the presence of a CSS file.

Criterion 13: Usable without Images

Rationale

Images add significantly to the overall download time of your pages so it is important that they are used intelligently. Some users will be viewing your site with images turned off and it still needs to be usable in this situation.

Verification

Turn images off in your browser and make sure that the website is still functional. For example, in Firefox you would turn off image viewing by clicking through the menu Edit > Preferences > Content and de-selecting the tick box 'Load images automatically'.

Criterion 14: Usable without JavaScript

Rationale

Inappropriate use of JavaScript can waste bandwidth and reduce readability. Some users will have JavaScript disabled in their browsers and so you will want to be sure that your site will still be usable without JavaScript.

Verification

Turn off JavaScript in your browser and check that the website is still fully functional. In Firefox you would disable JavaScript by clicking on Edit > Preferences > Content and de-selecting the tick box 'Enable JavaScript'.

Criterion 15: Provide Alternatives to High Bandwidth Media

Rationale

Large media files may be too big to work effectively over low bandwidths. Provide lower-bandwidth alternatives where possible.

Verification

Check that audio-only and text-only versions are provided for all videos and text-only versions for all audio. Check that HTML or text-only versions are provided for all PDFs. Check that any large images are linked to using thumbnails or low bandwidth versions.

Criterion 16: No Page to Require More Than 10 HTTP Requests

Rationale

The download time for a new visitor to your site is largely based on the number of HTTP requests required to fetch all the page elements. Reducing the number of HTTP requests is an important way of improving the performance of your site.

Verification

Running a page through the Pingdom Tools[7] or Live HTTP Headers[8] will show you the number of HTTP requests that are being sent.

Criterion 17: PDFs to be Optimised

Rationale

Large PDFs, like other large media objects, can be difficult to download over slow connections. PDFs that are optimised for print rather than screen can be very large indeed. It is often the images and fonts that make the biggest contribution to size, but these can be optimised. Consider offering PDFs with reduced quality and splitting lengthy documents.

Verification

If you have access to a PDF audit tool, such as Adobe's Acrobat Professional[9], this can be used to analyse the content of the PDF. Failing such software, you should at least check that the PDF isn't larger than you would expect.


Footnotes

[#1] http://www.agilealliance.org/

[#2] http://www.websiteoptimization.com/services/analyze/index.html

[#3] Aptivate Low Bandwidth Simulator, http://www.loband.org/loband/simulator.jsp

[#4] Web Developer Toolbar, https://addons.mozilla.org/en-US/firefox/addon/60

[#5] W3C HTML validator, http://validator.w3.org/

[#6] W3C CSS validator, http://jigsaw.w3.org/css-validator/

[#7] Pingdom Tools, http://tools.pingdom.com/fpt/

[#8] Live HTTP Headers https://addons.mozilla.org/en-US/firefox/addon/3829

[#9] Adobe Acrobat Professional http://www.adobe.com/products/acrobatpro/