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?

Advertisements

Using Yahoo! Pipes to filter an RSS feed

Pipes

I’m currently working on a redesign of the University’s research homepage which involves a requirement to pull in three RSS feeds:

  1. Recent research outputs (from the PURE research portal, which hasn’t gone public yet)
  2. Recent research activities (from the PURE research portal)
  3. Research news (from the main University news page. But this third feed needs to pull in only those stories that are related to research.)

Using PHP SimpleXML

I’m using the PHP SimpleXML extension to pull in the news feeds, extract the data that I want and then output it onto the Web page.  For the first two feeds that was simple, I created a PHP function to which I would pass two parameters, the URL and the number of posts I wanted to display on the page:

getNews($url, $postsRequired)

As the name suggests SimpleXML was very easy to use. SimpleXML converts the XML document into an object which you can then iterate through like a collection of arrays and objects.  It’s great if you already know the structure of the XML document (which we do because a) it follows the RSS 2.0 standard and b) we generated it).

So to load  a new XML document you use the simplexml_load_file() function:

$feed = simplexml_load_file('http://www.st-andrews.ac.uk/rss/news/index.xml');

And you then gain access to the different elements as you would using ordinary object properties. So for an RSS 2.0 file which contains this data:

<rss version="2.0">
  <channel>
      <title>News feed from The University of St Andrews</title>
      <link>http://www.st-andrews.ac.uk/rss/news/index.xml</link>
      ...

I could use this code to grab the feed title and URL:

$feedTitle = $feed->channel->title; // get name of RSS feed
$feedURL = $feed->channel->link;    // get URL of RSS feed

In this case $feedTitle would equal “News feed from The University of St Andrews” and $feedURL would equal “http://www.st-andrews.ac.uk/rss/news/index.xml&#8221;.

But I only want Research news

The third feed required a bit of thinking because I don’t want to simply pull in all the latest news, I only want the latest news articles that relate to research.

To help us the RSS specification allows content creators to add any number (zero or more) of <category> tags to each news item, e.g.

<category>News</category>
<category>Research</category>

When a content creator adds a new news item to our content management system they have an option of selecting a category from a drop-down list; this populates a category tag in the RSS feed.

I realised that I then had two options:

  1. I could write into my PHP code a script that would filter out any posts that were not tagged with the Research category.
  2. Use an external, third-party application to do this for me.

Yahoo! Pipes

In the end I opted for Yahoo! Pipes simply because it was much quicker to have Pipes filter the news RSS feed for me than it was for me to write a PHP parser to do the same.  (“I’m a PHP coder of very little brain”, as Winnie the Pooh might say!)

But I then realised that an attractive side-effect of this was that I then had a new RSS feed that not only I could use but that other users could subscribe to it as well.

Screenshot of Yahoo! Pipes fetching an XML feed, filtering it and then outputing the results

Screenshot of Yahoo! Pipes fetching an XML feed, filtering it and then outputing the results

Yahoo! Pipes was really simple to use and the feed filter took less than a minute to set up.  It just involved three stages:

  1. Fetch the feed.
  2. Filter the feed, permitting only items that matched the rules I set.
  3. Output the results.

Making the Student Handbook mobile-friendly

Yesterday I wrote a post about our first steps into the mobile web. Today I will look at what I had to do to make it happen.

Learning about the principles

The first step was to think about the principles behind mobile web design. I am well versed in the principles behind desktop web design, but mobile is a different ball game. The focus is even more strongly centred on a streamlined approach — less is more.

The only other thing I really knew is that there are no easy answers. I had to do my research.

The first question to ask myself was, is a three year old book about mobile web design still relevant? Gareth let me borrow this book, and while parts of it feel out of date, there is still plenty of insight to chew over. It is particularly useful when thinking about older or non-‘smart’ mobile devices. There is a tendency nowadays for articles about mobile to be heavily focussed on iPhone and Android. While this book does feature the iPhone, it is much more about the wider principles of mobile web design.

I also found it useful to take a look at Patrick Lauke’s slides about the mobile web, which he delivered at IWMW. These are more up-to-date, and it was useful to refresh my memory about what I had learnt.

There are three major approaches to tackling mobile:

  1. Do nothing and hope for the best.
  2. Create a separate mobile site.
  3. Adapt what already exists.

Option 3 was the only one really open to us. This option requires compromises to be made. It probably also leads to the largest file sizes. But it is easier, and if you use web standards and code your website well, it should work well enough on a mobile device.

The stylesheet

The first step was to create a stylesheet optimised for mobile devices. A decision was taken early on to focus on the current generation of browsers, as mSaint is designed primarily for smartphones. Mobile Safari, Android and Opera Mini and Mobile all ignore stylesheets with the attribute media="handheld". Modern mobile browsers like to think of themselves as a cut above that sort of thing. They try to render a webpage more or less as you would expect it to on a desktop.

