Making sure your website works in every browser can be a lengthy process. Luckily, help is at hand
To build a successful website, you have to do more than just put the pages together using a tool such as Dreamweaver or Frontpage. You also need to test and optimise the site. This is usually done by developing with one or two browsers and then testing the site on a few more.
Links are tested with the help of the site map when the site is finished. Often that’s as far as testing goes, and it leaves gaps. This approach misses some important browsers, perhaps because no Mac or Linux setup is available for testing. And dead links and similar errors are difficult to track down by hand.
To ensure your site is working properly, you need suitable tools and a plan for testing. In this feature we’ll describe a typical test cycle and look at some useful tools and optimisation tricks.
Browser compatibility
If beauty is in the eye of the beholder, on the web it’s often due to the
browser. What the user sees in their browser can determine the success or
failure of the site. It’s obviously crucial to know what individual browsers can
do. You can find lists comparing the capabilities of browsers at sites such as
this.
If you’re a web designer you’ll also have to do a juggling act with various operating systems. Konqueror needs to be tested on Linux, Internet Explorer on Windows and Safari on the Mac. Konqueror and Safari might have common roots, but they are now sufficiently different that you need to test your site with both.
If you find it impractical to keep multiple computers or partitions running different operating systems, the best solution is virtualisation. A virtual computer runs in its own window on your system.
Microsoft offers two products for this: Virtual PC 2007 and Virtual Server 2005. Virtual PC is fine to test websites and the Windows version is a free download. The Mac version of Virtual PC has to be paid for unless you own the Mac version of Microsoft Office Professional.
VMware offers a much wider range of products. Its entry-level product is the Player, which enables you to run previously created virtual computers, and can be downloaded free. You can find a wide selection of virtual computers for use with the Player here.
If, however, you would prefer to create your own virtual machine, then you will need to buy at least VMware Workstation version, although the free sample virtual machines will often do for simple testing.
Screenshot services
Virtual machines are practical for testing but require a fairly powerful host
computer to run on, and all of the browsers to be tested have to be installed
and configured. That’s a lot of effort, especially if you want to cater for the
more exotic browsers.
Help is at hand in the form of websites that capture browser screenshots of a specified URL. All you have to do is to put the site to be tested on the web and then request a screenshot.
Browsershots.org is a good free service. Currently, it’s still in the testing phase, and to ensure reasonable performance it works with a queueing mechanism. This means you enter the URL to test and the browser and resolution to use and then you’ll receive a URL for the results. You can check the address regularly until the screenshots have been made, and you can use the Queue page to see the current state of the queue.
This service has its disadvantages. The queuing obviously doesn’t help your workflow, and both the queue and screenshots are publicly available. In addition you can’t take screenshots of areas protected by HTTP authentication.
Many web developers have access to all of the big browsers except Safari, which is only available for Mac OS X. Help with that is offered by sites such as Browsrcamp.com, which specialises in providing free Safari 2.0 screenshots.
The screenshots this service provides don’t show the browser frames; if you do need to see them, we recommend Webdesignerstoolkit.com. This has Photoshop files of the various current browsers at different resolutions. Thanks to the clear way in which the layers are structured, draft designs and tests can easily and quickly be inserted.
As well as the free screenshots, Browsrcamp offers paid-for remote access to a virtual Mac; prices start from $2 (about £1) on a daily basis, reaching $100 for a year. Screenshots are also available from commercial sources such as Browsercam.com.
The big advantage here is the huge choice of browsers and operating systems. You can also request screenshots of sites protected by HTTP authentication. There’s also remote access to various operating systems. The prices for screenshots start at about $20 (about £10) per day, and a year’s access costs about $340 (about £174).
Running more than one version of IE
A common problem for testers is that you can’t install different versions of
Internet Explorer; each one will replace the other, so many web developers
resort to using virtual systems with a different IE version in each. However,
there is a workaround for installing multiple versions of Internet Explorer, and
you’ll find a handy install routine for it
here.
You should only use this solution on test systems or on a virtual PC, as older versions of IE are not always stable in combination. The installer includes Internet Explorer 3, 4, 5, 5.5 and 6. You can install Internet Explorer 7 in parallel. Javascript is supported, alongside HTML and CSS.
Futureproof with XHTML
XHTML is one of the key buzzwords for web designers. You gain little from XHTML
conformity in itself. The most important argument in its favour was always that
HTML should follow the XML rules in order to be portable and editable in
different parsers. But this is usually brushed aside in practice, as that kind
of flexibility is really only required in very complex workflows.
On an ordinary website, HTML’s only purpose is to enable the browser to display content – and at the moment it still does not matter whether HTML or XHTML is used. XHTML conformity is usually only introduced along with CSS layouts and accessibility optimisation, as it does not require much additional effort. If you’re concerned about future-proofing your newly created website, however, XHTML should be the language of choice.
Valid code
You can complain about this bilingualism, or you can take a more relaxed
attitude, like the father of the web and W3C chairman
Tim
Berners-Lee. Accepting that HTML and XHTML can exist side by side is
arguably more appropriate to the real world than vehemently demanding
standards-compliant websites.
Whether you choose HTML or XHTML, it’s crucial to stick to the standards. Newer browsers, such as Internet Explorer 7, adhere more closely to them and are more likely to give display errors with sloppily coded pages – so validating your code is vital.
The first port of call should be the W3C’s official validators for HTML and XHTML, and the css-validator for CSS. In addition to this, similar tests are implemented in the current versions of HTML editors such as Dreamweaver.
Many editors make use of Tidy or similar libraries which clean up your HTML and CSS code. Tidy came from Dave Raggett and is now available as a command-line tool and as a PHP library. The main project is hosted by Sourceforge.
Accessibility
Even if accessibility is not your top priority when first designing the pages,
accessibility test tools can be very useful as an adjunct to simple validation.
And, of course, you will need to consider accessibility sooner or later.
The W3C offers testing tools and there are other testers available online. One classic is the offering from Watchfire, which was originally called Bobby. Watchfire’s tools are integrated in many HTML editors. An unusual online test can be found here. The results of the analysis are shown on the page with icons and you can click on the icons to see sub-pages. A similar approach is taken here. The source code is displayed, highlighted for accessibility.
Most of these testers, of course, work on a ‘snapshot’ basis. It’s more difficult to evaluate the overall user experience and usability of a site with automated tests. Although there are some tools that attempt to filter at least the most common errors from the code, they are really just academic and experimental in nature. The only really effective way to test usability is with real users.
Once you have HTML code and browser compatibility under control, it’s time to perform more specialised tests for particular purposes. For search engine optimisation a good starting point is the basic test offered by Seekport. The site’s Seekbot tests your site against vital criteria for search engine friendliness.
Search engine optimisation
There are plenty of sites that offer classical link tests; you can find one list
of them
here.
Some of the free ones work in a similar way to the free browser screenshot
service – you have to join a queue and wait to receive a URL where you can
retrieve the result.
Link checks do not have to be carried out as an online test, but can be performed as a script, because the underlying logic is not particularly complicated.
Link checking is the basis of all search engine optimisation. You can check the links that point back to your own site. To do this, www.check-link.com provides a useful online tool. The results also show estimated page rankings. Other sites provide a similar forecast, as of course does the Google Toolbar.
There’s a lot more that the diligent web developer can do to check their site before it goes live. There are software tests and load and stress tests, to check the resilience of the webserver. This begins with working out the download times and server response times.
There are free online tests, and commercial solutions such as Froglogic’s browser-independent tests and comprehensive test suites from Empirix or Mercury. However, these solutions can be costly, and are far more than most small sites will need. You can find a roundup of tools here.
Read the benefits
Websites obviously need to be tested. What isn’t so obvious is how to do it
thoroughly – without taking too much time. Our collection of online and offline
utilities is by no means comprehensive, but it should save you a little time and
give you a few new perspectives. Because if testing in other browsers becomes
less trouble, it might be done more often in future. And that’s to everyone’s
benefit.
Useful tools for testing your site
- Capabilities of the
individual browser
-
Browser
compatibility for CSS
-
Virtual
PC
- Vmware Player and assorted virtual computers
www.vmware.com/download/player
www.vmware.com/vmtn/appliances
- Free browser
screenshots
- Free Safari
screenshots
- Installing multiple
versions of Internet Explorer
- W3C HTML and XHTML
validator
- W3C CSS
validator
- List of
Accessibility test tools
- Online accessibility
test
- Optical accessibility
test
-
Accessibility
test with source code viewer
-
List
of link-checking tools