We are often asked by publishers what they can do to get a content management initiative headed in the right direction. Following are 7 tips that all publishers can follow to ensure a successful CMS project.

1. Data conversion | Typesetting service providers. Define what role a conversion house or a typesetter will have in the project and communicate that to in-house staff and the service provider. Get them involved early and detail the business requirements to them as well.

2. Pilot content. Identify and select representative publications that you would like to use as test content. It's useful to have a range of content types from your publishing organization (eg, 1 journal, 1 textbook, 1 instructor's manual, etc). But keep the number of actual documents small so you can work out the data details. You don't want to spend too much time just massaging data and not implementing core features.

3. Business rules. Define the essential business rules that the system needs to reflect. What are the high-level business process workflows? Keep the business process as simple as possible yet still document useful tracking and management. This usually means reflecting the key development, review, and approval steps. Don't necessarily model each little thing each actor does in the process. Shoot for the 30,000-foot view.  Typical RSuite customers require

• permissions
• data validation
• approvals

4. Metadata and search. Pinpoint the key discreet pieces of metadata that need to be captured to enable searching, reporting, and general management of content objects. Think about how you'll want to be able to search and find things from various users' perspectives. Also consider what you'll need to report on from a management and tracking aspect. Typical metadata fields include

• ISBNs
• DOIs
• author names
• classifying metadata
• controlled vocabularies
• approval statuses

5. Key deliveries. Determine what the system needs to deliver and export in order to demonstrate success.  Some key deliveries RSuite customers require include

• input to page layout
• XML for aggregation
• HTML for a Web site
• EPUB

6. System integration. Consider what systems the CMS will need to interact with now and in the future. Create a thorough list of systems that your editorial and production staff use. Obvious systems include page layout systems such as Typefi or InDesign. What about peer-review systems? Will your CMS deliver content to your web site? 

7. User roles. Specify all types of users of the system and define their roles. Will users interact with the CMS on a daily basis? What are the logical job roles? Will you need to provide for "casual" users of the system?

The main idea is to get your staff thinking about content management and CMS before you embark on an actual CMS implementation. Define, document, and communicate to internal staff, decision makers, stakeholders, and service providers. Have any other tips to add? How do you measure the success of your CMS implementation?

Compromise Will Set You Free: Lessons Learned From RSuite CMS Implementations

RSI Content Solutions' Lisa Bos will speak at the 2012 MarkLogic World Conference next week in Washington DC. Lisa serves as the CTO and EVP of publishing solutions with primary responsibility for the RSuite CMS product vision and engineering. Lisa is a recognized industry professional and an expert in the design of XML-based content management systems.

Her presentation at MarkLogic World, “Compromise Will Set You Free,” presents lessons learned during RSuite CMS implementations about simplifying projects. Lisa explains

“Our customers invest significant time, energy, and money to collect their assets into a central content management system. They do so with vital strategic goals in mind—single-source publishing, content discovery, and rapid product evolution. But many sabotage their efforts by resisting compromises intended to reduce the complexity and inconsistency of their systems, workflow processes, and content. Instead, they get bogged down with painful specifications and conversions—from Word to XML, from XML to InDesign, and so on—and they are distracted from the goals that are truly key to their success."

Lisa will share ideas and customer experiences that will inspire publishers, media companies, and content-centric organizations to make some tough decisions that result in simpler, more successful projects and that make them wonder why they resisted compromise in the first place.

The 2012 MarkLogic World Conference is May 1 to 3 in Washington, DC. It is 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.”

Eliot Kimber, senior solutions architect at RSI Content Solutions, spends most of his days helping publishers implement RSuite CMS, proselytizing DITA For Publishers, testing XML-to-EPUB3 conversions, and tending to his brood of hens and rooster. In his spare time he wrote a book: DITA For Practitioners, Volume 1, Architecture and Technology published by XML Press. On behalf of all his co-workers, congratulations Eliot!

Eliot has spent the past 25 years entrenched in generalized markup languages. He was one of the founding members of the XML Working Group, a co-editor of the HyTime standard (with Charles Goldfarb and Steve Newcomb), a long-time member of the XSL-FO working group, and most recently, a founding member of the DITA Technical Committee.
The goal of this book is to provide a detailed look at DITA aimed at engineers, tools builders, and content strategists – anyone who designs, implements, or supports DITA-based systems – as well as experienced DITA authors who want a deeper understanding of the technology they are using.

