There are plenty of things that people can say are good or bad with a particular browser and many get very emotional about it. I say rightly so, because without passion, we cannot drive an industry forwards. In order to keep the emotion out of this topic, I’d like to start this article off with some focus and make some practical assessments. We need to focus on what we’re trying to cover and sometimes the best thing to do is to express quite clearly what we’re not trying to cover.

In that case, I’ll identify two different use cases here:

1. Ordinary everyday users of a browser and their browsing experience;
2. Developers of web sites and their development experience in that browser.

Those are two incredibly different areas of focus and I think you’ll find that everybody and their dog have an opinion on the first one. The development contingent, perhaps the most passionate, has the most to say because it drastically affects their productivity and happiness in their day jobs. It’s this second use case I’m more interested in for the purposes of this article and I’ll be digging into what a browser needs to do to win me over as my primary development choice.

First a little history

I’ve been doing this web development thing basically since it started in the public eye back in 1995 when all we had was Mosaic, Netscape Navigator, a young Internet Explorer and “View Source” if we were lucky. I clearly remember Netscape being my favourite at the time all the way up to and including when IE3 came out.

It was only when IE4 arrived that my ears started to prick up, but even then, it was only just pulling level and web development wasn’t really difficult in those days since there wasn’t much you could actually do with a page and still keep it small enough to come down over a modem without growing a beard first.

IE5 came along, and with it my first personal exposure to CSS in its earliest forms, but I was hooked, and with the likes of Opera and Netscape still fighting for top spot, IE needed something special. Thus was born the browser that could not be killed. IE6, the champion of browsers in its day, with its only sin being that it was so damn good at the time; we still can’t get rid of it today. It was back then that IE6 was my primary development browser, a time when having the blue “e” icon on my desktop and watching it launch as my default browser didn’t make me wince in the slightest. Sadly, it has been downhill since then and one of the biggest contributors to that has been: Speed of innovation.

How we learn

Most of what web developers know about their craft doesn’t come from a classroom or a book. It comes from inspecting the online work of others – trying to decipher how they managed to achieve a particular effect or layout that defies logic.

The great pool of web developer knowledge is growing organically through inspection and creativity. Each developer standing on the shoulders of the next, building on what they’ve done, thereby homogeneously contributing back in to the greater pool of knowledge.

Why? Because they can’t help it – the source is laid bare for all to see and inspect and that is the very reason this is one of the fastest growing bodies of knowledge and communities on the planet. But this kind of organic learning can only be achieved through the existence of proper tools. Gone are the days when we used to hit “View Source” on the page and that was enough to grok everything being done.

Tools like Firebug kicked a massive hole through the cast iron door behind which much of this magic was locked away and in the last five years or so, each of the browsers have been getting better and better at providing those kinds of visualizations.

This is when I began to wonder if it was even possible for IE to capture the audience it had in its former glory years, and what kinds of things it would need to overcome in order to do so.

Next a little research

I couldn’t exactly start this opinion piece without at least doing some due diligence. That includes canvassing as much opinion as I could in a short space of time (which means it’s not very scientific), as well as trying things out for myself on something more than just the proverbial “Hello World” and then spouting my findings.

So first I sent this little teaser out on Twitter:

The results and responses I received were largely what I expected from quite a varied and open-minded group of web developers, mostly confirming my own thoughts, and in some cases expanding on things to which I hadn’t really given much thought. As a result, I dug deeper still, searching for various opinions and articles with comments both good and bad about every version of IE, before putting it to the test myself by using it as my primary development browser, forsaking all others in order to see what kind of trouble I could get myself into, or out of as it may be.

The experiment

To understand the friction points a little more, let’s take a look at a day in the life of a web developer. Let’s assume she’s been given the fairly common task of taking a Photoshop composite, and putting that on the face of a web application that is somewhere along the way to completion. For this, they’re going to be touching on a fair bit of technology in the browser space, namely:

1. HTML of course for the structure of mark-up and content;
2. CSS for layout and styling;
3. JavaScript for the interactive bits;
4. And a little bit of profiling thrown in for the hell of it.

For those four things I would expect the browser to provide the tools necessary to inspect, diagnose, visualise, troubleshoot and debug without breaking a sweat.

So I decided to try this experiment on a small project one of my clients asked me to do. They wanted to create a blog on the Blogger service, and the blog template had to have the same look and feel as their website of which I wasn’t involved with the original design. Oh and another thing, they weren’t able to provide me with access to the original CSS or HTML files – don’t ask.

No problem right? All I had to do was reverse engineer their existing HTML, CSS and JavaScript implementation and provide a blog that integrated seamlessly with their website on a sub-domain. This, my friends, is what the browser tools of today were born to solve!

