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?

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.

In the final installment we will look at two more recommendations for your corporate web browser strategy.

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.

Yesterday I talked about how the browser developers manage updates and supports for their browsers, and provided examples of a few ill-advised responses.

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.

Click here to see all articles in this series.

Welcome to the second 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 part 1 I talked a little bit about why I have an interest in this topic.

Today we will look at the release cycles and support provided by the major browser vendors. We then look at two very tempting but ultimately destructive strategies many organizations have tried to attempt to cope with the challenges of a web-based infrastructure.

Browsers with rapid release calendars: Chrome and Firefox

Unfortunately, many of today's browsers make it difficult to successfully employ a locked-down approach to technology deployments. Both Google Chrome and Mozilla Firefox have adopted rapid release cycle strategies whereby major new versions are introduced every 6 to 8 weeks. When a new release is introduced, a very short period of overlap exists before the vendor drops support for previous versions. Now web sites and web-based tools and applications must adapt to this reality if they are to use supported versions of Firefox or Chrome.
Mozilla and Google aren't doing this to destabilize your delicate software balance. They are instead trying to focus effort around a single browser release. When Firefox 12 debuts (scheduled April 24), you will have a few weeks to enjoy continued support on Firefox 11, during which time you should have plans well underway to support the new version. And you should make every effort to move on, if for no other reason than in the interest of security. Google's Chrome quietly updates their browser without user intervention. And note that this is categorized as a security feature. If Google Chrome is a used to access your web-based environments you better know when those updates are scheduled to occur and proactively test your applications. Firefox is moving in a similar direction.

While this makes it necessary to update more often, developers building around Firefox and Chrome can focus the vast majority of their effort around a single version of each for the Macintosh, Windows and Linux platforms.

IT departments should have the release schedule on their calendars and proactively plan to support the new releases as soon as possible. The new releases will have security updates and active support from the browser's developer.

Internet Explorer: Versions That Never Die

Microsoft often appears reluctant to cut off support for aging software, due in large part to the size of the install base and the fear of losing customers with aging hardware platforms. 

This is reflected in Internet Explorer. Internet Explorer 6 will be finally interred in April, 2014. This is for a product they are aggressively recommending customers discontinue using, a product that had been eulogized in a funeral ceremony in 2010. Allowing aging versions to continue well beyond their prime, Microsoft has created the browser that wouldn't die.

Even when IE6 is finally gone we still have to contend with Internet Explorer 7, 8 and 9, and soon 10. We can only hope that Microsoft musters up some courage to discontinue their aging releases or they'll all be around into the next decade.

Safari: Something old and something new

Apple mixes a bit of the old with the new in their approach to Safari. They have longer release cycles often tied to major OS/X operating system updates, and tend to aggressively discontinue support for all previous releases. So at any given time developers using web-based technologies can largely focus on a single version of Safari for the Mac, for Windows, and for iOS.

The B-Movie Scientist Policy

So your organization will no doubt have to decide how to adapt to life once your supported browser is dead and buried. You could join many of Microsoft's large customers and use threats, bribes, begging, and tears to cajol them into keeping whatever version you use on official life support well past their prime. Of course, companies like Apple and Microsoft (and open source communities in the Linux world) are unlikely to respond unless you have an enormous IT budget. Even if you do manage to succeed, your victory will only be short-term. Like an ill-fated b-movie scientist, your monstrous creations may be doomed to roam the earth indefinitely.

I read an interesting case study of a startup who estimated the cost of providing Internet Explorer support for their tool at $100K. They chose not to support the world's #1 browser and claim it as a competitive advantage! Writing web applications and tools that can cope with the idiosyncrasies of years of browser releases is a challenge. Building code to deal with all the subtle variances means increased complexity. Hiring staff members who understand all these variations can be difficult. Even keeping around working versions of these dinosaurs is a challenge. Ultimately, the time you may have saved by avoiding a browser upgrade is probably lost many times over in long-run expenses.

The "Monkey's Paw" Policy

I am even more stunned by the approach taken by organizations who don't have the clout to officially keep their chosen browser alive indefinitely. Even after the vendor pulls the plug on the software, many organizations refuse to let go. They continue to support software that the software's creator has given up on. They continue to allow their users to rely on unsupported, unpatched browsers. While this may be sustainable in the short-term, it is a dangerous strategy in the long term. Like a wish on a monkey's paw, unintended consequences may be serious.

As I vendor, I have seen this phenomenon first-hand. Customers will ask for assurances that our software will support "dead" releases, even though such assurances are in reality impossible to guarantee when the browser itself is unsupported.

When a customer tries taking this approach I politely decline. Ultimately most customers realize that supporting dead browsers is an unsustainable strategy only to be used for short-term, emergency situations. Putting systems and users at risk by forcing them to use browsers that do not receive security updates should not be a standard operating procedure. 

Well before the browser developer ceases support for the version of a browser you use, you should already be planning your upgrade.

So that's a quick summary of how the browser vendors handle the lifecycle of their browsers and a few suboptimal responses.

The third installment in this series explores positive steps to a proactive web browser strategy.

Click here to see all articles in this series.

Welcome to the first installment in a multi-part series where I look at how well-intentioned IT departments may be causing more problems than they prevent in their approach to deploying web browsers in their organization.

This installment provides some of the context that lead me to explore this topic.