Self Engineering, Chad Fowler (LivingSocial)

Bryan: The ideas presented in this talk were more life-hacking than tech-hacking---but the talk was inspiring. The premise was that of treating one's life goals as engineering problems, and using those principles---measurement, decomposition, analysis, iteration, etc.---to drive the goals forward.

Rob: The talk set the tone for the conference as a whole. Digging into other areas of the sciences can help with whatever you are working on. The measurement, analysis, improvement loop was a common theme in many presentations.

Javascript, Programming style, and your brain, Douglas Crockford (Yahoo)

Bryan: I didn't know what to expect from this talk but I am familiar with Crockford and some of his work. He proceeded to outline the motivation for creating JSLint and the reasoning behind some of the most restrictive cases, making a convincing case for each---citing reduction of common error frequency as the most common reason for most subsetting rules. I came away feeling humbled and knowing that I should probably lint 3.7 to, at least, understand where the failures were likely to be.

Ember.js: Attacking Boilerplate where it lives, Yehuda Katz (SproutCore, Ruby on Rails, jQuery core)

Bryan: Ember.js is a fairly lightweight (143k) framework that solves common problems in application development---the most notable being that of end-to-end data binding. That is to say, a single update to the client-side model of a ManagedObject would update every presentational instance of that Object with no further coding. This is the end result, but this result is enabled by an object model that includes many missing language constructs in Javascript; it can be, among other things, considered a "java.util.*" for Javascript.

Just beyond HTML5: Device APIs with PhoneGap, Brian Leroux (PhoneGap)

Bryan: (Web) Device APIs are an ongoing set of independent projects going on at the W3C, Mozilla, several Cell manufacturers and service providers. They are simply ways for a browser to get access to the device's hardware in useful ways. While the projects are all starting to converge now - and standards emerging - there are significant problems yet to be solved. Most notable of these are a common security model that asks the user for permission to perform a task in a way that is both not annoying ("may coolthing.com do this, please?" every 5 seconds) and not cursory (like the install-time permissions for Android apps, resulting in a “yeah whatever you like” response from most users).

Abstracting CSS for Sustainable UI, David Kaneda (Sencha)

Bryan: CSS can quickly become a mess for even the most basic web application. Less, Sass/Scss, and Stylus are CSS preprocessors that enable simple, abstracted style rules to be constructed that produce complex CSS. I had already considered using Less with the RSuite product, and this talk convinced me.

The Evolution of CSS Layout: Through CSS 3 and Beyond, Elika J. Etemad (W3C)

Bryan: This was a brief walk down the history of CSS, the technical challenges inherent in describing the CSS level 3 2d layout spec. Fascinating and lots of political intrigue, but not much meat to report on.

Emerging Programming Languages: A Tour of the Horizon, Alex Payne (Simple Finance)

Rob: There is a ton of work going into developing new languages. Whether it is a better Java or JavaScript, or something completely different like new querying languages. Alex tried to focus on languages people mostly have not heard of, so the direct applicability is not readily apparent. However, he essentially gave an overview of the various types of languages that are available and what to use them for.

Building Real-Time Web Applications, Aaron Mulder (Chariot Solutions)

Bryan: Discussion of Web Sockets and Web workers as enablers of real-time applications in a browser. Web Sockets are especially interesting to me to enable the server to push notifications out to the browser, rather than rely on polling. Web workers are less interesting to be in the context of RSuite: while they enable serious client-side processing without interupting the interface thread, the hardest thing RSuite does is parse JSON and XML - and because webworkers have to communicate via serialized data, that's hardly a help.

The Coffeescript Edge, Trevor Burnham (Author of CoffeeScript: Accelerated Javascript Development)

Bryan: CoffeeScript is a terse language that compiles into clean Javascript. I was aware of it before, and I may seek to learn it now. Integrating it into the CMS build process and the build for our plugins would be fairly trivial, and may be useful for writing better code but I don't intend to use it in RSuite unless a compelling case can be made, and even adding the feature may just be the urge to Kitchen Sink in every cool thing.

Javascript Testing: Completing the BDD Circle in Web Development, Trevor Lalish-Menagh (Comcast, EnvJasmine)

Bryan: Unit testing of Javascript code was not something I had considered to be feasible. I had always approached the UI testing question as an end-to-end matter: use Selenium to test your final product. This talk gave an example of how to unit test Javascript at build time, and enable UI developers (i.e., me) to notice a build break before commit, rather than after; how to integrate a platform like EnvJasmine into Maven or Ant; how to run a CI such as Jenkins. Being able to TDD my Javascript will be a nice change.

