Designing in the browser

Cover of Implementing Responsive Design by Tim Kadlec

Implementing Responsive Design by Tim Kadlec (New Riders, 2013) ISBN 978-0-321-82168-3

As we begin to transition towards a mobile-friendly design and workflow, I’m thankful that for the last five or six years we’ve been designing primarily in the browser, rather than in graphic editing applications such as Adove Photoshop or Corel PaintShop Pro.

I’m one of these people that usually has numerous books on the go at the same time. One of my current books is this excellent book by Tim Kadlec called Implementing Responsive Design—Building sites for an anywhere, everywhere web (New Riders, 2013) ISBN 978-0-321-82168-3.

The world is changing. We now have more networked devices on the planet than human beings. In the UK people now spend around 16 hours online every week, on a variety of devices (desktop computers, laptops, tablets, smartphones, game consoles, etc.). Very shortly there will be more mobile devices accessing the web than desktop and laptop machines.

Therefore, we need to change too. One of the things the web team is currently looking at is our strategy for designing for mobile devices. We’re very much in the early stages.

What is immediately clear, however, is that this will have a profound effect on how we work as a team. Designing for today’s devices and users requires a different kind of workflow than we’ve previously enjoyed/endured (delete as applicable).

Old workflow

When I began in the web team in 2006 we would typically design a website as though it was a brochure. We started with a fixed width (around 950 pixels), and we used desktop publishing, image manipulation, and occasionally presentation software to design our sites.

It was a terribly inefficient way to work. We would first design it as though it was a document, and then have to interpret it for real in HTML and CSS to view in a web browser. It certainly wasn’t a DRY (don’t repeat yourself) process.

And it also gave our clients completely the wrong impressions. Once they had signed off on a design they expected the website to look exactly like the image we’d promised them on paper. In every browser. On all screen resolutions. And of course we couldn’t deliver it. Does anyone else remember, for example, trying to provide smoked-glass effect backgrounds on IE6, which doesn’t support alpha transparent PNG files, and modern browsers, that did?

On one website build we were brought in quite late on in the project to take receipt of a number of site designs and code them up for our content management system. It was one of the most frustrating projects I’ve worked on. We had no say in the design; we were effectively handed a photograph of a website and told “build that!”

As you might expect much of the interactive nature of the web had been ignored and we kept returning to the designers asking them “How did you envision this to work?” “This bit says ‘slider’ but where does the text go? What happens when the image reaches this part, does it slide underneath, over the top?” A lot of these things hadn’t been thought through because the designers had been used to designing for print, which is static.

A different workflow

When we worked on the current incarnation of the website in 2007–2008 I realised that we needed a more efficient workflow, and because I was more familiar with HTML and CSS than I was with the nuances of Adobe Photoshop I started designing everything in the browser.

The reasoning I gave people was very simple: nothing looks more like a website than a website. People understood that.

I found it liberating. It meant that we didn’t need to rework things: we didn’t need to sketch it in a graphics package and then code it later. It meant that we were given immediate feedback, and could see what it looked like in IE6 and deal with it there and then.

And it meant too that clients could get a very real idea of the effort and issues that go into designing a site, the issues with cross-browser compatibility (now that’s not so much of an issue), and they began to realise that not everything needed to be pixel-perfect in every browser.

To be honest, it was a little intimidating at first. If you’ve never sat in front of a client and written code (whether HTML or CSS) you can feel very self-conscious. What if you get it wrong and they lose confidence in you?

The truth is that not every designer or coder gets it right the first time. But that’s the truth whether there is someone sitting with you or not. And I found it helpful for the client to see that. “Oh! That didn’t work,” I’d say. Then I’d sit and talk through the issue out loud until I found a solution. It was helpful for the client to effectively see the working out of these issues, to see the scribbles and the code syntax look ups.

I would often explain that I would sketch it out in code, to make sure the idea worked, then I’d clean up the code later.

