1. XML – more trouble than it’s worth? Andy Williams University Press Conference 17 th March 2016

2. Of course you should do XML…  If cost no object! For elegance, future preservation and re-use  Book sales are tough, revenue per title down, digital revenue/sales not replacing print directly  Migrating to digital but print still important and needed for books  Need to deliver in many formats, but no increase in revenue, just potential increase in costs  Need to spend wisely and ensure that the items funded have a positive benefit (either immediate financial, or long term profile)  Need to balance investment now against long term opportunities and future proofing  People keep telling you that you should be doing it differently…

3. Scope  Business case  Building it as a process  Upsides  Downsides  University Press extra wrinkles  Journals versus books  Implementation impacts to consider for the business case  Workflow  Organisational impacts  Project management  Systems

4. Business case process What benefits looked for? Possible solutionWhat will it cost Am I happy of balance benefits vs costs NO Reconsider, must haves, nice to have, revisit solution Work out detail YES Review: have we maximized the potential? Ongoing review

5. Drivers – why do it  Better products … Sell more, increased revenue, attract more authors, attract more users (discoverability)  Better processes (now) … Cheaper, faster, better (quality), cost avoidance (COPQ)  Better future … Easier re-use, future proofing, preservation

6. XML providing the potential  Better products – richer content  Crossref and DOIs (external hyperlinking)  Final products (epub, epdf eBooks); internal hyperlinking  Indexes, internal hyperlinking  Semantic tagging  Maximises delivery platform functionality  Better process – cost avoidance  Benefits in the workflow, regardless of final outputs  Standardised tools, workflow  QA automation (COPQ)  Speed to market  Onix bibliographic data  Better future  Standards – easier for integration, easier to cope with change  Ease of transfer and migration  For future preservation and re-use

7. Drivers – why do it  Better products  Crossref and DOIs (external hyperlinking)  Final products (epub, epdf eBooks); internal hyperlinking  Indexes, internal hyperlinking  Semantic tagging  Maximises delivery platform functionality  Better process  Benefits in the workflow, regardless of final outputs; speed  Standardised tools, workflow  QA automation  Speed to market  Onix bibliographic data  Better future  Standards – easier for integration  Ease of transfer and migration  For future preservation and re-use

8. Constraints – why not?  Costs:  Direct (typesetters etc)  Infrastructure and maintenance  Disruption  Author impacts; content variability  Inflexibility; supplier choice  Lack of skills required in house  Supplier impacts: copy editors, existing typesetters  Accounting – title level costings/GM may not change, pay back from elsewhere?  Usage – PDF downloads vs HTML … still favours PDF “ researchers said that they like the PDF and use it to ‘ consume’ an article – to engage with it, scrawl all over it etc”

9. Constraints – why not?  Typesetter direct costs Book workflows/outputs Workflow delivering print PDF only 88% Workflow delivering standard product files = print PDF, EPDF and epub 2.1 (minimal linking) 100% Workflow delivering print PDF, EPDF, epub plus XML (rich linking) 120% Journal workflows/outputs Workflow delivering print PDF only 92% Workflow delivering standard files = print PDF and HTML 100% Workflow delivering print PDF, HTML plus XML 108%

10. Affordability (how to cheat)  Depends on your starting point…

11. University Press specific bumps  Size of output and hence volumes for buying power and amortisation of costs  Onshore setting  Onshore freelance copy editors  DAMS patchy… QA potential?  HSS content  Speed

12. Journals versus books  How many workflows? Are journals different from books… “In the realm of technical production, there are differences between monographs and journals, but these are predominantly now the result of legacy systems. There is no reason why books should not feature the same XML- first workflow that is widely used in journal production. After all, the technology behaves in the same way when dealing with 8,000 words or 80,000 words” Martin Paul Eve, 2014 … a book is not a journal, a chapter is not an article Journals … ‘just do it’

13. Journals facilitators  Standardised inputs; standardised outputs  Consistent and repeating structure to articles, written to style  Industry standard delivery platform requirements  Key areas to code, authors, title, abstract and references – could limit to these/metadata  JATS DTD emerging as a default… humanities?  “Most” suppliers probably have standard workflow for other customers; not a new build  Digital revenue potentially greater now than print revenue

14. Journals scenario  Define minimum coding requirements for platforms used (authors, title, abstract and references)  Offshore coding and typesetting  Potentially offshore copy editing  Tagging at/just after copy editing  Validate DTD (JATS?)  Piggy back on supplier existing workflows

