Remember when everyone was shouting ‘XML workflow! You need an XML workflow!’ The publishers nodded, agreed, checked to see if they could buy one on Amazon then asked what exactly was meant by XML workflow. Those who were asked were usually trying to sell something so the answer was never really clear but the publishers were assured that they really needed it and the service that was being sold to them for a bajillion dollars totally had it – oh, and it was based in the cloud.
Feeling a bit frightened by that bajillion dollars and not feeling at all enlightened on XML workflows the poor publishers went back to their publishing houses and used the tried, tested and not-bajillion-dollars-worth-of-software-requiring workflows.
Then everyone was shouting, ‘publishers are stuck in out-dated business practices. They aren’t changing fast enough! Only the versatile will survive!’ (My voice may have been a whisper among those shouts but let’s move on shall we.)
The poor publishers sighed, checked their purses and wondered if there was a way to be versatile without becoming insolvent.+
An XML workflow would certainly help versatility and is something that publishers should be trying to implement but it really requires everyone in the company to sit down and discuss exactly what that workflow will look like.
The idea of an XML workflow, for books and ebooks, is that a central ‘file’ (it could be more than one file) be created that will be the base for all formats of that book. This ‘file’ will not only be the content of the book but will also contain all the metadata and information relating to it. This file will be marked up in a way that could represent any media application (like a website). The idea would be that the language used to mark up the file could be used across the board with all books and would be fine-tuned so that minimal editing would be required on any given format - On a side note: anyone who has worked with conversions will know that fine tuning will be a long process in itself.
Once this source file is created information could be pulled from it to create the PDF for printing, the epub or mobi files for eBooks (with metadata embedded), or parts of the contents could be drawn out to be used in a variety of multimedia.
Now that all sounds fine and dandy but first and foremost there needs to be a lot of communication about what is actually needed in that file; endorsements, metadata, keywords, covers, author bios, links to related titles/information or anything else that may be useful in increasing returns on the work. Secondly there will need to be someone with the skills to create and manage the file and the rest of the staff would need to have some similar, though not quite as detailed, understanding. The storage systems would also have to be completely streamlined (preferably in the cloud) so files could be linked easily and outsourced contributors could be involved right at the core.
All this can be done in-house but a publisher would need to have pretty technically savvy employees. Or this could be outsourced to one of those companies claiming the bajillions for their services. Either way there is going to be an investment with quite a high risk factor.
I guess what I’m trying to get at is yes versatility is all fine and dandy, with its XML workflows and cloud computing* but the reality is the majority of publishers do not have the resources to make such a big leap.
So, maybe small steps are what we should be looking at. Perhaps publishers should first gain a secure understanding of what it is they are actually trying to achieve and then map how they might get there.
It might be worth starting off with a single project, maybe set it up on a temporary online platform like GoogleDocs or Dropbox just to get a feel of how a cloud based XML workflow would work.
Taking it slow can seem very frightening in an industry that is changing so fast – but publishers have to be sure they are taking the right path for them, so maybe slow isn't so bad, as long as it isn't stationary.
Feeling a bit frightened by that bajillion dollars and not feeling at all enlightened on XML workflows the poor publishers went back to their publishing houses and used the tried, tested and not-bajillion-dollars-worth-of-software-requiring workflows.
Then everyone was shouting, ‘publishers are stuck in out-dated business practices. They aren’t changing fast enough! Only the versatile will survive!’ (My voice may have been a whisper among those shouts but let’s move on shall we.)
The poor publishers sighed, checked their purses and wondered if there was a way to be versatile without becoming insolvent.+
An XML workflow would certainly help versatility and is something that publishers should be trying to implement but it really requires everyone in the company to sit down and discuss exactly what that workflow will look like.
The idea of an XML workflow, for books and ebooks, is that a central ‘file’ (it could be more than one file) be created that will be the base for all formats of that book. This ‘file’ will not only be the content of the book but will also contain all the metadata and information relating to it. This file will be marked up in a way that could represent any media application (like a website). The idea would be that the language used to mark up the file could be used across the board with all books and would be fine-tuned so that minimal editing would be required on any given format - On a side note: anyone who has worked with conversions will know that fine tuning will be a long process in itself.
Once this source file is created information could be pulled from it to create the PDF for printing, the epub or mobi files for eBooks (with metadata embedded), or parts of the contents could be drawn out to be used in a variety of multimedia.
Now that all sounds fine and dandy but first and foremost there needs to be a lot of communication about what is actually needed in that file; endorsements, metadata, keywords, covers, author bios, links to related titles/information or anything else that may be useful in increasing returns on the work. Secondly there will need to be someone with the skills to create and manage the file and the rest of the staff would need to have some similar, though not quite as detailed, understanding. The storage systems would also have to be completely streamlined (preferably in the cloud) so files could be linked easily and outsourced contributors could be involved right at the core.
All this can be done in-house but a publisher would need to have pretty technically savvy employees. Or this could be outsourced to one of those companies claiming the bajillions for their services. Either way there is going to be an investment with quite a high risk factor.
I guess what I’m trying to get at is yes versatility is all fine and dandy, with its XML workflows and cloud computing* but the reality is the majority of publishers do not have the resources to make such a big leap.
So, maybe small steps are what we should be looking at. Perhaps publishers should first gain a secure understanding of what it is they are actually trying to achieve and then map how they might get there.
It might be worth starting off with a single project, maybe set it up on a temporary online platform like GoogleDocs or Dropbox just to get a feel of how a cloud based XML workflow would work.
Taking it slow can seem very frightening in an industry that is changing so fast – but publishers have to be sure they are taking the right path for them, so maybe slow isn't so bad, as long as it isn't stationary.
0 comments:
Post a Comment