While I felt self-conscious, I often found the client was delighted. They could see their ideas taking shape on an actual website in front of their eyes. They could then immediately see what worked and what didn’t. It was a really effective way to work.

A responsive workflow

Now things are changing again. We’re not designing for a best-guess fixed-width site, we now have thousands of mobile devices to take into account.

We do have a lot to learn still, but we are on the right road, and already having a workflow revolves around designing in the browser is a tremendous help.

As Tim Kadlec says:

Until the wonder-tool comes along, it’s important to work toward loosening the grip of your favourite graphic editing program. Don’t remove it entirely, but start moving toward an more agile approach. Create the visuals as you code. Tackle the two hand-in-hand and you’ll be much better equipped to work on the Web. (ibid., p. 173)

Advertisements

Zeal and Dash—Offline documentation browsers

Zeal for Linux and Windows

Zeal for Linux and Windows

Yesterday I came across a really useful application for web development which has already sped up my workflow when needing to look for documentation: Zeal.

Zeal is available for Linux and Windows only, because it’s based on a similar application for Mac OS X only called Dash.

On my personal blog, I’ve written about how I’m using Zeal, and how I’ve configured it to be integrated into Sublime Text 3. It has been a real time-saver already: thoroughly recommended.

Which browsers do you support?

Five web browsers

Chrome, IE, Opera, Safari and Firefox

I’m currently working on a document of guidelines for our web team and web developers. Something that I’ve been asked to include is to indicate which browsers we support.

Digging around, for example, Yahoo! have their fine Graded Browser Support page which lists specific version numbers of various browsers. Google Apps, on the other hand, supports

“the current and previous major releases of Firefox, Internet Explorer, and Safari on a rolling basis. Each time a new version is released, [they] begin supporting that version and stop supporting the third most recent version.”

What do you folks do? Do you have browser support guidelines, either written down or not? Where do you draw the line (do you still support IE7, for example)? What are your criteria for what you support and don’t support?

And what about mobile devices?

I’d love to read your thoughts about this.

What developers think of Internet Explorer

I like this self-deprecating advert from Microsoft about Internet Explorer 9.

Only today I was thinking how refreshing it is that I now don’t have to worry too much about testing webpages in Internet Explorer 9. Everything just works now.

Sure, it doesn’t have the same level of support for HTML5 and CSS3 that Chrome, Firefox and Opera have but it does the basics really well and doesn’t have the same weird quirks that IE7 and IE8 have that require obscure hacks and workarounds.

Besides, at the moment all the major browsers have varying levels of support for these new Web standards-in-the-making. That’s why we’ve got tools like Modernizr.

Let’s hope that Internet Explorer’s support of Web standards grows from strength to strength.

Either that or they see sense and move to using the WebKit rendering engine! 😉

My favourite Web developer add-ons for Firefox

Mozilla released Firefox 4.0 on Tuesday—it has already been downloaded 16,041,437 times; that’s about 92 downloads a second!— and there is a lot to commend it for: a clean look, that’s not too far away from both Google Chrome and Internet Explorer 9 and it’s much faster too.

While I use Google Chrome for most of my day-to-day browsing I still use Firefox for Web development, largely thanks to the number of mature add-ons available for it. These are my favourites:

1. Firebug

20110324-firefox4-firebug

Firebug is the number one reason that I use Firefox. Sure, Chrome and Internet Explorer have their own Web developer tools but none of them come close to Firebug for its awesomeness.

That said, I recently tried out Opera Dragonfly and I was really impressed.

2. Web Developer

20110324-firefox4-webdeveloper

A close second is Chris Penderick’s Web Developer toolbar that adds all sorts of useful tools to Firefox: disable CSS, outline headings and tables on the page, show HTML classes and IDs, show image sizes as overlays on the images. Brilliant!

3. ColorZilla

20110324-firefox4-colorzilla

