In this brief video, Keith Lawrenz, Sr Business Analyst & Content Systems Supervisor at SAGE Publications, explains why RSuite CMS is a great fit for publishers and how RSuite CMS has enabled SAGE to control their content. You'll hear how SAGE had tens of thousands of zip files that they couldn't begin to look at until RSuite CMS was implemented. Now, they're able to search and discover their content within RSuite.
Interested in seeing how RSuite CMS can manage your organization's content?
Topics: content management, RSuite CMS, publishing, zip files, Success Stories, control
As with everything in life, it's all a matter of the lens you view things through. Something can look rosey to one person while looking like a train wreck to another. Often times the view of a legacy content management system is dependent on where you sit within your organization, and rightly so. But many times the decision to not replace a legacy CMS is based completely on the false premise that everything is OK and IT has everything under control. In our experience, many times the IT organization is overwhelmed with projects and maintaining a legacy system becomes more difficult with each passing year.
In many publishing organizations that we speak with on a daily basis, legacy CMS' are patched together by one or two very key individuals within an organization because they happen to be the longest tenured staff and were around when the system was installed. There is generally a knowledgebase of small system idiosyncracies that these individuals know to stay away from because of either a design flaw or through implementing the system incorrectly. Having an IT person be a single point of failure is not a good business practice to begin with, but having little or no understanding of what the black box legacy CMS is doing is much, much worse. Unfortunately these situation exist at major publishing organizations around the globe. This is an outgrowth of publishers who don't want to face the reality that their system is in serious jeapordy of crashing and there is no recovery mechanism in place.
So how does each management level within a publisher view a legacy CMS? Here's an outsiders perspective:
From the top, everything looks calm, cool, and collected. Think about the duck gliding across the pond. Products are being produced, money is being collected, why do we need to change anything? Remember the duck is paddling like crazy under the water.
While there are issues we need to address, the technology is solid and has been proven for some time. Our team does not have turnover issues and therefore they are well versed in the CMS. Some investment might be required to patch things here or there, but we have no need to upgrade to a new CMS. Throwing more staff or budget at the legacy CMS will take care of everytihng. We should be fine to meet our strategy.
The system has been working, but barely. The fragile nature causes daily concern that one hiccup could bring the entire production process down. Editorial is comfortable with the workflow, knows the editorial tools, but under the covers the CMS cannot be extended and is patched because the technology has not been upgraded in years. Adding more content, integrating with other systems, or adding third party tools will be extremely difficult without a large budget and a sufficient timeline to complete.
The application has been maintained by different people over time. Nothing has been documented, we have not paid support and have not received CMS software upgrades, and the underlying database has not been upgraded in years. If the system goes down, I may need to look for a job.
Every position and management level at a publisher has a different view of their CMS. It's natural. What consistenly surprises people is that a legacy CMS can only address the requirements from yesterday and potentially not address the strategy of multi-channel publishing or automated eBook creation or whatever objective because changes are difficult and the system cannot scale. Legacy systems are generally proven, but they do not generally have the stability to support the long-term business objectives and must be replaced.
If your CMS is over seven years old, has been patched to keep it running, and doesn't support your strategy, let us show you why publishers from around the globe and over 10,000 publishing professionals use RSuite every day.
Topics: content management for publishers, content management, CMS for publishers, Content Mangement Project Team, CMS Teams, Legacy CMS
Last week we attended the DITA North America conference in my home city of Seattle. It is always interesting to have the opportunity to interact with the DITA community. During a birds-of-a-feather lunch gathering I had some interesting conversation regarding the promise and perils of content re-use. Many of those in the conversation were new to DITA. As we discussed the challenges around content re-use in DITA I was reminded of the many pitfalls often encountered that often subvert the efficiencies promised by DITA.
One of DITA's more attractive feature is its ability to provide a range of technical support for reusing content within or across publications. Traditional authoring and page layout tools tended to have limited support for re-use, and often the mechanisms for this support was proprietary. This is why more often than not these tools are underused in favor of copy and paste.
The DITA specification has effective, open concepts of re-use baked into the design. This means that using DITA for content authoring eliminates the technical hurdles limiting the re-use of content. It's topic-based approach encourages the creation of reusable content. Many organizations that move to DITA, then, are often surprised when after solving the technical hurdles content is still not widely re-used in their organizations.
Many challenges to content re-use exist that are not technical. Unless these are addressed as part of a DITA project, wide re-use of content may remain an elusive vision. Here are some of the critical challenges that should at least be considered when trying to create an environment of content re-use.
Most content delivered today is shifting from traditional print deliveries to a range of digital delivery formats. Yet when the content is authored it is often from the perspective of a single deliverable. Even though the tool may allow any section of a book to be re-used, you may find that the way the content is actually written prevents such use. Imagine a section of a technical manual that makes reference to other content contained in the manual. What happens if that content is re-used in a manual that does not contain the referenced section? And are such references required to be clearly tagged so that tools can provide assistance in managing such references when needed? Often this area of training is not well-addressed and authors continue to create content dependencies that are difficult to manage.
Authors who write content units only in the context of a deliverable will be tempted to write content that is dependent on the particular deliverable. You can't assume that they'll "figure it out" or that a tool can magically change such behaviors. You need to have a plan to train users not only on the technical use of the new tools but also the conceptual framework that DITA brings.
Another temptation is to try to simplify your DITA implementation in an attempt to address potential dissatisfaction from your users. While it sounds like an XML editor that hides details and "acts just like Word" might be much easier for users to learn, if such a tool becomes an excuse to hide the details of DITA from the content creators then you may actually impede the realization of many of DITA's benefits. One of the important foundations of DITA is in separating content from presentation. This is at the heart of its powers to support single-source publishing.
In such a scenario, the concept of a WYSIWYG editor makes little sense. XML editors that provide a word-processor-like view are really better thought of as tools that present a style of XML useful for the authors in the creation of content. As such, when you design stylesheets for your authoring tool you probably do not want them matching your print output. Doing so risks obfuscating many important structures that are not visible in a specific print output but may be important foundations for re-use and linking. Instead of trying to match the authoring tool to a specific output format, you should consider creating styles for authors that make apparent the information they need to manage in order to create re-usable content. Metadata, conditional tagging and other supporting structures should be made apparent and easily accessed. If hidden behind a context menu or in an external panel users may find their use cumbersome. Worse, unexpected behaviors not readily apparent to someone re-using the content may occur. Such surprises often result in users avoiding the re-use of content they can't readily understand.
Access to properly configured tools and training is critical if you expect your users to take advantage of DITA's support for re-use. Not everyone needs to have a full set of content analysis skills in order to use a DITA system, but they do need to know the details of how your particular business environment is configured.
Many DITA projects start using the DITA open toolkit and a file system or shared folder. But problems can occur specifically around re-use in such a scenario. Shared folders rarely provide controlled access to content. Content in directories often provides no mechanism for tracking versions, controlling updates, and ensuring that two users do not try to modify the same content (or overwrite others' content). When a small DITA project is rolled out to a larger set of users these problems worsen with increased content re-use. If a team runs into these problems they quickly begin creating copies of content anyway to avoid the problem — eliminating any potential benefits of content re-use.
Content management is also needed to support the organization of content components. Content management systems often provide the ability to support metadata and search features that make locating potential content for re-use much easier. Relying on a shared folder typically means that as the number of content components increases users' ability to find re-usable components decreases. At some point, users may decide its easier to write new content rather than try to deal with these challenges.
Unless you have a very small team that is tightly coordinated content management is an important tool for maximizing your investment in DITA.
These examples represent just a few of the many potential challenges that can surprise newcomers to DITA. Some may be addressed through training. Some may improve with experience. But it is very hard for organizations new to DITA to make content decisions before they have sufficient experience. And there is often a chicken-and-egg scenario where the promise of DITA remains unrealized without an investment in tools to properly use it. Such investment is often risky, as it may require investment in integration, licenses and products unfamiliar to your organization.
In the last several years, however, tools like our own DocZone product are available that provide preconfigured integrated DITA tools on a hosted basis. For a monthly fee, you can license the use of DocZone's best-of-breed tools in an already integrated and configured environment. If your organization is new to DITA and/or content management such a solution can enable users to build experience on a professional platform without the cost typically associated with setting up such an environment yourself. Because you are in a proven, production-ready environment you are less susceptible to many of the problems typically encountered when setting up a new DITA environment. A hosted solution also can scale to address the requirements of small and large teams. The use of DITA also means that your content can be used with other DITA-based tools if needed.
Trying to achieve the full promise of DITA is a challenge whether you try learning in an ineffective shared-folder environment or try integrating an end-to-end DITA toolset for the first time. A hosted option like DocZone is a great alternative to taking on these challenges alone.
Topics: content management, DITA, DocZone
Every so often we get inquiries from our RSuite enterprise clients or prospects about why there are services required to implement our RSuite software if the pre-configured environment is pretty much useful out-of-the-box? If one digs a little deeper and analyzes exactly what types of services are required, I think a publisher will be surprised that services related to customizing or extending the content management software are actually pretty small. Sure there will be custom forms for metadata capture or custom search forms, but these are generally a few days worth of work at the most. On the other hand, services related to content structure and workflow re-engineering have a huge impact on the services required for a content management product implementation independent of the software package chosen.
Content Engineering
Content engineering can be simply defined as understanding the structure of your content and putting a migration plan to make it adhere to some type of standard. In some cases very large publishers have crafted a proprietary content standard, but many adhere to industry standards such as NLM, D4P, DocBook, etc. The amount of services required to transform the content from one format to another can vary widely depending on the amount of file formats and complexity of content. While this effort can be categorized as part of the content management project, it is not part of the content management software.
Content structure and organization reflects how an organization has worked over time. If the publisher was disciplined and remained in compliance with industry standards, the amount of services to get the content into the content management system is minimal at best. Basically, if the publisher has well structured content that adheres to a DTD, then it should just work in RSuite or other systems. The challenge surfaces when multiple products adhere to different DTD's and then the publisher wants to consolidate under one standard. Again, a very good idea, but this is an issue beyond the content management software. Or the publisher has no DTD and wants to migrate all of their content to a standard. Again, an excellent idea, but the effort to complete this should not reflect on the content management software. As one of our engineers has said, "there is no magic button to transform the content, you either have the discipline to adhere to a standard or it will take some work to transform the content so that it does comply". There is no simple solution.
Workflow Analysis and Automation
Services related to workflow are generally consultative in nature whereby a business analyst sits with all parties to understand current "as-is" and "to-be" workflows. In some cases publishers have done a very nice job documenting their current as-is workflows but have a difficult time envisioning the to-be workflows. This is normal and can generally be addressed by creating some pilot workflows and showing the client how the software will help them. In some cases though a publisher which has been doing business one way for the past 20-years can have cultural challenges to change to the to-be workflows. This has been becoming less and less over the past 5-years as the need to embrace multi-channel publishing is critical to the sustainability of the publishing business. In other words, optimizing workflows, creating efficiencies, and actually automating multi-channel publishing are no longer options. It does mean in some cases that people within the publishing organization will have to be re-skilled or let go. That is unfortunately the nature of the game right now for publishers. Workflow equals efficiency which equals cost reductions which equals a reduction or reallocation of staff or an increase in production throughput.
A publisher that requires significant manual steps (e.g., a person needs to review and approve content) in their workflow will not realize the true benefits of implementing the workflow software. Manual steps are still required in the editorial process, but minimizing them is key. An automated step (e.g., content transformation) is the key to gaining the efficiencies that are sought by management. Depending on the complexity of the automated steps, the amount of services required can vary widely. The key is automating the highest value steps in the workflow and minimizing the manual steps. Again, the more a publisher understands how they need to change their process, the less services will be required to implement the content management software. The software will do whatever you configure it to do, but time spent understanding exactly what a publisher should be doing takes time and requires a visionary within your organization to think outside the box.
The Bottom Line
For both content engineering and workflow related services, the more a publisher is organized in these areas, the less services are required for a content management project independent of whether it is RSuite or not. The painfulness of addressing years of neglect in a structured or disciplined production of content can require significant services to unwind the structure, business rules, or lack of adherence to standards. Unfortunately this can be seen as a barrier to implementing a content management system.
While a new content management system could offer tremendous value in content reuse, version control, and production efficiency, the new software cannot magically address the messiness of the content or undocumented workflow. If your team has been organized and have very structured content with a well documented and agreed upon workflow (even if you are using legacy technology), then services to implement a CMS should be relatively small.
If you are embarking on a content management initiative, I would highly recommend that you have an honest assessment of your content structure and your workflow. If these pieces are in order, then you have just increased your odds of a successful content management system implementation and reduced the required services to implement the software.
Topics: content management for publishers, RSuite, content management, DITA for Publishers, CMS, CMS project, Barry Bealer, content conversion
I had the opportunity to attend the Outsell Signature Event last week that brings together top executives from the information industry. As always, everything that Outsell does is top notch and so in an inviting setting and surrounded by movers and shakers in the industry a number of key topics were discussed, debated, and argued. The event traditionally focuses on all aspects of the information industry and provides an executive level view of the economy, business models, technology adoption, current stress points, and business and technology transformation.
Some random points from the sessions:
While RSuite CMS was not front and center at this conference as an exhibitor, it was interesting to speak with publishers who continue to be challenged by managing a large (dare I say big data) set of disparate content.
Publishers realize that content management software is an absolute necessity to transforming their organization, and I believe executive management understands the larger problem is with their processes and culture. The culture (i.e., people) side of transformation is probably the most challenging and will continue to require a significant investment of time and money to address. The process side of transformation is a bit easier because everyone wants to make their jobs easier and more efficient. It is great to finally hear executives say that XML content management is no longer a "nice to have" but a necessity in business transformation to meet multi-channel publishing goals. Fortunately, RSuite CMS is positioned very well to help out publishers in their transformation.
I look forward to the meeting next year.
Topics: RSuite, content management, Outsell
For the bulk of my 10+ years in various jobs involving content management I found myself routinely discussing metadata at work. I don't know if I ever recall the subject arising outside of that sphere. This month that has changed literally overnight. The breaking news on the National Security Agency's PRISM program - apparently focused on collecting metadata regarding telephone calls - has brought metadata to the attention of the general public. Suddenly I'm reading tutorials on the term metadata in newspapers and magazine, hearing it defined on network television, and finding opportunities to discuss metadata with my non-technical family, friends and acquaintences. I've often said that metadata can be just as important as the content it describes, and the PRISM program serves as an excellent example of this.
I find it sometimes dismaying that even today content management problems still neglect to give proper attention to the subject of metadata. Many of the RFPs I read have highly detailed inquiries regarding the ability to work with content including re-use, componentization, and other sophisticated capabilities. Most of the time, however, they make only a few cursory inquiries regarding metadata neglecting key capabilities that can adversely affect the ability to take advantage of some of these advanced content management capabilities.
Here are some of those neglected metadata capabilities that may have a major impact of your ability to solve your content management issues.
Extensibility
More times than I care to remember I have worked with systems that have very little flexibility to modify metadata requirements after they are deployed. These are often related to technical implementation issues relating to the underlying architecture. You know you are working in such a situation if adding a new metadata field requires system downtime, interventions of a team of database administrators, or the cooperation of a team of programmers.
In practice such systems tend to limit metadata to a few narrow cases and fields. This is sometimes tolerable with systems dedicated to specific tactical production duties or limited content repositories. But when trying to deploy solutions horizontally through an organization or adapt a production system to a broader set of requirements or tasks it is typically easier to just deploy another content management solution than adapt the existing one.
When I worked for a semantic text mining company we provided a tool that could extract a list of all of the important metadata values from a piece of text. This included things like lists of people, places, companies, landmarks, events, etc. present in the text. There was no artificial limit to how many of these things might be present. Unfortunately, when we worked with many companies we found their systems could only deal with a predefined number of items, and the user interfaces were not well-equipped to present or manage these lists of items.
Look for a content management system that has the flexibility to be modified over time. Inquire about how metadata is stored and the provisions to modifying and expanding it. Can metadata fields have any number of multiple values? Try to uncover these limitations in both storage as well as user interface.
Selective presentation
Another problem that plagues many systems is their assumption that all metadata fields are important to all users equally. In reality, most users are only concerned with - or even prepared to understand - a subset of the metadata on a piece of content. Compare the key interests of your editorial staff to that of your marketing team or legal department. Are you able to selectively present each potential viewer of content with appropriate metadata that serves their needs, without wading through a lot of information that isn't important to them? I have sat through many analysis meetings where representatives of every stakeholder gather around a table and spend hours, days or weeks trying to agree upon a comprehensive set of metadata.
Instead, look for your content management system to provide the capability to selectively present relevant metadata to different audiences. This should include the forms to view and edit metadata as well as a means to provide different search tools that make it easy to filter based on each category of users' requirements.Then you can maintain a large body of metadata appropriate to a wide range of requirements without overwhelming an individual user.
Context sensitivity
Today it is common for organizations ask for a content management system to provide them with the tools to re-use content. Yet even when the requirement is specified and delivered, in practice the capability often goes unused. One of the hidden reasons for this is in the inability of most systems to allow metadata to vary based on context.
In many situations a user may want to re-use a piece of content in a few places - but requires different metadata values in each place. As a simple example think of a photo caption. A caption appropriate in a novel may not work when the photo is used in a news article. Digital rights may be secured for the same photo multiple times, each needing its own context-specific representation. In countless situations like these, the inability to have some of the metadata vary by context means that users are forced to copy and paste content and cannot take advantage of the re-use tools provided by a system.
Even if the initial deployment of a system will not require contextual metadata you will probably find yourself wanting the capability at some point in the future.
Versioning... or not
Most content management inquiries will ask about versioning content. But what about metadata? In many systems, metadata is either a required part of the version history of content - meaning that every change to a metadata field creates a new version of the content. This may be desirable for many of the fields, but there are some cases where all of the versions created by metadata changes end up generating so much noise in the content's version history that those features become difficult or impossible to use.
At the other end of the spectrum are systems that do not version any metadata values. For important metadata values, this can be risky as there is no way to determine when or even if a metadata value was modified.
In reality, most organizations will have some metadata they want to keep in the version history and others that they do not. Unfortunately, it is generally after they have started putting a tool in production that most people find out the capabilties of their system.
These four metadata requirements are significant in their impact of content management and can have major implications on how a system is implemented and adapted over time. While not all of these are a necessity to a single solution, their absence may make it difficult or impossible to adapt or expand your system in the future.
You may be thinking of some other neglected metadata requirements you've run across. If so I'd like to hear about them.
Topics: content management for publishers, content management, metadata
RSuite CMS is a content management system for publishers that serves a wide range of workflow and content needs. To better serve our customers as well as the greater publishing community, we want to understand what's important in terms of a work-in-progress and finished goods repository. Most everyone agrees that an archive of published content is critical. The importance of maintaining versions of the various formats is also something no one will argue. Yet when it's time to roll out that new edition, or search for the latest file to do an erratum, content can be harder to find than it should (in theory) be.
Over the years, we've seen many different content storage scenarios:
Over the years, we've also maintained that a secure content repository is the first step in content management. Because if you can't find your content, how can you do anything interesting with it?
We invite you to take part in our short survey to assess how you approach the topic of content storage and a finished goods repository. Or as we like to call it, a publisher's warehouse.
Topics: content management, RSuite CMS, publisher's warehouse
Today, stresses on the publishing industry are more accelerated than most other industries. New expenses are added to reach publishing targets and those expenses don't always add to total revenue. A content management system (CMS) helps publishers manage, store, transform, and delivery content in a sustainable and economical way. A CMS is a publisher’s factory.
Want to learn how your organization can benefit from RSuite CMS?
Topics: content management for publishers, RSuite, content management, CMS, digital publishing
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? In this webinar, we’ll reveal some interesting truths around quality control and provide tips that you can bring back to your office.
Join panelists Mike Edson and John Corkery from the DETI Group.
Topics: content management, Webinar
RSI Content Solutions and Data Conversion Laboratory are collecting input on the state of technology adoption and digital revenue metrics from publishing and media organizations. We want to understand and analyze how publishers are approaching the digital landscape to benefit customers and recognize increased revenue from multi-channel publishing. We've created a quick survey to gather input and will share the results of this survey at our November webinar. Additionally, everyone who takes the survey is entered in a drawing for a $100 American Express gift card. The winner of the drawing will be announced here on this blog.
