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 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.
Technical skills for publishers using a CMS and XML
Publishers often ask us what skills they should have on staff in order to be ready to use a CMS and XML. Our response is that publishers will be more effective if they have staff with the technical skills tied most closely to their content and products. Not every publisher needs to be able to perform RSuite customizations using Java. (In fact, few publishers need or have this.) But every publisher should know their own content and publishing processes. This is especially important when a system is first rolled out, but continues to be useful for normal system maintenance and for those occasional unexpected problems when you need help fast to get your product out the door. It’s not that you can’t outsource these skills; it’s that you will be more nimble with them.
Identifying Your Content Architect Candidates
At RSI we usually refer to someone with these skills as a “content architect”. In most cases, our customers already have one or more staff members poised to take on deeper content architecture expertise, and hiring isn’t necessary. You’ll recognize these colleagues as the ones you already turn to for answers about why and how things get done.
- They know your content and products deeply.
- They know your processes backwards and forwards.
- They are naturally interested in the under-the-cover details of your existing systems.
- They have technical aptitude – an intuition for how software works or might work. They might also have a background in scripting or another software development area.
Most often (but not always!) these colleagues will be on your print or digital production teams.
Skills and Knowledge Areas to Consider
The following are typical areas of focus for content architects. Each item’s relative importance depends on factors like the volume and pace of your publishing schedule and the complexity of your content and processes. While you don’t necessarily need the same person to be expert in all these areas, having one or two people with broad knowledge across the areas provides the shortest path to solving problems and planning system improvements.
Publishers rarely need staff who can develop an XML schema (DTD or XSD) from scratch, but someone on staff should be able to read your schemas, understand how they are used to mark up your content, and talk in detail with partners, vendors, or other departments who need to use them. This is crucial because you need this skill to manage your vendors (e.g., Is the XML created by your vendor good enough?).
Sometimes it’s useful if your content architect can make minor schema changes and deploy updates to RSuite, but since such changes are rare and rarely time-sensitive, you can usually do without this skill on staff.
Metadata is all the data you use to manage your content and to enable findability and usability on the web and elsewhere. It drives many internal and customer-facing publishing systems. Content architects can help you plan how to build in metadata quality aids and checks, and can diagnose problems when something goes wrong. For example, if topical metadata is missing, content might not be findable on your website or might not be delivered to a partner. How might your CMS help avoid this problem? How can you tell when a problem has occurred?
Transformation knowledge and technical skills
Transformations are the automated or semi-automated steps that convert content from one form to another, such as from Word to XML or XML to ePUB. Transformations are responsible for much of the efficiency gains and product improvements CMS and XML bring.
But here’s the thing: Unless you have products that are very high volume and can be held to extraordinary consistency standards (think “dictionaries”), then your transformations will never really be finished. No sooner will you get one issue or book out the door then you will realize that your next project is just a little different. You need a new type of article, or a new type of layout element. This is normal and this is okay – as long as you can quickly and affordably adjust your transformations for minor changes.
When using RSuite, this means someone on staff (or at least on call) should be able to maintain Word-to-XML mappings and XSLT scripts and the mappings and XSLT scripts responsible for generating outputs from XML. Our most successful customers do light maintenance themselves and call us or other experts only for more complex changes.
Most of our customers use two types of templates: those for Microsoft Word, and those for their page production systems (e.g., InDesign). Templates define many of the inputs and outputs of your CMS. Along with transformations, they enable you to work predictably and, therefore, efficiently. A staff content architect should understand how templates must be used to ensure successful transformations, and ideally will be able to make minor changes to templates to correspond with maintenance level transformation changes.
Workflow and content lifecycle management
“Workflow and content lifecycle management” is a fancy way of saying someone needs an understanding of the changes content goes through over time, from creation/acquisition through to delivery to all targets, and who or what is making those changes. While the prior areas focus on the technical details of the content and software, lifecycle management adds in knowledge of who (or what system) is doing what when. This holistic understanding is required to quickly debug and correct problems when they occur, and to know when outside help is and isn’t needed.
How to Start?
The best way to prepare someone to be a content architect after your CMS launches is to make them one of the primary participants in CMS implementation. They will naturally learn most or all they need to know through the project. If your content architect is going especially deep with transformations or schema management, then formal training might be desirable, but in most cases it’s not needed. What they will need is some time to gain experience while still being backed up by outside experts.
Your content architect will also need some of his or her ongoing work hours freed up. For some publishers, this work represents only a minutes each day. In other cases, such as when significant new product development goals are being rolled out concurrently with the CMS, this could turn into a fulltime job. Your RSI project manager can help you think through what is most likely in your organization.
In summary, you need a content architect for light maintenance, to solve unexpected problems, and to help plan for content and CMS changes over time. The good news is you probably already have the right person on staff!
Constraints can be beautiful
Several years ago (before I had worked with RSuite), I posted on my personal blog a couple of times on the merits of constraint in design http://blog.chiliarchy.com/search/label/constraint. At that time, I was dabbling in software design but had yet to be responsible for establishing and communicating constraints to the engineers building a software application.
The redesigned RSuite of today often challenged me and the engineering team to balance many competing opinions and interests. With an application offering the flexibility of RSuite, it is tempting to always do more.
Engineers tend to like building things. A good engineer's "can-do" attitude will favor developing enhancements. It's more fun to create new code. Going back through existing code to refactor, trim, or remove can sometimes feel like cleaning out the garage.
Customers often request more, seldom request less
Project managers, the tip of the spear when it comes to customer projects, are also often managing requests for features. Customers tell them they need a button, widget, dial or gadget and it seems simplest to just add it. Rarely does a request come in to remove anything.
Features have immediate and ongoing costs
It's obvious that a new feature costs something to build. Most people consider this when deciding whether or not a feature is worth adding. The more important factor is the long-term costs that aren't so easy to identify. A single button can have an exponential effect on the number of test cases and unintended interactions. Documentation and support have to be revised and maintained. More features often mean more visual elements for users to process when using the software. These penalties often seem relatively tiny when viewed in isolation.
An automotive example
I was on a work trip driving from Minneapolis to a city several hours away in a rental car. I rented a Ford Focus, a car I actually owned in 2000. It was a dark winter night in Minnesota, so I took time to check the lights, made sure I knew to to operate the various wiper modes, adjusted my mirrors, and familiarized myself with the climate controls and stereo.
After 45 uneventful minutes on the road, I made a quick stop for food then headed back out on the dark two lane highway. Twenty minutes later a car overtook me from behind. Rather than pass, he tailgated for a few annoying miles. Suddenly a flood of police lights had me pull over to the side.
As the patrolmen cautiously approached I fumbled for the window controls.
The car "helps"
As I was trying to unroll the window, the Microsoft Sync voice came over the speakers asking how she could help. I didn't know what I had bumped that caused this but decided to first get the passenger window down. As it opened the patrolman asked for my license. As I retrieved my wallet the car's computer voice told the officer she didn't understand the command, could he try again? I began to try to explain when the car interrupted and began listing some examples of commands she could understand.
I fumbled around for an "off" switch. Suddenly the controls I thought I largely understood were becoming confusing. I turned off the key but she kept talking. I pushed several more buttons. I pulled the key out of the ignition. She kept talking. Then I remembered that the power to the accessories remained on until the driver opened the door. I gently pulled the door latch and she fell silent. The officer seemed mildly amused as he said, "Rental car?"
Good design or a trap?
Ford's engineers had done an excellent job adding lots of additional features to this car without making it seem unfamiliar.
A myriad of optional features were present, but not obtrusive. I had left the airport confident that I could competently operate the vehicle. Under stress, however, the inadvertent activation of voice control had suddenly made me realize the large number of controls I hadn't paid attention to. In my attempts to silence the computer I had tried pressing many of them. Would I regret some of those actions later?
The patrolman informed me that I was driving with no taillights. I told him the headlights were working and that they must have burned out. He said that he had seen this a few months prior on a Ford pickup, and asked me to try all the positions for the light control. I turned the knob to several positions. "That's it. Remember that setting."
While he went back to his car with my license, I studied the symbols on the headlight control. What seemed so natural an hour ago now looked like symbols on an alien spacecraft. The patrolman returned with my license and wished me good night.
A dubious feature documented
I'm still not sure why the car could run with the headlights on and the taillights off. Later I consulted the owner's manual. To improve accuracy and save costs, automobile manuals are modular to accommodate re-use across models and provide for optional features. In the manual, there was what appeared to be a single page showing the use of the lights. No where was there any mention of the possibility of using headlights without taillights.
If you were reading the owner's manual cover-to-cover you'd find two more pages on the lights. When was the last time you've done that? At the end of the third page, below several optional features that were irrelevant and further encouragement to stop reading, was this warning.
I had to read it a few times before realizing it applied to me. Although I still wasn't sure how this all played out. Even if we were to move the warning to a more prominent place at the beginning of the section and clarify its language, how many people have read the owner's manual before operating their car for the first time?
A lesson for IT projects
Whether designing a car, creating a piece of software or customizing an application for your organization, managing whether and how features are added is an important activity that is too often overlooked. It is easy to see how a feature might help when used as directed. The real challenge is in being able to see potential unintended consequences the feature may create.
Whether you are designing, modifying or selecting software, it is tempting to just list all the desired features and evaluate its presence or absence. Much harder is evaluating whether the features provided are provided in a usable way. Don't assume that more is always better. Sometimes a feature like "headlights on taillights off" can create problems for users.
If you find yourself having to place warnings or cautions in the documentation you should be reconsidering either the presence of or implementation of a feature.
Software often has an advantage over car design in that it is easier to add custom features to software. The CMS I work on, RSuite, makes it possible to implement features for a subset of users if needed. Sometimes customers complain that some feature isn't included.
Balancing features and design
RSuite has a flexible user interface that can accomodate a wide range of features. Menus can be rearranged and reorganized easily. This makes it not only easy to make product changes, but also can be used if a customer wishes to customize RSuite for addressing specific business requirements.
When developing the product we strive to balance the impact of additional features against the overall product usability. This often means looking for ways to clarify, simplify or modify other areas of the interface. It is also vital to test for unintended consequences that may inadertently create potential problems for users.
Reflect on your design
A major goal as we work on our RSuite product is to find ways to design RSuite's interface to support the highly flexible architecture while discouraging practices that might create problems that are invisible or difficult to correct. This is a primary consideration whenever a user-facing modification is made to the interface. Even though objective perfection is not possible in any design, we strive to examine each implementation and look for potential refinements that could benefit the product as a whole.
We've made a number of refinements over the last several months from these activities, and have identified more substantial changes that will be rolled out in upcoming releases. Some of these will actually provide additional features to users while reducing complexity.
Potential signs of design problems
There are some areas that often indicate potential design problems. None of these are a smoking gun, but they are good starting points when reflecting on a design.
Does the feature rely on an "Are you sure?" confirmation before performing an action?
Do you find your support staff complaining that users don't read the manual?
Are you putting cautions and warnings into your documentation?
Do you rely on users to report problems? Remember users often are unaware of problems they may have inadvertently caused - instead blaming the software.
Are there "irrational" complaints or support requests that cannot be reproduced?
Are there support requests that have been marked "as designed"?
Have you looked at what aspects of product implementation require the most customization effort, documentation effort, or training effort?
More is not always better
Sometimes they are right and we add the feature. Other times the request is narrow, and adding the feature would probably result in more harm than good. It is easy to overlook this whether designing, modifying or evaluating software. Creating a long checklist of features is tempting. But make sure those features don't leave your users in the dark with their taillights off.
RSI began as a consulting company for publishers. In that role, we were often asked by our customers to document their as-is workflows and recommend new ones that would drive electronic product development and efficiency. We spent a lot of time creating massive diagrams. A lot of time. These projects were sometimes useful, and sometimes not. They were useful when we and our customer stopped analysis and documentation before the point of diminishing returns and turned our focus instead to implementing real change and on breaking down barriers to it. They were not useful when our customer was more focused on the perfection of the workflow documentation than on what they could learn from it. (Like, “Whoa, do we really need three different people to perform the same review cycle?” or “Does the author really need a print-perfect PDF proof?”)
As we transitioned to becoming a software solutions provider, workflow analysis was one of the more interesting and challenging areas because we had to actually make those new workflows work in the real world. The timing of this shift for us was accompanied by a shift in perspective by many publishers. Most of our business sponsors no longer have patience (or budget!) for extended analysis projects. They want change, and they are willing to take on some risk to make it happen. Fortunately, what our customers want and what we’ve found really works align nicely.
Bottom line: Most teams come to us already knowing what they want to change about their business processes (at a high level), can list their most obvious inefficiencies, and have no way of knowing about the other ones that lurk until they move to an environment where they can measure them. Sometimes this is because another consultancy has helped them plan, but usually it’s because they are smart people and they know their own processes because they live with them every day. (Sometimes teams don’t know these things, but that points to management and staffing problems and that’s a post for another day…)
Because most of the teams we work with already know, roughly speaking, what they need and want to do, our job is to guide them towards a workflow implementation that reflects their big goals for change (usually being digitally-driven rather than print-driven), works for every day users, is flexible, and provides enough reporting to inform ongoing improvement. And to get it in their hands quickly.
Even though we and our customers are smarter than we were ten years ago, there are still plenty of pitfalls in implementing workflow. This is especially true of a system that enables automation of content transformation, product delivery, and other common publishing tasks. Everyone is looking for the Easy Button.
Here are the best practices we follow when implementing RSuite workflow.
- Keep it simple, keep it loose. Our customers today are mostly willing to forego months of analysis, but they often still want to reflect hundreds of discrete steps in their CMS workflow. Unless you have a legal compliancy concern, this is a waste of effort and will make your team nuts. System workflows with a small number of milestone steps give human beings flexibility in working out the daily details of their jobs and avoid the feeling of a police state. Few publishing processes really follow the documented 500 steps, and often that is for good reason. Don’t hem in your staff with a rigid implementation.
- Automate, but avoid automation dependencies for your workflows. A business process often has several predictable points at which automation is needed (e.g., conversion of a manuscript from Word to XML, generation of author proofs, delivery). It’s tempting to want to plug those steps tightly into your workflow. In the past few years we’ve taken a different approach. We give users tools to run or rerun automations whenever they need to, but don’t have the workflow engine itself initiate the conversion, delivery, and so on. This simplifies (read, cheaper, shorter) workflow implementation and also gives the publisher the opportunity to change a workflow on a one-off basis or permanently with minimal or no configuration changes.
- Don’t forget reporting! During a project it’s easy to get caught up in workflow process implementation and not spend enough time creating truly useful reports. Which leads to…
- Remember that change isn’t a switch you flip. Rolling out your new CMS and workflows is the beginning of change, not the end. Expect that over time you will want to adjust not only the offline details of how you’re working, but also the workflow itself. Create a habit of reviewing reports and looking for bottlenecks and points of frustrations. Make sure you have a staffing plan that enables you to make small changes quickly. This best practice also means you have permission NOT to rationalize all your business processes on day one of CMS launch. Management often has the goal of getting rid of all the unnecessary inconsistencies among teams, and this is a worthy goal. But sometimes it makes sense to step into that level of change incrementally.
We’ve found that following these guidelines results in a system that enables immediate change but with the option for more change when you need it. Not following them can lead to user revolt and management disappointment.
What do you think? What has and hasn’t worked for you when implementing business process changes?
RSI Content Solutions, a leading content management software provider, was recognized by Philadelphia SmartCEO magazine as a winner of the 2014 Philadelphia Future 50 Award. The Future 50 Awards program recognizes 50 of the area’s fastest-growing companies based on employee and revenue growth over the past 3 years. The 2014 Future 50 winners collectively generate $3.2 billion in annual revenue and employ 10,412 individuals in the Greater Philadelphia area.
The Future 50 Awards program, now in its 4th year of celebration in Philadelphia, kicked off with an application process in September 2013. More than 700 local business executives and guests attended a gala on January 16th, 2014 at the Drexelbrook to celebrate the winners and their achievements.
Read the full press release here.
David Saracco, VP of Business Development at RSI Content Solutions, will be speaking at The Challenges of Digital Online Publishing Management Seminar on January 15 from 11 AM to 12:30 PM E.D.T. The seminar will take place at the SUNY Global Center for Graduate and Executive Education, located at 116 East 55th Street in New York.
The purpose of this management seminar is to provide an overview of the rapidly developing technologies and new businesses for digital and online publishing for a delegation of Chinese publishers. It will present a review of recent developments that are taking place and how they will impact the publishing or information industry in the areas of editing entering data, storage and retrieval of information as new forms of the publishing business. The functions of searching, data storage and data mining, bookmarking, tagging, blogs, websites, social networks, and new business models will be presented as an intense management overview.
Click here to read the entire press release.
In the coming months, I’ll periodically be writing a bit about the design of RSuite 4. It has been very exciting to see the effort and thought we put in to the user experience translating into a much improved experience for our users.
RSuite 4: Unnaturally Natural By Design
Many of our new customers starting out with RSuite 4 may not be aware of the effort required to put together such a natural design. It’s easy to forget that thousands of hours of thought, design, and refinement by many people are usually behind those interfaces that seem so effortless. Starting now and for several months I will be periodically posting this series of behind-the-scenes discussion of RSuite 4. Along the way you will have the opportunity to get a taste of some of the major challenges and opportunities when designing software user interfaces.
Indirect Action Traps Unsuspecting Users
Traditional content and asset management users might click on an image then scoot up to a toolbar or some menu to conduct an action. You might find the preview button on the toolbar. Click it and the selected image is previewed for you.
This works fine if users operate with a clear understanding of what item they have selected as well as an action’s area of effect. Accidentally clicking the mouse or forgetting about a change of selection and users may find they've acted on the wrong item. With each mistake an inexperienced user’s confidence is eroded, often snowballing into more errors. Not only are inexperienced users struggling to get their work done, now they have to undo their mistakes. If they can find them...
Look at the RSuite 3 screenshot. The selected item is clearly identified with the orange highlighting. Bump the scroller on your mouse, however, and that orange item can slide out of view. The toolbar, though, remains visible and is still ready to act on the now-unseen item. If you are sure that the now-hidden item you want to act on is still selected then you can click the toolbar. Most users lack this surety and instead have to scroll around until they can double-check that the right item is still selected.
After observing many types of users repeat such behaviors in a wide range of software applications, I suspect that users have become resigned to these error-prone designs. They aren't aware that this checking and double-checking is time consuming and directly impeding their ability to get work done.
Context Menus: A Step In The Right Direction
In the mid-90s mainstream computer software adopted context menus, menus accessed by right-clicking an item and selecting an action to take from a flat list of menu items. Context menus had the advantage of providing users a direct action interface. Right click an item and a list of actions relevant to that item are displayed. It was definitely a step in the right direction. Web applications like RSuite 3 typically offer context menus.
Context menus were great for users who figured out how to right-click something provided the action you wanted to take was present in the menu that appeared. But the flat menu design of context menus generally lacks the density of functionality of buttons on a toolbar. So the compromise of context menus is that some subset of available actions appear in the context menu.
A Context Menu or Scavanger Hunt
Most interfaces ended up with many actions available only in the toolbar or some traditional menu structure. It is common to also find a few actions that are only available in the context menu. There also might be additional menus hiding somewhere with the action we need. Inexperienced users struggle to memorize the interface or become a highly practiced scavenger hunters as they try to get their work done.
A careful UI designer will go to great lengths to design some logic into the interface to explain why some actions are in toolbars, others menus and still other in context menus. Unfortunately understanding the design logic usually requires a solid understanding of the application. So users who could be greatly helped if they could more easily act within the application lack the level of understanding of the software needed to interpret the design logic.
Extensibility Is A Design Challenge
RSuite’s renowned extensibility usually requires integrators find places to extend the UI in order to interact with the user. Should I put a new button in the toolbar? In the context menu? Add to some existing menu? Or look somewhere else? Or maybe put it everywhere? Instead of focusing on the actual business goals, most traditional UI designs bog integrators down in decision-making, UI coding activities and design tasks that are not productive or efficient uses of their time.
In spite of an integrator’s best intention and effort, traditional integration projects can end up producing customized applications that feel more like trying to land a 1974 jumbo jet for the first time rather than doing my actual job. While it is easy to blame the integration team, sometimes you might find that traditional software design and integration points are complicit in the ineffective result.
RSuite 4: Consistent, Direct, Logical
RSuite 4 uses a direct action-based interface revealed by left-clicking on an item. Long toolbars filled with inscrutable icons are no longer present. Traditional menus are reserved for a few special cases. If a user wants to know what actions are available on any item in RSuite 4, just click it. Every available action for the item they click on is displayed clearly in an action menu.
Want to act on an image? Click it. A menu with icons and text clearly communicate all of the actions you can take. This simple approach means that no experience is necessary to discover what actions are available. Over time, as your implementation changes, users only have to understand the changes to the business-specific actions available. The UI remans consistent.
Would You Like To Know More?
With RSuite 4 we have worked hard to remove barriers that are still far too common in business applications. If your interested in seeing more check out our online video tour or visit our website to contact us for a demonstration.
RSuite CMS, the leading multi-channel Content Management System for the publishing and media industry, has been selected by HarperCollins Publishers and HarperCollins Christian Publishing as their workflow and content management system. HarperCollins is one of the world’s leading English-language publishers known for being a broad-based publisher with strengths in literary and commercial fiction, business books, children’s books, cookbooks, narrative nonfiction, mystery, romance, reference, pop culture, design, health, wellness, and religious and spiritual books.
HarperCollins needed a robust software system that can manage each aspect of their publishing process. RSuite CMS will configure the system to meet HarperCollins’s specific requirements such as their workflow and content development needs.
“HarperCollins had a business requirement for a cross-functional collaborative workflow platform to manage the publishing process,” stated David Saracco, Vice President, Business Development, RSuite CMS. “The trade book market is quickly evolving, and HarperCollins required a content management solution to better manage products across all platforms – both print and digital.”
RSuite CMS, a content management system for publishers, is now powered by MarkLogic 7, the industry’s leading Enterprise NoSQL database. RSuite CMS 4 provides an entirely new user experience through an intuitive user interface that minimizes actions required to execute complex searches across an entire set of content, globally apply metadata, dynamically organize content into collections, package and distribute content to licensing partners, and much more.
“RSuite and MarkLogic have had a wonderful partnership over the past seven years,” stated Christopher Hill, vice president, product management at RSI Content Solutions. “While MarkLogic provides the foundation, the RSuite toolset adds a robust set of capabilities that publishers can leverage to meet their multi-channel publishing goals.”
To read the entire press release, click here.
RSI Content Solutions, a content management solutions provider to the publishing industry, is pleased to announce that it has been named to the 2013 EContent 100 list of companies that matter most in the digital content industry for the third year in a row. Selection of the companies for the EContent 100 list falls to a team of judges including editors from Information Today, Inc., EContent magazine contributing editors, and other industry experts. Additional companies on the list include Amazon, Apple, Facebook, Google, LinkedIn, O'Reilly Media, and others.
“In 2013, our task was to narrow down the ever expanding list of important players in the digital content industry to a mere 100 companies that matter most, a task that is becoming harder every year,” said Theresa Cramer, editor of EContent. “Consequently, the companies that do make up our list can be sure that they are in good company—and that next year, there will be a new crop of companies biting at their heels. This is great for the industry, and exciting for those of us who cover the space.”
Continue reading the press release here.