Storm: Scalable and Fault-Tolerant Realtime Computation, Nathan Marz (Twitter)

Rob: Realtime data collection and processing is a hot topic right now and Storm is an open source product from Twitter. Twitter uses Storm for much of their analytics tracking, so it is required to be a distributed solution. Basically, it is like Hadoop for realtime data.

The Programming Ape, Coda Hale (Yammer)

Rob: “Software needs to fit the human mind.” The basic idea being our brains are wired to do some things better than others. Pattern matching is one thing humans do well. As an example, a graph showing some performance metric might show a spike at some points, but what is the context and is it really a problem. Baselining the information and potentially showing a colored based chart is intuitively easier for humans to process.

SQL, NoSQL or NewSQL, Chris Richardson (SpringSource)

Rob: Simple comparison of some of the NoSQL solutions (MongoDB and Cassandra) as well as NewSQL tools (VoltDB) and why they can be used instead of a traditional RDBMS. MongoDB looks very interesting and could be useful for storing internal metrics. Cassandra is widely used but querying the data just sucks. NewSQL is really an RDBMS but with distributed scaling built in. VoltDB does not look ready for production use.

Emerging Languages, Alex Payne (Simple Finance)

Rob: There is a ton of work going into developing new languages. Whether it is a better Java or JavaScript, or something completely different like new querying languages. Alex tried to focus on languages people mostly have not heard of, so the direct applicability is not readily apparent. However, he essentially gave an overview of the various types of languages that are available and what to use them for.

Behind the Scenes with Spring Batch, Josh Long (SpringSource)

Rob: Spring Batch is yet another framework for batch processing. I am not sure if it would fit with our background processing or scheduled job frameworks, but definitely something to look into. I did not stay for the whole session.

Effective use of FindBugs in large software development efforts, Bill Pugh (inventor, Skip Lists; lead, FindBugs)

Rob: I joined this session half way through. FindBugs is a static analysis tool that can find potential errors in your Java code. He talked about prioritizing issues, customizing FindBugs, sharing issue data and using annotations with FindBugs. There was some mention of plugins but I would rather not worry about the structure of a class file and how to manipulate Java bytecode.

HTML5 Apps in Java and Scala with Play, James Ward (Heroku)

Rob: Not much about HTML5, but plenty of discussion about Play, a web development framework. Essentially, Play is a hybrid of Restlet and some of the Spring Controller ideas. I had hoped to see more information about the breadth of Play but it is definitely something I will be looking into for upcoming RSuite releases. Also, this was one of many sessions to talk about Scala, a newer language built on the Java VM. I will be looking at Scala to determine if it fits into our architecture and whether it would benefit us at all. Akka is another framework, used for actors and event-driven applications, mentioned fairly often and supposedly integrates with Play.

Building Applications with Functional Domain Models, Event Sourcing and Actors, Debasish Ghosh (Author, DSLs in Action)

Rob: This was a difficult presentation to follow. Slides were text heavy. However, the content was interesting and complex. Modeling functions or behaviors in the system as opposed to modeling objects is becoming more popular in the mainstream. By modeling behaviors, event-driven applications become much simpler to implement as they have a direct relation to your domain model. This was another presentation using Scala and Akka.

Kanban, Lean and Large-Scale Agile, James Shore (Author, The Art of Agile Development)

Rob: First, large-scale agile is really just more than one team using agile processes. Kanban comes from the Toyota production systems, where a Kanban is an empty bucket or bin. The basic idea is that we are trying to no significant backlog of work products. This means, no huge pile of requirements documents, but giving a partial set of requirements to the design team. This can be extrapolated to all of the groups on a project where they are assured of having a small list of things to be working on, and all of the teams are working in parallel.

Creating a Cross Platform Experience, Doug Bellenger (Movitas)

Rob: Movitas develops mobile applications for the hospitality industry. The apps have to run on various platforms, like the web, tables, blackberry, iphone and android. They created layers of abstraction when some things needed similar functionality, but the user interface or skin needed to be different. Knowing where the abstractions should be is difficult. There was not a lot of coding detail in the presentation, mostly just some high level concepts.

Webinar Series on the Business Case for Digital Content

RSI Content Solutions and Data Conversion Laboratory are kicking off a 6-part webinar series next week that will address the many myths associated with the world of XML, CMS, and eBooks.