15. Journals drivers – why do it   DOIs article submission and references resolution (external hyperlinking)   Full suite of final products (PDF for print; ePDF; HTML); (internal hyperlinking); speed of final files/upload   Potential for semantic tagging (hence greater discoverability)   Delivery platforms requirements met, maximised functionality   Ease of transfer and migration; digital preservation   QA automation

16. Books – more to think about  Chapters of a book have relationships to other chapters (bibliographic references; indexes; cross references)  Greater variation of input  Less control of authors and styles (e.g. references!)  HSS less standardised authoring vs STM  Epdf and epub as formats generally work as deliverables; platform requirements less defined  Print still essential (at least for HSS)

17. Mapping out the journey Q1 2016 Q2 2016 Q3 2016 Q4 2016 Technical specification Organisation Systems & business integration Job descriptions Identify systems implications Current capability, DAMS? QA? Receipt? Tracking? Requirements assessment Documentation Project & change management Implemented XML workflow – benefits realised Workflow specification Content and delivery requirements Check supplier capability Common DTD or separate Requirements for rules based checking DTD for books Confirm QA processes Define how to manage business as usual Governance Single or many suppliers? Business case; P&L; budgets Define expectations and success criteria Roll back plan Create coding instructions DTD for journals Align DTD with designs; check content Workflow Run tests on processes Check XML conforms to end requirements Run RFP Supplier selection Set up change protocols System selection as required System implementation or modification Run systems tests Run tests on deliverables Discuss with suppliers Supplier contracts Coding rules, supplier instructions DTD Business case In house impacts? Staff & skill sets Freelancer impacts? New roles (QA?) if required – recruit/train Author comms Create roll out plan Editor comms Training Transition: legacy BAU/new workflow Retire legacy systems? Define high level requirements Review options Define preferred workflow Confirm stakeholders; set up project team Staff comms Supplier/freelancer comms QA rules Design spex

18. Implementation considerations  Where in the workflow (xml first, middle or end?)  Technical choices (which DTD etc)  Organisational impacts  Project management  Systems  Development approach, who owns and controls the process?  publisher predicates and controls  subcontract out to supplier, specify deliverables  subcontract out to supplier, supplier defined deliverables  collective boilerplate

19. Where in the workflow? Author creates Before copy editing During copy editing Post copy editing During page make up At final file delivery Post processing (Never)

20. Where in the workflow? Before copy editing Pre-edit for copy editors Standardised files for copy editors Standardised tools and processing Potentially supplier independent Early identification of issues, rules based checking Metadata workflow and systems integration Annoyed authors, delays, confusing Potential complexity for copy editors Changes and rewrites Perfect/finished input Imperfect initial hyperlinking

21. Where in the workflow? Author creates Before copy editing During copy editing Post copy editing During page make up At final file delivery Post processing Logical Automation of checks Possibly being done by suppliers already Skills sets? Tagging vs grammar Costs Resistance ‘traditional’ copy editors Tools required, configuration management Author changes and approval

22. Where in the workflow? Author creates Before copy editing During copy editing Post copy editing During page make up At final file delivery Post processing “Not my problem” Appropriate skill sets Implicit in the process Hyperlinking – when to check? Complexity implementing publisher DTD Change management Cost Can you actually tell?

23. Where in the workflow? Author creates Before copy editing During copy editing Post copy editing During page make up At final file delivery Post processing Gives you XML May be relatively cheap (less infrastructure overhead) Quality of XML vs DTD Difficulty for supplier to convert Time delays No advantages of QA during the process What additional QA required beyond usual final file checks How to fix errors identified and issues

24. Where in the workflow? Author creates Before copy editing During copy editing Post copy editing During page make up At final file delivery Post processing Only code what you need as XML, on finished version Insert single point of control – consistency of XML Include with other processing requirements Only subset of content as rich XML Time delay No advantages of QA during the process What additional QA required beyond usual final file checks How to fix errors identified and issues, some product already published!

25. Where in the workflow? Author creates Before copy editing During copy editing Post copy editing During page make up At final file delivery Post processing (Never) Least Cost Most Least Functionality Most

26. Implementation considerations  Where in the workflow (xml first, middle or end?)  Technical choices (which DTD etc)  Organisational impacts  Project management  Systems  Development approach, who owns and controls the process?  publisher predicates and controls  subcontract out to supplier, specify deliverables  subcontract out to supplier, supplier defined deliverables  collective boilerplate

