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.

RSuite CMS, a content management system for publishers, has partnered with MarkLogic for 8 years to provide world-class content management to publishing and media companies around the globe. RSuite CMS is a gold sponsor and exhibitor at MarkLogic World 2012, the premier event for organizations looking to collaborate with and learn from leading industry experts, partners, customers, and MarkLogic employees on how you can turn “big data” into “big ideas.”

“MarkLogic World is one of the most important educational events for organizations who need to understand how content-centric assets become revenue-generating products,” explained Barry Bealer, CEO and co-founder of RSI Content Solutions.  “RSuite CMS has worked with MarkLogic from the very beginning to provide content management and workflow solutions to publishers.”

As a gold sponsor of the event, RSuite CMS will be visible throughout the 3-day conference:

• Birds-of-a-feather lunch
• May 1 breakfast sponsor
• Speaking May 1, 3:15 | Compromise Will Set You Free by Lisa Bos

Representatives will be available to demonstrate how RSuite is helping organizations like Oxford University Press, LexisNexis Pacific, Wolters Kluwer, Elsevier and many others manage content and assets. Schedule a meeting with one of our digital publishing specialists by clicking here or learn more at www.rsicms.com

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.

Award-Winning End-to-End Automated Publishing Solution to Exhibit in The Digital Zone; Dan Dube from DocZone to Present Success Stories in the Digital Zone Theatre

DocZone Book Publisher announces its silver sponsorship at the 2012 London Book Fair at stand Y800 in The Digital Zone. The award-winning end-to-end automated cloud publishing team from RSI Content Solutions will meet with book publishers and demonstrate how their publishing clients save time by automating production processes to deliver content simultaneously to print and digital products.

DocZone Book Publisher will also be highlighted during two presentations in the Digital Zone Theatre as Dan Dube, EVP of global solutions at RSI, will showcase success stories of publishers using the system to produce multilingual print books and ebooks.

“DocZone Book Publisher continues to blaze a trail as the first fully automated ‘cloud’ solution for editing and producing both print and ebooks. We are pleased to show our latest release at the 2012 London Book Fair, where we will introduce new support for generating InDesign output from our XML-based publishing platform.” explained Dan Dube. “DocZone Book Publisher enables push-button publishing to PDF, EPUB, HTML, and InDesign. And with built-in language translation tools, it also allows publishers to reach today’s global markets by publishing to these formats in over 200 languages.”

Click here to schedule an appointment with one of our digital publishing strategists.

RSuite CMS Will Provide LexisNexis Pacific with the Tools to Efficiently Manage its Vast Collection of XML

Audubon, Pa.—March 27, 2012—LexisNexis Pacific provides world-class content and leading-edge technology designed specifically for professionals in the legal, risk management, corporate, government, accounting, and academic markets. LexisNexis Pacific recently licensed RSuite CMS by RSI Content Solutions. RSuite CMS is the leading content management system for publishers who want to manage, store, and deliver content to any channel, in any format, at any time.

RSuite CMS will replace several legacy internal editorial systems in use at LexisNexis Pacific and provide a consolidated and editorial system to manage its vast collection of XML, DTDs, metadata, and other content.

“LexisNexis Pacific has a wealth of great content and products,” stated Barry Bealer, CEO and co-founder at RSI Content Solutions. “RSuite CMS will provide the LexisNexis Pacific team with workflow tools and content discovery tools that stay true to their mission of putting the right information into the right hands and giving people the power to change the world.”

“We required a content management solution that leveraged our investment in MarkLogic Server,” explained Andrew Squire, project manager at LexisNexis Pacific. “RSuite CMS is not only deployed on top of MarkLogic Server but it has the added workflow functionality that will enable us to centralise and normalise our content across all product chains.”

Every once in a while a company finds itself evolving and in need of a makeover. Really Strategies reached that point. The company's new name is RSI Content Solutions. "When we founded the company back in 2000, we were 100% focused on XML technology consulting to publishers and media companies," stated Barry Bealer, CEO and co-founder of RSI Content Solutions. "Today, 99% of our revenue is from our software products and related services and we needed to reflect that in our company name."

The name has changed but the dedication to provide world-class content solutions to publishers, media companies, and technical publishers remains.

The new web site reflects the name change and also brings together our three content management software products---RSuite CMS, DocZone Book Publisher, DocZone DITA Publisher---under one url: www.rsicms.com.  Additionally, the new web site highlights more of our customer success stories. When our customers make statements like this, we want people to know!

“RSuite CMS combined with the DITA for Publishers framework is helping us achieve the holy grail of single-source publishing: XML content automatically delivered to InDesign and to multiple ebook delivery formats. The transformations from structured content to designed content have been seamless, allowing our staff to focus on content and product development.”
--Holly Gilly, Vice President for Product Development, Human Kinetics

"RSuite CMS is 200 times faster than our old system. The efficiencies we've gained are hard to believe."
--Keith Lawrenz, Senior Business Analyst, SAGE Publications, Inc.

"We selected DocZone because it is the only DITA-specific CMS available as a hosted solution that met all of our requirements."
--Nancy Thompson, CMS Implementation Specialist, Epson America

"We saw the time for PDF proofs drop from a week to just a few minutes with DocZone Book Publisher."
--Stephen Driver, Vice President of Production Services, Rowman & Littlefield Publishing Group

Over the next week, this blog will also have a face lift to reflect our new brand. We'll share more customer case studies as welll as highlight a series of webinars that kick off in April. Thanks for your interest thus far and stay tuned!

Publishers understand the value of XML but sometimes the cost of entry into an early XML workflow is difficult, expensive, and time consuming. The open source project DITA for Publishers combined with RSuite CMS changes everything.

DITA is a sophisticated XML-based application architecture for authoring, producing, and delivering information. While enthusiastically adopted in the TechDoc world, DITA is less understood among traditional publishing organizations.  Until now. DITA specialist Eliot Kimber and technology evangelist Christopher Hill are hosting a webinar in March that details how RSuite CMS and the open source project, “DITA for Publishers" is  the toolset that launches publishers into the XML world and why this is critical. DITA’s unique extensibility architecture makes it a better business value than any comparable XML alternative. Eliot and Chris' enthusiasm combined with a straight-forward approach to CMS and DITA, will have you starting to take DITA seriously.

Webinar details

Wednesday, March 21, 2012 2:00 PM - 3:00 PM EDT

How Successful Publishers Deliver Content: RSuite CMS & DITA for Publishers

Panelists: Eliot Kimber & Christopher Hill

While catching up on some metrics reported by various publishers on ebook sales, I thought it would be a good idea to consolidate them in a quick list:

• Penguin ebook sales doubled in 2011---Penguin Group (USA) CEO David Shanks stated: “Our eBook sales doubled, we expanded our digital publishing programs, and we won a Pulitzer Prize for the second year in a row.”
• Association of American Publishers report ebook sales went up 72% in December---eBooks grew slightly over November 2011, closing out the year with an increase of 117% over 2010.
• Hachette Book Group reports 130% increase in ebook and audiobook sales in 2011---These digital products represented 22% of the company’s overall revenue in 2011, compared with 8% in 2010.
• Bloomsbury reported its eBook sales grew 38% in the fourth quarter of 2011 over sales during the same period last year---Chief executive Nigel Newton, stated: “We have a robust business, strongly adapted to the digital market place, that we have positioned to take full advantage of the continuing opportunities arising from growth of online sales and sales of ebooks.”