Click here to see all articles in this series.
Welcome to the fourth 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.
In the previous installment we considered the option of selecting two or more browsers as the corporate standard, giving flexibility when internal or external sites or web-based applications prove difficult to support in a single browser.
Just like most organizations now support more than one phone handset (a difficult option in 1994), they should consider supporting more than one browser.
Today we will look two more practices deserving serious consideration in setting web browser standards in your organization.
2. Stick to officially-supported browsers
Many IT professionals might be surprised to discover that the browsers in use in their organizations are no longer actively maintained. Browser exploits go unpatched often compromising security in these cases. Companies should make it a policy to not allow unsupported browsers to be part of their standard deployments. Yet in many enterprises the opposite is the case. I've seen officially-supported releases specifically forbidden by IT departments because they are untested and instead users rely on older, unsupported releases. This is a dangerous policy that creates serious security risks.
There are a few reasons why organizations have allowed this untenable situation to continue. First is that they did not budget appropriate resources to the predictable browser schedules. Instead, they pretend these schedules do not exist and only try to react after a new version of a browser is released. Resources need to be allocated to begin testing beta versions of browsers for major issues and allocate resources to correct the problem. If you took the first recommendation, you may be able to buy extra time by instructing users to switch to an alternate browser until the sites and applications are adapted to the new browser release.
Budget for the inevitable cost of browser updates in your organization rather than trying to respond after they are released. Keep tabs on new browser releases so that you can plan for them in advance. Then make sure you have dedicated ongoing resources to ensuring the organization only use officially supported browsers. While it may seem you can't possibly keep track of all the browser updates, in reality vendors are very transparent. Most give clear signals of when to expect a major new version, and generally provide plenty of lead time to test beta candidates before the official release.
As of now, Mozilla officially supports Firefox 3.6.28, 10.0.3 and 11. So if you have users on Firefox 4, 5, 6, 7, 8 or 9 they are at risk as these releases are not actively maintained. Microsoft supports Internet Explorer 7, 8 and 9. They also have some provisional support for Internet Explorer 6 even though they have begged their customers to abandon this version. Apple takes a decidedly tighter approach, only supporting Safari 5.1.4 for the Mac and 5.1.5 for Windows. And Google is most aggressive, quietly pushing updates to Chrome often unbeknownst to the end user. Right now they support 18.0.1025. Get used to this - Firefox is heading that way as well.
As a browser-based software vendor, however, I am routinely asked to provide support for browsers that aren't even officially supported by their creator. While we strive for remaining browser neutral in our software, there are inevitable inconsistencies in browsers and versions that make it impossible to eliminate every possible problem created by inconsistencies in browsers.
It may be more work to update browsers frequently, but these updates should be prioritized to maintain security and support innovation. Make plans around the browser vendors' release schedules in advance and take advantage of beta programs to begin testing early. Proactively and aggressively encourage your users to stay on supported browser releases.
3. Browser support as a goal, not a requirement
One reason enterprises are loathe to support even two browsers is that they attempt to ensure that every application and site operate correctly on every browser they deploy. This can lead to impossible situations, complicated testing, and lengthy deployments as the organization tries to ensure all tools operate consistently across all browsers on all platforms they deploy.
While browser-based product vendors like me understand this as part of the cost of doing business, it seems that often organizations relying on browser-based tools set a far more difficult bar for application/browser compatibility than is necessary. Recently I found that an expense report utility I use does not seem to function correctly on Safari. Rather than spend a lot of my time (or my company's time) trying to figure out what the issue was, I instead use Firefox. Someday there may be a reason to worry about why it isn't working in Safari, but for now I have an acceptable workaround. Make this easier for end users by putting a browser-detect page in front of all corporate applications and updating it when testing new browser releases to inform users of their alternatives. Make updating this browser detection page a part of your browser test plan.
Are users annoyed when their browser of choice doesn't work with a tool? Perhaps. But denying any choice at all leaves them no option but to make a support request and wait.
That said, companies should plan to update their applications eventually whenever possible to handle all supported browsers. But making this a goal rather than a requirement allows practical decisions to be made. Is the latest update to Internet Explorer going to require a massive effort to support on your legacy tools? Look for supported alternatives from the other browser manufacturers for an easier temporary or permanent workaround. Make sure users are informed of this when they attempt to access the application. Don't assume that if you communicate these things through handbooks, emails, or posts to the corporate site you've done your job. Instead, try to detect problematic browsers on your site or application and provide users with the information they need to access the site or tool.