The most useful feature of ColorZilla for me is the eyedropper tool that allows me to sample a colour on a Web page and find out the RGB or HEX value for it.

4. HTML Validator

20110324-firefox4-htmlvalidator

HTML Validator does exactly what it suggests that it does: it shows HTML validation information in the Firefox add-on bar (what used to be the status bar) at the foot of the browser viewport.

It’s very useful for at-a-glance error checking; obviously, recognising that HTML validation is an ideal and a guide rather than a hard-and-fast rule.

5. Wappalyzer

20110324-firefox4-wappalyzer

Wappalyzer is a new add-on for me that adds to Firefox the functionality that I’ve been enjoying with the Chrome Sniffer extension in Google Chrome.

It shows you in the AwesomeBar what technologies are being used, e.g. JavaScript framework, server type, content management system, web statistics, etc.

6. RSS Icon in Awesombar

20110324-firefox4-rssiconinawesomebar

For some unfathomable reason Mozilla has removed the RSS icon that appears in the AwesomeBar when you visit a page that has an RSS autodiscovery tag, such as the University homepage.

That’s where RSS Icon in Awesombar (sic) comes in. It… well, puts an RSS icon in the AwesomeBar.

7. Tab Mix Plus

20110324-firefox4-tabmixplus

There are some options within Firefox that I still cannot believe are missing. There is still no way to, by default, open your homepage when you open a new tab.

Tab Mix Plus allows you to set this option—and a whole lot more, like being able to duplicate existing tabs, or protect or lock tabs so that you don’t accidentally close them.

Over to you…

What are your favourite Firefox add-ons, for Web development or otherwise?

Internet Explorer from version 1.0 to 9.0

Since Microsoft Internet Explorer 9 was released Andy—you know! Andy!—wondered what it would be like to install every version of Microsoft’s Web browser starting at IE 1.0 under Windows 95 and working all the way up through IE 6.0 on Windows XP to IE 9.0 which is only available for Windows Vista or 7 and compare them. His video is fascinating.

Acid tests

In the video he mentions Acid1, Acid2 and Acid3 (these links take you to Wikipedia) which are test pages that are used by browser manufacturers to check for problems in the way that they display Web pages.

  • Acid1 tests how a browser uses the Cascading Style Sheets (CSS) 1.0 specification.
  • Acid2 tests CSS 2.1 styling, HTML, PNG images, and data URIs (a way to include data within pages as though they were external resources).
  • Acid3 tests the Document Object Model (that is the structure of the page) and how the browser handles the JavaScript scripting language which is often used to add interactivity to a Web page.

You can check how well your browser does by clicking on the links above, which take you to the tests themselves.

The browser that I’m using to write this in (Google Chrome 11 beta) passes all three tests, even scoing 100/100 in Acid3. Internet Explorer 9.0 passes tests 1 and 2 and scores an admirable 95/100 in Acid 3; Firefox 4.0 scores 97/100.

But I digress…

Internet Explorer 3.0… without the internet

My first introduction to Internet Explorer was IE 3.0 under Windows 3.11 for Workgroups when I was learning HTML back in 1997. I wasn’t even connected to the World Wide Web, which is fine because the readme file suggested that the internet was just one option:

This product enables you to browse and view HTML documents on the network, in addition to documents on the World Wide Web or Internet. Other services, such as Gopher and FTP, and NNTP news support, are also available.

I still have the installer for Microsoft Internet Explorer 3.0 for Microsoft Windows 3.1 from November 1996).

Here are the system requirements:

  • A personal computer, 386 processor or higher
  • Microsoft Windows 3.1 or 3.11 or  Microsoft Windows for Workgroups 3.1 or 3.11
  • At least 4 megabytes (MB) of memory
  • A VGA monitor or better
  • A mouse
  • A modem with a speed of at least 9600 or a LAN  connection

Personal computers and the Web have come a long way since then.

Should we still be supporting Internet Explorer 6?

