Click here to see all articles in this series.
Welcome to the third installment in a multi-part series where I look at how IT departments may inadvertently cause more problems than they avoid in their approaches to deploying web browsers in their organization.
Today we look at some positive responses organizations should consider when handling web browser standards in their organization.
I understand the plight of IT departments. They can't upgrade the official company-supported browser to support new tools and technologies without having to extensively test and invest what could be substantial resources into updating old tools to work in the new browsers. While pressuring your software vendors to support years-old browsers may seem like a way to ease your support headaches, in reality this is really a short term gain with long term costs. Writing code to support years-old versions of every browser takes a lot of effort, and often introduces much more code complexity. Each version of each browser is a real cost to code against, test against and support. These costs will eventually be passed on to you even if you manage to hide this by pressuring browser developers or your web site developers and tool vendors. Higher licensing costs, slower innovation, delayed release schedules, increased complexity, reduced stability, longer testing cycles, reduced functionality and increased downtime are all potential liabilities incurred by each additional browser and version a vendor must support. Most of the browser developers have already acknowledged this and adopted update strategies that rapidly drop support for non-current browser versions.
I've been thinking about this quite a bit lately and came up with a few suggestions that I think should be seriously considered by every IT organization. Not all IT departments can or should adopt these wholesale. But thinking through these suggestions may help alleviate some of the challenges faced by IT organizations managing web-based technologies.
Today we will look at why you shouldn't try to regress to 1994 when there was only one browser available to most users.
1. Do not rely on a single browser platform for your end users
I'm often surprised that many IT departments force their entire organization to rely on a single version of a single browser. Personally I keep several browsers at the ready in case I run across problems working with a web site or application. The Macintosh computer I'm using to type this has installed on it Internet Explorer 9 (through Parallels virtualization software running Windows 7), Google Chrome 18.0.1025, Firefox 3.6.28, Firefox 11, and Safari 5.1.4.
Why is it that many enterprises sanction only a single browser and version as a corporate standard? Such a draconian mandate has the potential to create more support problems than it solves. Users who run across web sites and applications that don't operate properly with the single sanctioned browser are forced to contact their IT department for assistance, not use the site or application, or attempt to access the tool outside of the company computers (most likely from their home).
Many users in their home environment are perfectly able to install and use multiple browsers. I have often seen "novice" computer users react to problems using a web site or application by switching to another browser. When they upgrade to the latest version of Internet Explorer only to discover problems with some site, they immediately will fire up Firefox to see if they can get around the problem. In a corporate setting, it may actually save in IT costs to give users options to troubleshoot and solve their own browser compatibility issues through trial and error. This buys time for the browser developers, site developers and tool vendors to find solutions to any issues on a particular platform.
Why not make two, three or all of the major browsers for your platform a standard part of the deployment? If the latest update to Internet Explorer breaks some vital application, there's a good chance it will continue to run in Firefox, Safari or Chrome. Think of it as a redundancy mechanism that minimizes the chance that any one browser update will bring everything to a halt.
Yes, IT organizations will have to expend some additional resources keeping more browsers patched. But a single point of failure for a fundamentally critical tool like a browser seems shortsighted and needlessly restrictive. And the extra effort may ultimately save time and resources in that users have at least one other option than to call the IT department when a browser update occurs.