The Web Browser: Mission Critical Infrastructure
RSI Content Solutions fields two product lines reliant on the web browser as client software: RSuite CMS and DocZone. Managing products that operate in the browser presents challenges when trying to balance functionality against the need to support a wide range of browsers and their versions. Browser developers have been under increasing pressure to provide rapid updates to remain competitive and deal with ongoing security concerns. Users have become more reliant on a range of browser-based tools and applications. Almost every category of traditional desktop applications now have browser-based alternatives available. It can become a real challenge to find that magical browser release that supports the range of platforms and technologies in use today.

I've worked as a vendor in the browser-based application space for more than five years. In that time, I have encountered a range of responses from IT departments dealing with browser deployments. Some exert little or no control, often providing guidance but ultimately letting the users decide what browser to employ and when to upgrade it. Some IT departments have locked things down so tight they only give their users access to a single approved browser. While this may be sufficient for a fairly narrow use case over some finite period of time, the inflexibility is often stifling their ability to take advantage of the latest tools and technologies.

It's ironic that the mission critical role of the web browser has lead to defensive policies in many organizations in seeming ignorance of the rich variety of available tools. In the interest of ensuring a "perfect" technology deployment, it is tempting to lock the organization to a functional set of tools. Just don't blink lest your heavenly solution suddenly show its shortcomings and leaves you mired down.

Over the next several days I will be inviting you to consider your approach to supporting the web browser in your organization. In the next installment, we will look at the various approaches browser developers have adopted regarding updates and support. I'll also tell you about two strategies that have seduced many an IT department astray only to find they're worse off than before. 

Installment number two discusses how browsers are updated today and why acting like a B-movie scientest or wishing on a monkey's paw is not the right response.

I've been working in content management for more than ten years, and thinking back over that time I realized that the dream of a true, standards-based, central repository for all of an organization's assets I naïvely espoused in the late 90s still hasn't become a reality except in the most narrow of applications. When I used to write and teach XML classes I was sure that open markup standards were going to revolutionize the way we created and managed assets. Around 2003 I started to become a bit disillusioned with my vision for content utopia. By 2008 I had all but thrown in the towel. Despite herculean efforts content kept worming its way into proprietary, tactical-level production systems and often was never seen nor heard from again, a victim of legacy of "fire and forget" publishing approaches common prior to the rise of the Internet.

Fortunately, just as I had resigned myself to living in a world of content silos, new strategic ways of managing content started to emerge that rekindled my ideals. The idea is more modest than my grandiose vision of pure standards I once embraced, but offers a new, more practical approach that can survive in the real world.

Rather than insist that every asset be centralized in a consistent, preferably open, format practicality may dictate that we instead work to build a centralized asset repository that shares common representations for all assets. The actual bits and bytes making up the asset (Word documents, InDesign files, photos, videos, etc.) can still be developed and stored in traditional systems where applicable, but a new system takes on the responsibility of cataloging relevant features and details about the asset in a centralized repository. So instead of insisting that every asset be physically managed in a central repository, we instead insist on the much more modest - and realistic - demand that all assets make relevant, common data and metadata available in a consistent format through a centralized system. This distinction means that rather than try to replace the tactical systems we use to create, manage or distribute content we instead develop a parallel, complementary content management strategy that reflects data in these systems and presents a common, consistent view of the asset regardless of type. 

So an image file may exist as a TIFF or PSD formatted file in a production system or on some hard drive somewhere, but the centralized repository maintains a record for this image with all of its relevant metadata and a standard image format readily accessible to any system (i.e. PNG, JPG in thumbnail and applicable preview formats). For a lot of applications, centralized lighter-weight representations of content is enough to create new products without returning to . For example, if I want to rapidly re-use images or stories on a new microsite, I don't have to resort to tracking down all of the content in its silos, but instead rely on these common representations to collect the assets together and send them into my Web CMS for the new microsite. Formats, conversions, and so forth can either be provided to the central system through traditional manual conversion or, preferably, through automated mechanisms built in to existing content workflows.

This sort of approach was attempted using search technologies at one time, but lacked an important ability to offer the depth of content management required to not just find the asset but also to be able to use and transform it. It gave us the ability to view the content but not any tools to do anything once we saw it. Search remains important, but a real central repository needs to actually have usable representations of content that can be managed, transformed and distributed as assets on their own. This requires a full content management system.

So my new vision of a centralized asset repository is not the end-all be-all "do everything" system that becomes impossible to design and build, it's a "do-some-things" central system that maintains some consistent, common format that can be readily transformed and transmitted and becomes an organization's strategic content reserve. It can answer questions like "what assets do we have about Egypt?" quickly, and serve as a baseline for those assets so that after finding them they can be used in our various tactical systems.

To build such a thing, consistent representations are needed. When looking for data standards we of course start with XML. When only a binary will do, ensuring that pointers are accurately maintained to the original assets and appropriate renditions of the binaries are created for things like the user interface of the central repository is an obviously useful model. Even if re-work is required the assets are already under active management. 

The RSuite Content Management System happens to be a great foundation for building shared, managed centralize repositories of content. The system is flexible, built on an XML standard database with a metadata model that can not only leverage existing metadata but also be extended in arbitrary ways to adapt to evolving requirements. It is built on open standards and is a good corporate citizen, ready to interoperate with existing systems. The native XML database and pointer management features ensure that consistent representations are available. This approach creates a solid foundation for a strategic, centralized asset repository. 

Part of my role as Product Manager for Really Strategies will be to focus on the ways that our existing clients have adopted XML-based content management. I'll be reporting in with our client success stories at building these content repositories here on the blog. 

Does your organization have a vision for managing content strategically? It’d be great hearing how others are working to address this challenge.