Keep calm and debug IE6

Keep calm and debug IE6

Every couple of months the same topic of conversation comes up in the Web team office: should we still be supporting Internet Explorer 6? The answer so far has always been a resigned yes, but that may not be the case for too long.

A little history: IE6 was released on 27 August 2001, three days after Windows XP was released.  Since then IE7 was released in October 2006, IE8 in March 2009 and IE9 public beta in September 2010.  So, surely it’s now time to withdraw support for a browser that is over nine years old.

Bring down IE6

In 2009 .net magazine started a campaign called “Bring down IE6“.

Bring down IE6

Their mission:

The premise is simple: Internet Explorer 6 is antiquated, doesn’t support key web standards, and should be phased out. This isn’t about being anti-Microsoft, it’s about making sure that we encourage people to move to modern browsers such as IE8, Firefox, Chrome, Safari and Opera.

Case-by-case

In an article entitled “Calling time on IE6” Craig Grannell “asks designers and developers if it’s finally time to take IE6 behind the shed and shoot it”!  He leaves the conclusion of the article to Web standards hero Jeffrey Zeldman:

How much longer we prop up this ageing browser must be decided on a case-by-case basis. Not every site can afford to dump it today, but the writing’s on the wall.

I think that’s a really important point because until recently the primary browser on the University’s default PC setup, that was installed on every Windows PC in the PC classrooms, was Internet Explorer 6.  If we wanted our websites to be viewable and usable across the University then we had to support it, we had no option.

Supporting IE6 is a drag. As all web developers will know, you spend a couple of hours building something that works perfectly in Chrome, Firefox, Opera and Safari and then you spend twice as long again debugging it in IE6 and IE7 and IE8, which all appear to have introduced new bugs to the game.  Keep calm and debug IE!

Analytics

Since the University’s default PC setup (‘standard build’) has now moved to Windows XP (and will hopefully soon move again to Windows 7) the default browser is now IE8, and s the requirement to support IE6 has now been reduced.

This is backed up by the statistics from our Google Analytics account that tracks which pages are being view most often and by which browsers.

Unsurprisingly Internet Explorer, being the default browser on our standard build PC, is the most popular browser to use to visit the University website; Apple Safari (the default browser on Apple Macs) is second.  42.5% of all visitors in the last month have used one version or another of Internet Explorer.  The breakdown of which version is interesting:

  1. IE8: 79.8% (382,394 visits)
  2. IE7: 15.4% (73,944 visits)
  3. IE6: 4.4% (21,186 visits)
  4. IE9 beta: 0.29% (1,395 visits)

That means that only 1.8% of all visitors to the University website last month used IE6. But 21,186 visits is still quite a lot.

Frameworks

Adopting the Blueprint CSS framework a few years back made a considerable difference to our development time.  Blueprint comes with a build-in IE hacks/workarounds stylesheet that addresses a good number of common IE5, IE6 and IE7 issues that has literally saved us hours and hours of hair-pulling.

Similarly we’re using the jQuery JavaScript framework which still supports IE6 and so makes cross-browser coding much simpler.

My view is that with such good support built-in to these frameworks for IE6 there’s really no excuse at the moment to completely drop providing a certain degree of support for IE6. The bugs are well known and the hacks are well-documented, and so finding workarounds for those that are not already contained in the framework files really doesn’t take that long to code these days.

Yahoo! graded browser support

However, it doesn’t mean that pages need to look pixel-for-pixel identical in every browser.  Something that is made explicit in the Yahoo! Graded Browser Support chart:

Support does not mean that everybody gets the same thing. Expecting two users using different browser software to have an identical experience fails to embrace or acknowledge the heterogeneous essence of the Web. In fact, requiring the same experience for all users creates an artificial barrier to participation. Availability and accessibility of content should be our key priority.