27. Organisational impacts Q1 2016 Q2 2016 Q3 2016 Q4 2016 Technical specification Organisation Systems & business integration Job descriptions Identify systems implications Current capability, DAMS? QA? Receipt? Tracking? Requirements assessment Documentation Project & change management Implemented XML workflow – benefits realised Workflow specification Content and delivery requirements Check supplier capability Common DTD or separate Requirements for rules based checking DTD for books Confirm QA processes Define how to manage business as usual Governance Single or many suppliers? Business case; P&L; budgets Define expectations and success criteria Roll back plan Create coding instructions DTD for journals Align DTD with designs; check content Workflow Run tests on processes Check XML conforms to end requirements Run RFP Supplier selection Set up change protocols System selection as required System implementation or modification Run systems tests Run tests on deliverables Discuss with suppliers Supplier contracts Coding rules, supplier instructions DTD Business case In house impacts? Staff & skill sets Freelancer impacts? New roles (QA?) if required – recruit/train Author comms Create roll out plan Editor comms Training Transition: legacy BAU/new workflow Retire legacy systems? Define high level requirements Review options Define preferred workflow Confirm stakeholders; set up project team Staff comms Supplier/freelancer comms QA rules Design spex

28. Project management Q1 2016 Q2 2016 Q3 2016 Q4 2016 Technical specification Organisation Systems & business integration Job descriptions Identify systems implications Current capability, DAMS? QA? Receipt? Tracking? Requirements assessment Documentation Project & change management Implemented XML workflow – benefits realised Workflow specification Content and delivery requirements Check supplier capability Common DTD or separate Requirements for rules based checking DTD for books Confirm QA processes Define how to manage business as usual Governance Single or many suppliers? Business case; P&L; budgets Define expectations and success criteria Roll back plan Create coding instructions DTD for journals Align DTD with designs; check content Workflow Run tests on processes Check XML conforms to end requirements Run RFP Supplier selection Set up change protocols System selection as required System implementation or modification Run systems tests Run tests on deliverables Discuss with suppliers Supplier contracts Coding rules, supplier instructions DTD Business case In house impacts? Staff & skill sets Freelancer impacts? New roles (QA?) if required – recruit/train Author comms Create roll out plan Editor comms Training Transition: legacy BAU/new workflow Retire legacy systems? Define high level requirements Review options Define preferred workflow Confirm stakeholders; set up project team Staff comms Supplier/freelancer comms QA rules Design spex

29. Project management  Development approach, who owns and controls the process?  publisher predicates and controls  subcontract out to supplier, specify deliverables  subcontract out to supplier, supplier defined deliverables  collective boilerplate solution (establish common standard requirements and operating procedures)  Roll out…  big bang, gentle migration  how to handle business as usual plus extra new work

30. Systems Q1 2016 Q2 2016 Q3 2016 Q4 2016 Technical specification Organisation Systems & business integration Job descriptions Identify systems implications Current capability, DAMS? QA? Receipt? Tracking? Requirements assessment Documentation Project & change management Implemented XML workflow – benefits realised Workflow specification Content and delivery requirements Check supplier capability Common DTD or separate Requirements for rules based checking DTD for books Confirm QA processes Define how to manage business as usual Governance Single or many suppliers? Business case; P&L; budgets Define expectations and success criteria Roll back plan Create coding instructions DTD for journals Align DTD with designs; check content Workflow Run tests on processes Check XML conforms to end requirements Run RFP Supplier selection Set up change protocols System selection as required System implementation or modification Run systems tests Run tests on deliverables Discuss with suppliers Supplier contracts Coding rules, supplier instructions DTD Business case In house impacts? Staff & skill sets Freelancer impacts? New roles (QA?) if required – recruit/train Author comms Create roll out plan Editor comms Training Transition: legacy BAU/new workflow Retire legacy systems? Define high level requirements Review options Define preferred workflow Confirm stakeholders; set up project team Staff comms Supplier/freelancer comms QA rules Design spex

31. Sales – revenue opportunities HR – communication; roles Production – workflow; process; suppliers Editorial – content drivers Technology -- systems Marketing – discoverability; profile Decision?

32. XML – not more trouble than it’s worth  Timing/resources  Is this the best way to spend your money and effort, now?  Are there other short term improvements to focus the team on first?  Metadata accuracy and distribution  Minimizing stock risk for legacy print; warehousing costs  Eyes open; clear expectations; engage everyone  Understand the consequences (suppliers, systems etc)  Define your minimum success criteria; how will you know when you’ve reached your initial goal; how long?  Not a solution looking for a problem, define the problem

33. Andy Williams andyw@ourous.co.uk