Caption
As publishers realize that using a Content Management System (CMS) is not just good organizational practice, but increasingly indispensable to remain robust and competitive, an increasingly common question to consider is what sort of CMS to acquire. While it might be tempting to simply use free services like Dropbox or Google Drive, I’ve found that there are three reasons why a more specialized system that is specifically designed for publishing makes a lot more sense.
While it is a truism that every book is unique, this doesn’t mean that certain trends tend to repeat. Recognizing that most books are split into chapters with different teams working on art, editorial, design, proofreading, etc., a CMS built for publishing automatically creates a comprehensive folder structure for each book. A sample screenshot from PageMajik is provided as an example:
For a production team where art, editorial, design, and proofreading are handled by different people or at different stages, distinct folders are provided to store their files.
While it certainly is convenient to not have different teams constantly ensuring that they know which files are theirs and having to adopt intricate naming conventions, the folder structure enforces version throughout by making it possible to store each version of every file, as well as detailed metadata on each of those files. The presence of older versions lets users open any previous version to compare and contrast newer ones, and if the latest version proves unsatisfactory, a previous one can be reverted to.
As figure 1 shows, the metadata associated with each file that can be stored includes who created and updated it, when it was updated, and how many previous versions of that file are stored. This bird’s eye view of all content lets you monitor, search, and retrieve any information required, granting unprecedented control over the publishing process.
Your CMS doesn’t necessarily have to be a cluttered space where everyone has access to every file. You can specify instructions in advance regarding who is allowed to access what, letting you tailor the system to your particular needs. This doesn’t just keep files safe, it also removes the need to remember onerous instructions about who you should inform when you finish your work on the file or who to send your file to. Now the pre-set instructions will ensure that everything that has to be done at a certain stage is completed, and that once all the tasks are finished and signed-off on, the system will automatically trigger the next stage of production and everyone with permissions will be informed about this change.
This minimizes errors by not having to depend on just human supervision to ensure all the work gets done. In addition, it simply makes it more convenient for everyone involved, because they can focus on their work without having to deal with the hassles of the larger process itself.
Publishers I’ve talked to are often skeptical about workflows because they think their working arrangements are far too complicated to be capturable. Luckily, modern workflow creation tools are usually up to the challenge, while remaining intuitive to use. Figure 3 is a workflow PageMajik recently created for a client, and it showcases the flexibility the system allows.
As for those publishers who don’t have clearly specifiable rules about work, the CMS can still be used with open-ended workflows, letting them make use of the benefits of the system anyway.
Finally, a workflow doesn’t just have to necessarily be applicable to the entire publishing process; users can also choose to create workflows for specific teams in as fine-grained ways as they wish. This way, you get as much control as you want.
While book folders and workflows help tap into the full potential of the resources publishers already have, a severely underappreciated benefit of a CMS specifically built for publishing is its scalability or ability to support growth. A small publisher might very well make do with Dropbox and informal conventions when only a handful of people are working. It is quite clear that such a model cannot be used as the organization grows. There will soon be a need for separate repositories, ways to keep different stages of production distinct, and concerns about version control.
So even if some of the issues mentioned above don’t apply right away, any publisher who has ambitions for growth necessarily needs to look into a CMS that has been specifically built for the industry. And the sooner this is done, the less trouble it will be to adopt a new system, transfer all the files, and train content producers and production teams.
So what are you waiting for?