Over the last two to three years I’ve used the Yahoo! GBS chart to inform the Web team about how much support we should be affording to the various browsers.  IE6 is still granted A-grade support but it appears from a blog post “Graded Browser Support Update: Q4 2010” on the Yahoo! User Interface Blog that this is all about to change.

Listed among the various changes, which includes dropping A-grade support for Firefox 3.0 and initiating support for WebKit browsers on iOS and Android OS, is this:

Forecast discontinuation of A-grade coverage for Internet Explorer 6 in Q1 2011; we expect to move IE6 to the C-grade browser list as of the next update.

C-grade browsers, according to the GBS page are “identified, incapable, antiquated and rare.”

I would say that the bell is tolling for IE6 but it would appear from some corners of the Web that it has already rung out.  Google has already held a Funeral for IE6 after it withdrew support for the aged browser.  Microsoft sent flowers!

Conclusion

According to Google IE6 is already dead and buried, while Yahoo! are expected to degrade support for it in early 2011. Microsoft themselves, on the other hand, have committed to supporting IE6 until Windows XP SP3 support is removed in 2014; but that just means removing security issues rather than adding new features.  IE6 will never, on its own, support HTML5 or CSS3, for example.

So, should we still be supporting Internet Explorer 6? I expect that we’ll follow Yahoo!’s lead next year and move to providing only a base level of support for it.  When we move to using HTML5 and CSS3 then I expect we’ll have to drop support for IE6 completely.

We’ll make sure that content is readable but not worry too much about the presentation (CSS) and behaviour (JavaScript) layers; we’re already kind of doing that already in places, to be honest.  But as we’re using frameworks for CSS and JavaScript which still support IE6 the elderly blue ‘e’ may be inadvertently supported for a little while to come.

Then all we need to do is try to kill off IE7.  Who’s with me?

Window sizes and the fold

It can be difficult to design a webpage. Sure, there is a great deal of freedom. You are not limited by, say, the size of a piece of paper.

But there is, of course, a limit to what you can reasonably do with a webpage. One potential constraint is the size of a browser window. As monitors have increased in size over time, webpages have gradually become wider in order to fully use the available space.

Sometimes a web developer will be asked to optimise a webpage so that it looks perfect on a client’s setup, but not necessarily anyone else’s setup. While it may be common for something to be displayed at the bottom of a page on a physical publication, it is impossible to guess where the bottom of a monitor will be when designing a webpage.

Estimating browser sizes

There is not one set browser window size. While the vast majority of visitors use a display that is at least 1024 pixels wide, a handful are still using a display that is 800 pixels wide or smaller. Even then, there is nothing to say that the user has their browser window maximised! In essence, a user can be peering through a window as small or large as you can imagine.

Screenshot of the University of St Andrews website and browser sizes

To help us out, Google have a useful tool called Google Browser Size. This is probably familiar to those whose work focusses on the web. But it may be useful to other content creators and website maintainers to see this in action.

Google Browser Size shows you an estimate of the browser window sizes of web users. It displays this data like a map with contours, which is then overlayed onto your webpage. As you can see, 80-90% of users can comfortably view the full width of the University website.

What about the ‘fold’?

Where is the ‘fold’? Almost everyone has to scroll to view all of the content on a normal webpage. But when does this begin to matter? At the 80% mark, where horizontal scrolling stops? The 50% mark?

It is impossible to say. The truth is that web content should be accessible to all users. If the motivation is to stop people from having to scroll, arbitrarily selecting a percentage of people who must scroll is not good enough.

But we needn’t worry about squishing up our webpages so that no-one has to scroll. The fact is that scrolling is okay. We all do it. The fold is largely a myth.

Don’t worry about where the fold is. Of course, what appears at the top of a page is important. But cramming everything up there will overwhelm users. They would prefer to scroll. Just lay out your page so that it entices your users to read on.

Designing with all users in mind

The evolution of browser window sizes is one of those challenges that can make web design a tricky job. Just as developers have become accustomed to designing for monitors at least 1024px wide, the mobile web is ensuring that we must always keep smaller displays in mind too.