So I started ploughing away using IE9 and the developer tools it comes with (F12) to see how it held up under the challenge, and how well it stayed out of my way. I started by inspecting their website HTML and CSS, and did the same thing on the default Blogger templates and widgets. Trying to make sense of it all is not an easy feat and the browser inspector needs to be at the top of its game if it’s going to be any good to you.

The verdict

It turned out surprisingly well actually, and a lot better than I expected to be honest. For this task, I would have estimated about half a day to figure things out and get something pretty close with my normal set of tools, and this exercise took me a little over a day, which is not bad going considering this was my first outing with this particular release of their developer tools.

The Good

Most of the things I really liked about IE9 developer tools, I already like about other browser inspectors, so not much of a gain there. Very few things actually stood out for me above the rest. One thing that did though in this instance was the JavaScript debugging, which was a very pleasant experience.

I’m not sure if it’s because I spend an inordinate amount of time inside Visual Studio, which is quite possible, but the experience just felt natural to me, whereas with other browsers I remember having to scratch around to figure out how it all worked, using breakpoints and stepping through code etc. This particular area in IE just works! If you’re coming from a VS background, you’ll probably find the same thing.

The Bad

The profiler and network tools don’t do much other than give you a stack of numbers in a grid – oh and some, I suppose you could call them “bar graphs”, that look like they’re trying to send us on a one-way ticket back to 1998.

The network and profiling visualizers in other browsers today give you such a great picture, and problematic areas in your site jump out at you instantly. It wasn’t the worst experience ever, and I could live with it if I had to, but having seen much better implementations than this, I can’t help but think that they just didn’t try very hard.

Programmers are typically bad at design, and boy does that show up here in particular. It doesn’t look polished, and unfortunately, that has a significant impact on perception of the product, even if it does do what it’s supposed to do.

And the Ugly

There are some pretty horrendous usability issues I bumped into time and time again and while they made life very difficult for me in my task, if they were fixed, I think it could actually be a very good challenger for the crown of best browser debugging and inspection tools. Things like having to click a billion tiny plus symbols and check boxes on tree views gets old very quickly. There just has to be a better way of representing these things today than using the same paradigms brought to us in Windows ’95.

I don’t think I should go into every painstaking detail here, but let’s just say that the IE team need to take a good, hard look at, and hopefully a leaf out of the book of the other main browsers out there in terms of usability. But I can’t leave it there without at least giving one example that genuinely had me swearing at my screen a couple of times. I think I actually developed a slight tic because of it:

So if there was one thing in particular I could change today, it would have to be the element selection mechanism:

You see that menu? And that corresponding “white arrow” icon on the toolbar? There’s your first mistake. Its very existence is the problem and has to be one of the dumbest design decisions I’ve seen in a while. It is making me click something to tell the tool to go into selection mode. For the life of me I cannot fathom why someone thought that would be a good idea?

But wait, they managed to make it even less usable by making me click that same button again if I wanted to select something different on the page….and you guessed it, another click if I wanted to select a third element.. Getting bored yet? I know I was…

The way that Chrome (WebKit) does it for example is to correctly assume, selection is the default activity you want to perform, and otherwise you probably wouldn’t have bothered to open the tool in the first place. It then dynamically highlights a box selection on the page as you hover over elements in the inspector.

You can simply run your mouse down the inspector (no clicks) whilst looking at the page providing a nifty way of visualizing how the page is held together. Alternatively you can right-click on anything in the page itself and choose to “Inspect Element” which jumps to the exact spot in the inspector.

Accomplishing that same task in IE today is dismally painful and tedious. The number of times I had to context switch every time I wanted to select an element just gave me a headache.

Fix that, and you’ve already won a thousand victories in a day in the life of any web developer!

Good will, and a time machine would help

If the IE team had a time machine, I suspect one of the first things they would change is how tightly coupled IE is to the Windows OS. I can’t imagine just how much pain that has caused them, and continues to do to this day. It affects everything in development, distribution and especially their time to market. But they’ve made that bed now, and there are undoubtedly some very smart people working there, so figure it out, and it looks like they might have made a start with IE10 already starting to show up after IE9 had just launched.

Oh and please – enough with the reboot already! It’s 2011 in case you hadn’t noticed…

Again, it comes down to a point of perception. When developers see how much friction is involved in the installation process, it doesn’t inspire them with any confidence and certainly doesn’t get them chomping at the bit to try out the development experience. Perhaps wrongly so, but perception has led people to ignore even the most adept marketing pitches.

Oh, and about that marketing

This comes back to the age old argument about supporting web standards. Try not to bend the world view with half truths about what IE now supports, spouting so called proof of feature implementation supremacy, only to have independent assessments tear the arguments limb from limb.

