This sparked a long and heated debate in a number of web design agencies and clients I am working with (or have worked with / for), whether it would be worth just dropping the support for Internet Explorer 6 and ask users to upgrade their browsers so that they can enjoy the website to the fullest.

Coming from a usability, accessibility, SEO and web dev background, I thought it might be a good idea writing why I would recommend supporting (or not supporting) IE6 in the industry I am working for.

Looking at our industry – what made IE6 stay

With the release of Windows XP in October 2001, users were greeted to the new – bundled – version of Internet Explorer 6. Companies, schools and universities planning on buying new hardware tended to use resellers such as Dell to buy a number of same-spec machines at a bulk discount – and with all machines either shipping with XP or Win2000, the reign of IE6 was established.

Some stock-checking and invoicing software would only work with IE6

System admins were able to roll out updates and software easily, as all machines were virtually the same, and keeping control of networks became relatively easy. Additionally, intranet software was bought or developed based on IE6, since every machine came with it this made development and testing a lot quicker and easier.

In November 2005, FireFox 1.5 became the first real free browser on the market to rival IE6 for its ease of use, and coupled with the ability to extend the browser’s capabilities through extensions it became the browser of choice – if you had the ability to choose. You see, the browser (just like 95% of all applications) needed to be installed. This wasn’t a problem on your own personal computer, but when trying to do this in an office environment (or any institution) then things were a bit more difficult: most users were not given administration rights to their machines to prevent abuse or installing malicious software. Most software requests had to go through a number of channels, from procurement (if licensing was involved) to IT (to see how much work was involved and how much time would be required per machine) to head of department (to sign the request off and add additional reasons for the request) to someone a lot higher up to ultimately sign the request off. A simple “Can I have software XYZ” could easily take months to get it approved.

Internet Explorer 7 was released on 18 October 2006

With the arrival of Windows Vista and Server 2008 in October 2006, Microsoft released Internet Explorer 7, 5 years after the release of IE6. At that time, IE7 was only available for Vista and Server 2008 machines, and it was not until October 2007 that IE7 was officially available for XP machines. Companies were once again given the option to roll out IE7 to every machine under their care, however this didn’t happen: rolling out IE7 to all machines in bigger companies or institutions would not only cost a lot of time and – more importantly – money (system admin time, potential upgrade costs, etc), but the software used for business purposes (such as stock management software, accounting or counter software) was built on or running on IE6, most of the time exclusively, and paying for this software to be upgraded was a very expensive option (and sometimes the company that wrote the software did not even exist anymore).

As such, IE6 came to stay with us, and it will probably do so for a long time to come unless Microsoft was to offer free upgrades to companies and allow backwards compatibility of IE6, if only at least for the software and not for the browser use. And I somehow cannot see that happen.

.

Affecting your target audience

Now this was the general “industry” as we have it out there this year. What needs to be considered is how much of that sector fits into your target audience. Every website offers different bits of information, services or products, and each website has a different target audience with different needs or requirements and expectations of the website (if you read my article on information architecture and user testing you will be aware of different user scenarios to test a website with).

The main target audience I am dealing with is the travel and tourism industry. Our target traffic (based on a survey conducted in Jan / Feb 2008 by three of my clients) is coming from:

• Users at work, looking at holiday packages and destinations at work during their breaks – ~ 65%
• Users at home, either planning with the family or reading up on what they found at work – ~35%

Just over two thirds of traffic is coming from people using company / education networks. Depending on your target audience it might be a good idea to look at where your main traffic is coming from to paint your own picture for your market.

.

IE6 today – the stats

Let’s have a look at Google Analytics. These are the June / July stats of a holiday cottage provider based in the UK (we are looking at a slow month):

Web stats from a holiday cottage provider. IE accounts for 71% of the traffic

Interesting picture, almost three quarters of all traffic is coming from Internet Explorer.

Let’s break it down:

22% of IE-using visitors are using IE6. Interstingly, a very small number are still using IE5.x

About 16% of all visitors are using IE6 to browse the website, read more information about the product or destination and make a booking. A fifth of all bookings are made using IE6 – very interesting fact to keep in mind.

.

Debunking some myths about IE6

Now having looked at the stats and a brief history, let’s have a look at some of the most commonly used phrases in the last couple of weeks from my industry:

Myth 1 – No one uses ie6 any more

Looking at the stats above, this simply isn’t true. The website usage of people using IE6 is still significant enough to not ignore it. Again, this depends entirely on your industry, but if you are working in travel / tourism / holiday properties then you really ought to keep that in mind.

Myth 2 – Developing for IE6 is difficult

