Click here to see all articles in this series.
Welcome to the final 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 I recommended that organizations plan to stay with officially supported browser releases, and remain flexible so that in cases where a browser upgrade causes problems with certain sites or applications backup solutions be acceptable as an interim solution.
This installment gives you two more tips that can help deal with the inevitable browser update cycles and some final thoughts on the subject.
4. Be practical -- don't try to fight browser update cycles
At some point you may find that despite having browser options available you run into the need to go back to your vendor or development team with requests to fix compatibility problems with new browser releases. When doing so try to take a practical approach. Work with your developers and/or vendors to come up with an acceptable short-term solution to deal with the problem at hand. It often is counterproductive to go to enormous effort to get everything fully functional in all possible browsers when, by the time you have fully tested all the variations, new versions are being released and those browsers you just certified are no longer officially supported.
Stay focused on providing users with a practical path to access the tools they need. Find a solution, get it up and running, then decide if further effort is merited to support and certify against additional solutions. Browser development cycles have become more rapid. Don't bog yourself down in policies that ignore this reality.
5. Be strategic in your browser selection strategy
Deploying browser-based sites and applications should be done with the expectation that part of that cost is incurred over the life of the application in testing, support and deployment resulting from browser updates. Make this an ongoing part of your IT plan. I'm still surprised at the number of organizations who act as if browser releases are sprung on them without warning. In reality, most every company provides early access to browser releases and clear communication of upcoming releases.
When deciding which browsers to support IT organizations have often traditionally ignored the longer-term, strategic implications of their decisions. Notice a lot of iPhones and iPads in your users' hands? Maybe you should consider Safari as an option on the desktop, since there is a much higher likelihood that sites supporting desktop Safari will also support Safari on Apple's mobile devices. Considering that the underlying engine behind Safari (Webkit) is also the underlying engine behind Google Chrome, the Amazon Kindle browser, Android, and the Blackberry Tablet OS and webOS -- ensuring support today for Safari or Chrome on the desktop may pay additional dividends if you have mobile support planned for the future. Even Microsoft in their Windows 7 Phone browser has made adjustments to Internet Explorer to enhance their compatibility with Webkit given its dominance in the mobile space.
Today's web has more devices to support, more dangers to avoid, and new formal and de facto standards to address. Have you adopted a strategy for browser deployment that accepts these realities? Or are you pretending it is still 1994?