You might be able to pull the wool over the eyes of the average user, but developers can see straight through the marketing speak. Web developers need to cater to deficiencies in the product. Fact! If the vendor is actively masking those with semantics and choice of language, it really just comes across as dishonest and leaves a bad taste in the mouth. There’s nothing that developers despise more than a vendor who doesn’t tell it like it is.

Plugins, developers love plugins, and web standards

Anything the browser can’t help with in development, presumably a plugin can handle in theory. In order for that theory to become practice, the plugin story needs to be easy – really easy! The awesome Firebug plugin is a prime example of what community efforts can achieve. The size of the plugin ecosystem is directly proportional to how easy they are to create and distribute. If you want developers to use your browser, you need to get this one right.

As per the marketing comments earlier, web standards are really high up on developers’ list for two reasons:

1. Developers want to take advantage of new features, and the sooner browsers support them, the sooner they can be introduced;
2. Developers want, more than anything else, to write their code once, and once only! The only way that is ever going to happen is if the browsers can agree, and the only way that seems possible is if they implement the web standards they profess to agree with.

I understand there are a bunch of features that some browsers jump the gun on. Web sockets spring to mind here because no matter how cool something is, if it compromises security, people are going to lose some faith. And the last thing IE needs at this stage is a loss of faith.

But what about supporting simple things like `history.pushState()` for example? IE is the only major browser that doesn’t and it would make our lives some much easier if it just took the plunge and joined the rest of the crew. It will eventually have to anyway, so why not sooner on these kinds of things?

Version hell

There are more than 4 official versions of IE widespread in the wild today, and I’m not sure there’s anything that can be done about this, but it came up so often on the feedback I got, I had to make some mention of it. I think this is a grave hole that was dug many years ago, ironically due to the unprecedented foothold IE6 managed to get in the enterprise and Windows XP markets at large. A victim of their own success, it is now the number one snide remark thrown in Microsoft’s direction, that we still have to design websites with IE6 in mind today.

Their incessant need to be backwards compatible is working beautifully for them in the user space, but is biting them badly in the developer space, but it’s reached a point where it’s even starting to leak through to users now, and it’s a shame that this is the first time Microsoft seem to have taken any notice.

Most developers are just starting to express pure apathy since the anger has died down and are giving up completely on supporting IE6 these days, and even the likes of Google are officially not supporting IE7 anymore. It’s hard to tell if Microsoft have any problem with this – at least not on the face of it. It is this very complacency that is so offensive to developers who care down to their very core about the experience they are giving their users.

Keeping multiple versions out in the wild has its pitfalls on having to constantly develop for the lowest common denominator and jump through all sorts of hoops to still provide a rich experience to those users on newer software. But it can also go horribly wrong in the opposite extreme. Google force new versions of Chrome down your throat at such a rate that it’s impossible to keep up.

They are also demonstrating some catastrophic stupidity by releasing some very unstable versions, especially in the last few releases. I’m not on the developer beta track for that very reason, but even I have been negatively impacted by some pretty horrendous regressions, some of which took over 2 months to disappear, and in Google release cycles, that’s like – a dog year – or something.

What’s in a test?

A lot of people seem to mention side-by-side installation of versions, but to me that’s slightly different to primary development in a browser. You have to test every single major browser out there before launch anyway and it’s just not economical anymore to do so yourself. I’m also willing to bet body parts that you won’t be able to get 12 versions of Google Chrome installed side-by-side either, so I don’t understand why people still whinge about this point.

I know it’s a fine line, but let’s face it, a developer would usually develop in a browser they feel will get them 95% of the way there, and then they’ll start making tweaks while testing in other browsers. Nobody has the time, machines, or willpower to constantly be testing in all browsers. Well, maybe some do, but I honestly feel sorry for those folks.

I usually outsource this function to one of many online services that do this now and get far better results. It’s time to get with the programme and move on…

In conclusion

The browser needs to get out of the way and be friction free if a developer is going to voluntarily choose it. I think we can all agree that IE8 and below don’t stand a hope in hell of being a developer’s primary browser.

If IE vNext can start addressing those particular problem areas above in the eyes of developers, which means - “for real” and not just in the marketing jibber-jabber, then I think it could start striving to wear the crown that IE6 once wore in the 1990′s – it was untouchable and de facto, the best thing since sliced bread – but that bread is stale now and they need to bake some more – with bells on!

What other boxes do you think IE would need to tick before you would be able to use it to drive out development on your next web site project? Please leave a comment below and let’s get these out in the open in a constructive way so that we can help shape the development experience in future. Until then, I’ll be using Chrome for my friction-free-fix :)

Until next time…
RobertTheGrey