The beauty of the web is that there is great freedom. We really don’t have to worry about concepts like the fold. The trick is to embrace this freedom while exercising restraint.

Browser Wars – the next generation

On Monday Steve and I attended an Opera Software University Seminar hosted here at the University of St Andrews, one of many stops on their world tour of educational institutions.

I found it an interesting and encouraging hour long presentation which looked at the Opera range of browsers (did you know that there are four main products: Desktop, Embedded, Mini and Mobile, which all use the same rendering engine?), Web Standards and a brief dive into HTML 5 and CSS 3.  I’ve blogged about it elsewhere if you want to read more.

On our way out of the PC classroom (it was hosted in the School of Computer Science) in exchange for a completed feedback slip we were given a FREE umbrella. I know! FREE!  We didn’t even have to download it from one of over 80 download locations.

Comparisons

However, the question I know you’re all asking: how does it compare with the St Andrews Web Team’s Mozilla Firefox umbrella, which was purchased from the Mozilla store a few months ago?

Mozilla Firefox umbrella next to the Opera umbrella

Mozilla Firefox umbrella next to the Opera umbrella

Size

As you can see from the image above the Opera brolly is considerably smaller than the more cumbersome Mozilla brolly.

That observation correlates with my experience of the two browsers, currently Firefox is hogging 236 MB of RAM, while Opera is displaying the same three pages using only 34 MB. This is clearly the Opera Mini of umbrellas.

Opened each fares as you would expect: the Mozilla browser is considerably larger offering protection for more than one user.  The Opera Mini umbrella is clearly designed for single tab user use.

Mozilla Firefox umbrella open

Mozilla Firefox umbrella open

Opera Mini umbrella open

Opera Mini umbrella open

Rendering

Opera has clearly taken HTML 5 and CSS 3 to heart with this umbrella as in particularly windy situations the brolly dynamically re-renders itself … mostly inside out.  Ironically, for such a stable browser their umbrella does have a tendency to ‘crash’ alot in bad weather.  I suspect, however, that the weather we threw at it just had the wrong !DOCTYPE.

The Firefox umbrella on the other hand does appear to bend and sway a little but resolutely and reliably continues to do its job.

User interface

Both umbrellas feel robust enough, although I have to say that I would feel more confident taking the Firefox brolly out in the winds whistle down the streets of St Andrews.

In fact, in tests the Firefox umbrella proved to be easier and quicker to use simply due to the sturdiness of the fastenings and other hardware.

It is said that the first umbrella was likely to be nothing more than some largely-waterproof fabric stretched over a wooden or wire frame, and both models follow this tradition in terms of construction.  However, again, the Firefox brolly feels more robust with the stretched fabric stitches into the end of the spokes; the Opera brolly relies on small metal ‘cups’ slotting over the end of the spokes, which are too easy to knock off.

Security

Clasps on Firefox and Opera umbrellas

Clasps on Firefox and Opera umbrellas

Security is no less important on an umbrella as it is on a browser, and both models’ security features are built to impress.

The Mozilla model uses the traditional ring on a piece of elastic which wraps snuggly around the shaft of the umbrella and afixes on a button, while the Opera model relies on a vecro fastening.

One particularly impressive security feature though was the clear plastic sheath that the Opera umbrella came in.  It keeps your umbrella safe and secure when not being used.

Open Source

As an open-source product you are welcome to take the code of Mozilla Firefox and redevelop it.  While the brolly is available to anyone within the Web Team we discourage any modifications to the overall structure, and as far as I’m aware there are currently no official add-ons for the brolly.

Opera is not an open-source product, which is reflected in our need to go directly to Opera to obtain it on request.  Although, as I understand it, 3rd parties such as Oxfam may be able to sign up to distribute copies.

Conclusion