The six part webinar series called ‘Reality Check’ features experts in content management and publishing who lead the series and detail how to manage information and transform content to work within eBooks, browsers, and mobile platforms.

Following are the webinars in this series. You can read more here.

• April 26 | Truth of Digital Revenue Streams
  Panelist: Darrell W. Gunter, CEO, Gunter Media Group
  Having worked with hundreds of publishing professionals during the past 10 years, we've observed organizations that implement a strategic content management initiative and converted backlist titles into XML are the ones who are seeing digital revenue exceed print. Join this free webinar and hear the truths about what your organization can do recognize true digital revenue.
• May 9 | Truth About Automation
  For publishers and media companies, automating editorial and production tasks is necessary to keep pace with customer consumption as well as the competition. While many knowledge workers view automation as a threat to job security and an impediment to editorial quality, this webinar illustrates the truths around automating common editorial and production tasks. Indeed automation can free staff to focus on better content development.
• June 9 | Truth About ROI
  Panelist: Christopher Hill, VP Product Development, RSI Content Solutions
  Publishers understand that content management and data conversion is a pivotal piece in today's publishing environment. Yet budgeting for these initiatives can quickly scale to the point where executives question why they should stray from the status quo. In this free webinar, DCL and RSI Content Solutions, will lead a panel of publishing professionals who will discuss how they made their business case and received enthusiastic executive buy-in for content management and data conversion in their organizations.
• August 29 | Truth About DIY CMS and Conversion
  Panelist: Pat Sabosik, Elm City Consulting
  While using internal resources to develop a homegrown content management tool or convert your backlist to XML sounds like a cost-effective approach, the reality is that 82% or IT projects fail. This webinar focuses on the real concerns you need to address so that your organization can make educated decisions based on truths and not what simply seems will work.
• September 19 | Truth About Quality
  Panelists: Mike Edson and John Corkery, The DETI Group
  The premise of all publishing organizations is to provide quality content in a format that customers desire. Ask any copy editor about house style and you can anticipate a lengthy and thoughtful response. Authors too expect nothing but perfection when transforming intellectual property into a print or digital product. So how do successful publishing organizations blend automation into workflows without sacrificing quality?
• November 19 | The Truth From the Publishers' Perspective
  Panelists: Barry Bealer, CEO, RSI Content Solutions and Mark Gross, CEO, Data Conversion Laboratory
  Throughout the year, DCL and RSI Content Solutions have polled a large number of publishing and media executives to understand where they are in terms of strategic XML content management. We’ve asked tough questions around true revenue numbers, quality-control issues, content automation, and ROI. In this webinar series join CEOs Barry Bealer, RSI Content Solutions and Mark Gross, Data Conversion Laboratory who share not only the results of our 10-month polling but also their views on what the metrics mean.

No matter the allure and depth of digital products in today's world, publishers still need to print well-designed pages. At the last RSuite User Conference, we asked attendees what feature they found most useful. The ease of content transformations ranked high on the list of responses. Check out the following description about how RSuite CMS can automate content transformation to InDesign, HTML, EPUB, and PDF.

Want to learn how publishers are using RSuite to automate XML transformation to InDesign? Download our latest white paper: DITA For Publishers: How Successful Publishers Deliver Content

We’ve heard the allure of digital revenue for more than a decade. Yet many publishers still report that print supersedes digital. And a majority of publishing organizations continue to structure people, processes, and tools to support a print-first environment. In 2012 the rules have changed. Having worked with hundreds of publishing professionals during the past 10 years, we've observed organizations that implement a strategic content management initiative and converted backlist titles into XML are the ones who are seeing digital revenue exceed print.

RSI Content Solutions and Data Conversion Laboratory are hosting a series of webinars this year that examine today’s publishing landscape. This webinar series will step back and differentiate fact from fiction. We'll present success stories that demonstrate how publishing organizations are navigating the world of XML, CMS, and ebooks to meet and exceed customer demands.

The first webinar of the series is moderated by Darrell W. Gunter, CEO, Gunter Media Group. Register for this free webinar and hear the truths about what your organization can do to recognize true digital revenue.

Webinar: Reality Check: The Truth About Digital Revenue Streams
Date: Thursday, April 26, 2012 1:00 PM - 2:00 PM EDT
Moderator: Darrell W. Gunter, CEO, Gunter Media Group

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.

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.