That entirely depends on what you are planning to do. I have yet to encounter a problem that I could not overcome for IE6. Some websites (such as www.visitpeakdistrict.com for example) have been built by colleagues and myself with no IE stylesheet at all! There are plenty of resources out there to aid you (one of my personal favourite ones being the definitive guide to taming IE6 by Jeff Starr) with developing for IE6, from flickering backgrounds to missing text (usually it is just a width or height-issue anyway), and jQuery and other plugins still work reasonably well for IE6 and degrade gracefully if not.

Myth 3 – IE6 is bad user experience

Whoever said this clearly does not have a grasp of what “user experience” actually means. As a piece of software IE6 “works” (else it would not have passed QA at Microsoft), it allows for bookmarking, browsing, searching, information gathering and even levels for customisation, which I believe is delivering a pretty good user experience.

The user experience this person was talking about is not defined by the browser, it is defined by the experience the website has to offer! It comes back to the points above – if you cannot code properly for IE6 then it is you who is causing this user experience issue.

Myth 4 – No one supports IE6

Wrong. Many support IE6 still to this day, web developers, software companies, and even the most crucial web techniques such as jQuery or Flash support IE6 (hell, Flash doesn’t even support a 64bit plugin properly!).

Myth 5 – it is easy to upgrade your browser

Just because it is easy for you to upgrade doesn’t mean it is for everyone. Put yourself into the position of an office employee working for a big company. This comes back to the history of IE6 I mentioned earlier, upgrading a browser is difficult because:

• The computer you are using may have a very old operating system
• You may not have administrator rights to do so
• You may not be able to justify why you need to have a new browser, and approval may take a long time in a bigger company
• You may not be able to justify the time and costs involved to upgrade all machines with a new browser, let alone a new operating system.
• Software on your machine you are using for day-to-day work may heavily rely on IE6
• You don’t know how to upgrade

.

A lesson in history – when things went wrong (a case study)

A client of mine used this warning once. The result - over 2,000 complaings, 81% drop in traffic

About 2 years ago I was working with my team on a website for a relatively big UK travel company. Because the client wanted new functionality on certain product pages (interactive pricing grid and “add to basket facilities) they decided to make this available only to  certain newer browsers (against my company’s recommendation and to save development time), and set up an error message (see screenshot on the right) when visiting those new pages and asked us to monitor traffic in real-time for these pages and the whole of the website.

About 3h after putting these new pages (and this warning) up the CEO’s office rang to tell us that they received over 2,000 complaints about the new error message and had an over 80% drop in traffic and asked us to quickly take the new pages down and replace them with the old ones – and to plan in time to work on a cross-browser solution.

.

Looking ahead

IE6 is sadly the only browser that will stay with us long after IE9 or maybe even IE10 has been released. Many companies cannot afford the time and money for purchasing new software licenses or changing operating systems because a lot is depending on their current set-up.

IE6 is a problem for many web developers, myself included, and many of us are spending hours, even days, making a website work properly across all browsers. What you need to think about is: who is your target audience, and what computer capabilities do they have? And are you willing to take the plunge and not support IE6 and lose X% in visits and potential custom?

How is your industry affected? Are you still supporting IE6?

.

Especially for upcoming design studios or companies / agencies who are lacking in a certain area (such as developers or Flash animators) it makes sense looking to outsource work to keep employment costs low and not having to worry about whether or not there will be enough work to keep someone (or a whole team) employed.

Read after the fold what to look out for…

Before you make the jump into outsourcing client work, make sure you think about the following:
.

Confidentiality

Since you are dealing with an external source to work on a project that you managed to acquire maybe through a long process of sales and pitching or a project for a product that you created – it is important that the resources you hire are happy to sign a confidentiality agreement prior to commencing any work, and that everything they work on goes to you first. Between them and the client you are the account handler and the buffer, even if that means a bit more leg-work than with your regular employees.

.

Quality of work

When outsourcing project work you need to make sure that the quality both you as well as the client would expect is to a very high standard. Having a team on location in your office is always a good thing to see what is being worked on and if the project progresses as it should.

I remember a project where we commissioned a Flash animator to work on a flash-based mini-site for a T-shirt brand based on the core ideas behind the brand and the visuals we prepared for both online and off-line advertising. This animator was hired through the MD and was a friend of the family. Half-way down the project we sat down to see how the mini-site was coming along, and we were appalled by the blandness of the animation, the crude timelines and overall feel. “It’ll look better soon, I’ve got someone else working on the artwork, I am just preparing all the animation steps”. We hired someone else.

If you are looking for a resource then make sure that the person you are hiring:

• Has a good portfolio and / or sample work at the day of the interview in a style similar to the project you are working on, or can adapt to the style you are after
• Is being recommended by someone in your industry or you have had a previous experience working with
• Or has done work on similar projects
• Can do the work that he / she promised. Sometimes the resource you are hiring may not be fully fluid in a subject (such as ActionScript 3.0) and may be asking for help from a friend. That is of course fine, but make sure the resource understands that this may not impede a project or its timelines, and that any resource help requests will not be paid by you
• Is communicative and happy to give you updates on the project and can discuss problems (and solutions) with you and the team when or ideally before they arise.

.

Communication

Communication is a key in our industry. It is very important that you know how a project progresses, so that you can update not only your own team and superiors, but also your clients. Especially with external resources, a constant flow of communication needs to be put (and kept) in place. Especially when it comes down to sudden changes or amends to the project these will need to be communicated properly and as they arise with everyone. This may sound like usual common practice, but there are many horror-stories about projects being delayed due to lack of (or mis-)communication.

Remember to send out updates to the teams working on the project so that everyone knows how the project progresses and / or what to look out for and what needs to be worked on. It is very important that everyone talks to each other, which may be an issue for some in your team, as the outsourced resources are not in the office and as such easily forgotten / overlooked.

.

Deadlines

This is one thing you need to be aware of – deadlines may slip!
Due to the fact that some agencies or studios you outsource to may either already have work on the go or may only put limited resources into a project it could be that your work is being pushed back or given less attention than they (and especially you) would prefer.

I commissioned a studio to work on an administration backend that would tie in with a 3rd party application. About 2 months before the go-live date we informed the studio that we would need to begin styling and user-testing within the next week or two, just to receive the response “oh, we haven’t done much yet, we haven’t even looked at the integration yet.”

When it comes down to deadlines and projects that you know cannot slip much it is always worth to clearly define certain stages of outsourced development work. In an ideal world, you would want a weekly update, with a formal meeting / demonstration after every quarter of the project (if the project runs for 4 months you would want an update every end of the month). Towards the end of the 3rd quarter of the project the team you outsourced the work to would need to have everything pretty much ready for testing, integration and feedback to ensure nothing has been missed, call to actions are clear and the integration outputs the correct data.

.

Control

Keeping track of a project can be a bit daunting at first and it will take some time to get used to and to not overwork either anyone in your team or yourself. But keeping track of external as well as internal resources can become a balance act unless you do it very methodically:

1. When hiring external resources, ensure that the resources can do the work both from a skill-level but also from a time-level
2. Paperwork: make sure that a contract as well as a confidentiality agreement is signed from both parties before commencing any work
3. Make sure your team is aware of the external resources and what their role is
4. The external resources need to get to know the people in your team they will be spending the most time with and would need to be able to communicate on a friendly and professional level at all times
5. Updates: these should be giving and communicated in regular intervals both in writing as well as in form of meetings and demonstrations to ensure that the project is on schedule and to amend any problems that might have arisen at this stage
6. Time-keeping and project management: This one goes hand-in-hand with ‘5. Updates’ – your team as well as the external resources need to make sure that certain stages of any project are finished on time and on budget and that testing and signoff is done well in advance of presenting the project to the client. Remember that the client may also have feedback, so plan in time for that as well.

.

Conclusion

Getting a project online successfully with the help of external resources is not difficult as long as you have clear guidelines throughout the project and keep your team, your resources and your clients informed about what is going on and what will happen. Always remember that an outsourced project may take a bit more time than an internally kept project, and you need to make sure that you have plenty of time allocated for any eventuality. Who knows, maybe one day the external resource you just contracted may in fact end up in your team after all?

Following up on the previous article you may have some idea about if the mobile web is something for your company and your products. You have probably looked at your target audience by now, you know what users are going to look for on your website, how they find it, what information they read on your website that is related to the product, and you have a clear picture in your mind what content you want to promote for a mobile device user.

The question is now, how do you begin? What do you need to look out for, and what is a best-practise approach?

First off all, lets discuss the phone itself. More and more phones are coming out these days, but most of them share common functionality: colour-screen, wireless / wap capabilities, and input devices (such as stylus or keypad or even keyboard).

-

Screen sizes:

When looking at the mobile phone manufacturers’ websites we can read that the most common screen sizes are:
128×160
176×220
240×320
320×480
…with the latter belonging to Apple’s iPhone.

Looking at the graphic to the left (click to enlarge), you will notice already that there is a considerable difference between the sizes. Over the past year the World Wide Web Consortium (W3C) has been working on a Web Best Practices document for designing and developing mobile phones for the web. (I will be referring to this document a couple of times).

From that, we know that the recommended usable screen width is 120 pixels and the minimum amount of colours is 256.

(N.B. it is worth mentioning here that these are recommended sizes to reach the maximum number of mobile web users, obviously you can create a number of versions depending on the size of the screen, one for normal phones, one for iPhones for example, but I will get back to that later on)