Other than the fact that I clearly have too much time on my hands during the lunch hour, I’d say that the Firefox umbrella is probably the one you want if you need to stay dry (in all sorts of weather), although it is more cumbersome. Perhaps, a bit like Firefox Portable.

The Opera umbrella on the other hand is wonderfully compact, so you can take it anywhere you want … a bit like their Opera Mini and Mobile browsers.

Launch of new website design

Screenshot of new website design

Screenshot of new website design

Following consultation with staff and students, and nearly nine months of work we launched the new website design for the University of St Andrews during the early evening of Monday (8 September).

Unlike the website launch in May 2007, which combined for the first time all 27 of the support unit websites into one enterprise-wide site, this re-launch was more of a design update than a radical restructuring of information.

Feedback sessions

Back in February 2008 we meet over the course of three lunchtimes with both staff and students to elicit feedback on what people

  • liked
  • disliked
  • thought was missing (both information and features)

Those sessions were very helpful, and feedback from those were thrown into a melting pot of ideas that had also been compiled from Helpdesk calls received since the launch of the new site in May 2007, as well as our own thoughts and observations from using the site for nearly a year (remember, we had access to it for a few before it went public).

Re-design goals

Our redesign goals were quite clear:

  • Make the site easier to read
  • Offer more variety/flexibility in terms of layout, e.g. 2, 3 and 4 column
  • Ensure that it works in more browsers
  • Add new functionality

On the whole we’ve managed to achieve this, and the feedback during the last month when the site was quietly released to staff and students within a closed preview has been very positive.

The techie bit

When designing and building a new site you have to decide from the start which technologies you will definitely support and which you will try to break as least as possible.

We’ve built the site around a grid-based CSS framework called Blueprint CSS, which offers us a number of advantages such as ensuring that the site is built using accepted Web standards, a well-designed and attractive typography. It also makes it painlessly simple to develop new site designs and layouts.

Much of the new functionality (such as the carousel of images on the homepage, and the tabs on the Current Staff and Students’ pages) is largely provided using the jQuery JavaScript library.

While writing new features using JavaScript can be a long and arduous process the jQuery library allows you to do it in a fraction of the time — some of the functionality added to the site took less than a minute to write! It also works with a lot of modern browsers (Firefox 1.5+, IE6+, Safari 2.0.2+, Opera 9+).

Browsers

Speaking of browsers, based on statistics gathered by our Google Analytics account as well as Yahoo!’s guidelines for Graded Browser Support we settled on ensuring that the latest browsers received the best experience possible.  This included:

  • Firefox 2.0
  • Firefox 3.0
  • Internet Explorer 6
  • Internet Explorer 7
  • Opera 9.x
  • Safari 3.x

We tested the site back to Firefox 1.0, Internet Explorer 5.0, OPera 7.5 and Netscape Navigator 7.0, with varying degrees of success.  On the whole though the site is still usable in these older browsers, even if it doesn’t look exactly as it does in a modern, standards-compliant browser.

One major issue that we have become aware of is that the site crashes when viewed in Safari 2.0.4 (419.3) on a Mac. The issue it would appear is to do with how Safari handles JavaScript.  According to JavaScript expert, and jQuery author John Resig:

“Safari 2 has serious memory issues that are impossible to work around – simply loading and executing too much JavaScript will cause it to crash.” (J Resig, jQuery discussion group)

Our advice, following the graded browser support guideliness, would be to either disable JavaScript or upgrade to a more modern browser, such as Mozilla Firefox (the site works in everything back to Firefox 1.5).

Going live

Going live with a site is a strange experience of mixed emotions. There’s a combination of both elation that the site is going live, mixed with a little anti-climax and the nervousness of waiting for support calls to come in, hoping that we haven’t missed anything obvious.

On the whole, as a Web Team we’re really pleased with the results and the encouraging feedback that we’ve had from users, but we won’t stop there … there’s much still to be done, content to be improved on, sections to be reorganised and even more features to be added.