(Handheld stylesheets have always been shakily supported anyway. I have created one nonetheless as a fallback for any mobile browsers that prefer to deliver a webpage in this way.)

But accepting that modern mobile browsers will render the desktop version was not an option in this case. The technique around this is to use CSS3 media queries, which allow us to dictate which stylesheet is used based on the width of the device or browser window. Perfect for adapting content for mobile!

There is a good tutorial on how to use media queries. Guess which browser doesn’t quite like it? Internet Explorer’s issues were the source of some of the biggest puzzles I faced. But since I figured out how to make IE play nicely, it has worked well.

Design

So that it integrates well with mSaint, we have removed a lot of the devices that you find on a standard University webpage. The header, main navigation, left hand navigation and footer have all gone. Basically, everything except the content has gone. Thank goodness for display: none;!

Much of the rest of the stylesheet has been lifted straight from the existing stylesheets. So it should look and feel pretty familiar to regular users of the University website. The other major change I made was to lay out all of the content so that it sits in one mobile-sized column. So any items that appear in the right hand sidebar on the desktop version of the Student Handbook will appear beneath the main content on the mobile version.

When deciding on the ideal width of the column, I settled on a maximum width of 480px. This is the width of an iPhone in landscape mode. But I did not just make this decision with iPhone goggles on. Looking at standard screen resolutions for mobile devices (QVGA, HVGA, VGA and WVGA), 480px is the dimension that comes up the most.

Viewport

The main thing that I have learnt that I was not aware of before is to do with the viewport. The iPhone automatically displays every webpage as though it were 980px wide, and this becomes the scrollable area of the webpage. But if you have optimised the content specifically for mobile display, this is no good. The text is zoomed out and unreadable. The user must manually zoom in, even though there is absolutely nothing on the rest of the page.

The answer is to use the viewport meta tag:

<meta name="viewport" content="width=device-width" />

This tells your mobile browser to automatically zoom in as though the web page were as wide as the mobile device. You can also set a specific width, as well as setting an initial scale and control how far the user can zoom in and out. Originally introduced by Apple for Safari, it seems as though most modern mobile browsers recognise and support this — though this hasn’t been without its problems.

I have been a bit iffy about including the viewport meta tag on these standard web pages. From what I gather, its presence is supposed to indicate that the webpage has been optimised for mobile, which ours hasn’t. It also appears to alter the behaviour of Opera Mobile (by disabling the mobile view option). However, it appears to have no effect on the way desktop browsers display the page, while making it look much better on mobile devices. So we are sticking with it for the time being.

But just when I had got my head around how to control the viewport, imagine my shock when I discovered that a pixel is not a pixel. That is to say, the number of pixels on your device is not the same as the number of pixels that appear to be displayed. Accommodating different screen sizes and resolutions seem complicated at first, and unfortunately it only becomes more complicated as you learn more!

Apple have a very useful guide for developers called Safari Reference Library. It was hugely useful in helping me understand about the viewport and a lot of the other quirks of Safari for iOS, such as automatic text resizing. I think Safari tries to be too clever for its own good sometimes. This makes it a brilliant mobile browser overall, but it is quite frustrating as a developer to try and work out precisely what it is doing.

Incidentally, Opera also have a good mobile web optimisation guide.

Testing

Testing for mobile is notoriously difficult. There are hundreds of different devices, operating systems and browsers out there, with radically differing capabilities. Testing every possible combination is even more impossible for mobile. It makes designing for desktops look like a piece of cake.

The book Mobile Web Design by Cameron Moll contains a highly interesting section about Yahoo!’s procedure for testing their 2006 FIFA World Cup mobile site. By selecting a range of 5-10 devices from top- to bottom-end to test on, they felt that they had covered a wide enough range for the website to work on most mobile browsers. The technique paid off for them as it was a hugely successful website, attracting a peak of 290 million page views in one day. And that was four years ago. Incredible!

We are not aiming for that sort of audience, so our testing has been an even more modest affair. I used my own iPhone to test it in Safari and Opera Mini. But this has been quite frustrating as it is very difficult to get a signal in my office. Upstairs, my colleague has also been testing on an Android emulator.

The Opera Mobile emulator has also been hugely useful, particularly for comparing different screen sizes. How important Opera Mobile actually is, I am not sure. At the end of last semester, around 1% of visits to the University website were on a mobile device. Among those users, Opera does not appear to figure as highly as I had expected.

There is more information about mobile emulators here. These are highly useful tools for finding out how a mobile browser will render a page. But unfortunately they tell us little about how it genuinely feels to use a website on a particular type of device.