-

Information Architecture for mobile phones

I try and pride myself in preparing the best practice Information Architecture for any of our clients’ websites, and it is even more important for mobile sites. Desktop computers have the advantage of a full keyboard, mouse, big screen, and different windows you can click through, close, or go back to. On a mobile phone with a screen resolution of 120 pixels there is a lot less to play with: you can display only a limited amount of content on there, with only a limited number of links, not to mention small imagery. Plus, unlike the desktop computer the internet connection is very, very slow. The more you click, the more you wait or (if you are not using wireless) pay. As such we will need to strip the website down as much as possible. We need to limit the amount of copy, the amount of links and of course imagery and find a healthy balance between content and navigation.

Looking at the graphic to the right, it makes sense to keep your content fairly short and to the point. The reason you are browsing from a mobile phone is because you are interested in some quick information, not a novel. Due to the nature of mobile phone and its browser it is also important to repeat the navigation at the bottom of the main content area. At this point you are used to the “scroll down” functionality of your phone, and you don’t want to change your grip on the phone just to go back up where you just came from. The navigation here should be containing links related to what you just read (if it was a product then a call to action to get in touch would be good) and related information (such as similar products in that field / area).

So now we have looked at what the sizes are and what good practises are in setting the content up. So how do we develop this?

-

Development for mobile phones – considerations

Compared to web development for desktop computers mobile web developers need to consider a couple of limitations to a mobile website:

• One column layouts only, try not to use floats
• Reduce and optimize your HTML and CSS markup, don’t overdose on <div>’s and <span>’s
• Limit the number of images (that includes background images and graphical headlines and tabs!)
• Try not to use Javascript or any dynamic effects used for mouse and keyboard use (such as hover effects or iframes)
• If you use images, make sure you use alt-tags

-

Development for mobile phones – XHTML

Next to HTML / CSS one of the most commonly used languages for mobile phones is XHTML-MP (eXtensible Hypertext Markup Language – Mobile Profile), a subset of XHTML Basic and HTML and is the predominant language for mobile phone development.

An example of XHTML-MP can be found in the graphic below (click to enlarge):

As you can see, it is fairly easy, isn’t it.

-

Development for mobile phones – Navigation

Because you are working with a very vertical browser you will need to rethink your website’s navigation and plan ahead for a vertical list navigation, ideally together with access keys (access keys are the number keys on the keypad of a mobile phone 1-9 and 0). See below for an example using list navigation and access keys (click to enlarge)

(NB: If you intend to link a telephone number within a page to automatically dial the number on the users phone just use this snippet:
<a href=”tel:+123456789”>+1 23456789</a>)

-

Development for mobile phones – Publishing the mobile web content

Okay, so you have created a very simple version of the website, using semantic markup language and have generated the content how you would like it to appear. It is time to set the website up.

It would be ideal to have a sub-domain or a folder for your domain such as m.websitename.co.uk or www.websitename.co.uk/mobile and get users to go there directly using their mobile device. Another option would be to let the website detect the user agent similar to what you would do to use special style sheets for IE5/6/7 for example, in this case a
<link rel=”stylesheet” type=”text/css” media=”handheld” href=”mobile.css” />
will work wonders.

-

Testing

So the mobile version of your website is done, and you have sorted all your styles out and are ready to go live. Time to begin testing.
I would strongly suggest following this testing guide to ensure that everything goes well:

1. Desktop testing: Both Opera and FireFox have the great option for small-screen view. Test both without scripts (such as Javascript) and without graphics. Test without mouse
2. Emulator testing: Use any (or ALL) of the following emulators:
   Nokia’s emulator
   OperaMini simulator
   Blackberry simulator
   Openwave simulator
   Ready.mobi site-checker
3. Device testing: Get hold of many different mobile phones and test your website. Best option would be to test the site with mobile phones using WiFi in your own network, and once you are satisfied with the outcome go and try phones that do not have WiFi-capabilities (meaning you have to pay for each minute or kb) and test parts of the site.
4. Usability testing: knowing that the website works on mobile phones does not mean that it is usable. Test each aspect of the site, does it make sense? Can you find your way around it? Does your colleague? Does your friend? Your spouse?

-

Closing notes

This was a pretty quick rundown on designing and developing for the mobile web. I hope at least some of it made sense to you. For the next steps I would suggest you have a browse around for handheld style sheets and how to implement various style sheets depending on your audience (say a version for desktop computers – with IE style sheets – and mobile devices, you can even work on an iPhone version or versions for different sizes!) and see how you are getting on in regards to implementation, publishing and testing. If you have any comments or any experiences you would like to share then please do, I would really appreciate it