Consonance

PAAG charter signatory

2025-12-26T00:00:00+00:00

We are proud to finish 2025 by signing up to the Publishing Accessibility Action Group charter. Long admirers of the work of PAAG, we have held off from actually signing the charter because we didn’t want only to be a passive bystander to their great work. We wanted to know in our hearts that we’d taken real action. So here is what we’ve done and will continue to do to earn our place on the PAAG list.

This was also published in the 2025 PAAG annual report.

What are your accessibility highlights of the past 12 months?

Over the past year, we’ve focused on making Consonance easier and more inclusive for everyone to use, and we’re proud of the progress we’ve made. We strengthened screen-reader support, improved keyboard-only navigation, and introduced dark mode and the Atkinson Hyperlegible typeface to enhance readability and reduce eye strain.

We also invested in the foundations of long-term accessibility by strengthening our in-house expertise through accessibility training accredited by the International Association of Accessibility Professionals (IAAP), adding automated Playwright accessibility tests to our development workflow, and expanding manual testing with feedback from people with lived experience of disability.

We continue to help our clients get the most out of their ebooks by automatically pulling accessibility metadata from their EPUBs and generating accessible tables of contents to include in their ONIX feeds. Our clients are still responsible for producing accessible files, but once that work is done, we make sure the accessibility information gets in front of the right people.

Across the company, we set WCAG 2.1 Level AA as our baseline and continued moving towards Level AAA where feasible. We also updated our marketing website, user documentation, and training materials to meet WCAG standards, ensuring a more consistent and accessible experience across both our product and our public-facing content.

What are you working towards in terms of accessibility in the coming year?

In the year ahead, we want accessibility to feel even more embedded in how Consonance is designed, built and used. We’ll be working more closely with publishers and accessibility groups, continuing to improve keyboard and screen-reader experiences, and raising our standards as we move towards higher levels of WCAG compliance across our product and website.

Here is a YouTube video that talks about our automated Playwright accessibility testing.

Livestreams

2025-06-04T00:00:00+00:00

We do a Thursday livestream! Each week, or thereabouts, at 2pm UK time, we take about an hour to look at:

Task of the week - a publishing task that we think is useful to take a look at
Reporting spotlight - Consonance has a powerful reporting engine, called Data Studio, and in this segment we work through a real-life publishing problem to see how to solve it using Consonance.
From our own correspondence! - we pick a recent customer query, and anonymously share the problem, and solution, with everyone.
What’s new - a look at new or improved features and other hot topics.

Please like and subscribe to our channel, and bookmark this page too, so you know what’s available.

You can see the full, and growing, playlist on YouTube (alongside other playlists such as our Thoughtful Little Innovations list, and our world-renowned (!) Christmas ads.)

Any requests for what we should cover? Email them to support@consonance.app

2025 Spring release

2025-04-09T00:00:00+00:00

Whilst we tend to release little and often, Spring 2025 brings a major upgrade to Consonance. Read on to discover the new reporting and accessibility features it brings.

TL;DR

Consonance pages have had an accessibility boost: a new, legible font that improves readability; wider layout; keyboard shortcuts; more relevant language choices; more detailed breadcrumbs.
Taking advantage of the wider layout, Consonance now includes various analysis pages: sales at company / series / work / product / channel / format levels; royalties at work level; top tens by series, author and overall.
Search results also benefit from the wider layout, and, coupled with our flexible new search within searches, is officially launched out of beta as the powerful Reporting feature of Consonance.
We are harnessing more of the power of the web platform for this release.

What?

We have moved the menu to the top bar to free up the left hand of the page from fixed navigation. We’ve added keyboard accessible shortcuts, a page finder, starred menu options and better wording, plus all links visible at once so you don’t have to click to expand, or scroll:

The new navigation menu, featuring starred options, a page finder, and keyboard shortcuts.

Pressing Ctrl reveals keyboard shortcuts, for quick access:

Keyboard shortcuts to access pages in Consonance.

The page finder comes with a thesaurus, so even if you use a different word, chances are it’ll find where you want to go:

Using the page finder to look for “p&l” brings back “Plans”, which is where to do P&L analyses in Consonance.

Enhanced data insights

We’ve taken advantage of the new amount of horizontal space to also ship analyses pages.

If you currently use Consonance for royalties, then the sales analysis is already available. Even if you don’t, this additional insight into your sales might make it worth uploading them, particularly as we will later be adding new analysis based on subject codes, audiences, work types, and other metadata that can be hard to extract to external systems.

An example sales analysis page. There are analyses at client, series, and work level, and for royalties.

Enhanced accessibility

We have made accessibility improvements core to this release. Accessibility can mean a lot of things: we have considered navigation flow; data flow, both into and out of Consonance; semantic HTML markup, CSS styling, and Javascript behaviour; and how you experience pages in Consonance. Whilst we would say that achieving accessibility is a lifetime’s work, and we’re not there yet, here are some of the steps along the road that this release brings:

Finding pages and moving around the system

Keyboard shortcuts.
Semantic breadcrumbs on every screen, and structured in more depth.
Running headers contain exploratory links e.g. on a work that belongs to a series, the link goes to a new Series analysis page.
The work overview page contain Explore buttons, to set up a new report from a useful starting point.
New link to recently visited works on the top nav.

Getting data in and out

More copy to clipboards e.g. on the new analyses pages and on the work overview page.
A new ONIX dashboard at the work level.
Analysis pages, to bring data together from around the system, revealing actionable insights.

Reading pages

Playwright tests confirm whether our HTML contains semantically-correct, accessible markup. Automated tests like this mean we can maintain and update accessible pages without fear of regressions.
Minimise having to scroll tables to the right.
Maximise the amount of space available to see and interact with your data.
A new font, Atkinson Hyperlegible Next, designed to be legible, to improve readability.

Accessing pages

Less visual clutter.
Correct contrast colours.
Tighter, standardised whitespace.
There is an extra 230px / 460px of horizontal room on each page to see more information. Search results and tables in particular are less pokey.
We use the built-in features of the web platform as much as possible, avoiding libraries and bloat to keep the software maintainable and fast.
We don’t layer on after-the-fact accessibility fixes, so you will not find janky overlays with Consonance.
New navigation draws your attention to some features that you might have missed, such as Seasons, P&Ls and project management tools, to help you get the most value out of your Consonance investment.
At the same time, we have added starred links, and no longer have all navigation options visually present on all pages (on the sidebars), so you can visually limit the overwhelm of seeing all the parts of Consonance that you are not currently using.

Understanding pages

More inline help documentation.
Language. We use the words you have actually been using when you communicate with us, e.g.:
- Legal has become Contracts, and Rights
- Search has become Reporting (update, 2026: and now launched with a fuller feature-set, as Data Studio.)
- Finance has become Royalties
- Workflow has become Project management
- Contacts has become Address book.

Retirements

As search (Reporting) is now out of beta, the old advanced search / batch actions on the products page has been retired. We have also retired flip tables on the metadata page because the design refresh fits a lot more onto the page, so this complexity is no longer needed.

Why?

It all started with Search.

The Search feature has been in beta for a while, as we add new searches and displays. And as it’s grown, the page has got more and more cramped, until we’re now seeing pages like this. All starting to get pretty busy, and the results are getting cramped and fiddly to scroll through:

The search page. The actual results are crammed into the bottom right hand corner.

So we wanted to find a way to give those results more focus and room. The solution was to free up the third of a page that contained static navigation. Here’s the same search, with the new display. Now, the whole page horizontally can be given to the results.

The same report, with more horizontal space.

And by collapsing the form fields, the results can take up the whole page vertically, too:

The same report, with more horizontal AND vertical space.

You’ll notice some more features in there – the ability to duplicate, and to create a new report from this page, and the use of the word Report to describe a set of search conditions plus their display or action.

How?

This update has been in development since early January 2025 and we previewed these changes to the treasured clients that we met with at the London Book Fair. The unanimous enthusiasm and sense of urgency, particularly around being able to see sales analyses, emboldened us to hasten the launch of this feature forward to Easter 2025.

A note on mobile

We do not officially support (i.e. spend time writing a separate app for) mobile devices: Consonance is a complex, dense B2B app and intended for use on a laptop or desktop, at work. However, if you want to access it on a phone or tablet, Consonance is a website, so you can open it in a browser app, such as Safari. This release requires the very latest version of Safari, that comes with iOS (18.4). Previous iOS / Safari releases have bugs which crash the menu.

Highlights of the spring release on YouTube. (Warning: jingly music plays, and there is no voiceover, so you can mute it and not miss any content.)

Searching in Consonance

2025-04-09T00:00:00+00:00

These searches were not possible until today (April 2025):

Find the paperbacks that do not have an accompanying hardback.
Find the works that are audio only
Find the products with a USD RRP consumer price but no USD RRP library price
Find the contributors who are both editors and authors

Up to now, Consonance’s search feature had focused on flexible ways of finding metadata, such as products, works, or prices, based on the existence of other metadata.

We’re now releasing an enhancement that might seem like a straightforward extension of this, but which expands the search functionality in some very powerful and maybe surprising ways.

Put simply, this new feature allows you to add a filter to a product, work, contributor, etc., based on whether it is, or isn’t, included in the result of other searches that you’ve already defined.

Four kinds of condition are available, all of which accept multiple searches in their condition:

Is in the results of any of these other searches
Is in the results of all of these other searches
Is not in the results of any of these other searches
Is not in the results of all of these other searches

Examples:

Product is in the results of any of ‘USD price over $100’ and ‘CAD price over $110’ and ‘GBP price over £80’.
Products only need to have any of these prices to be returned in the result.
Product is in the results of all of ‘USD price over $100’ and ‘CAD price over $110’ and ‘GBP price over £80’.
Products need to have all of these prices to be returned in the result.
Work is in the results of all of ‘Forthcoming audiobooks’ and ‘Active hardbacks’.
The works in the result will have both a forthcoming audiobook and an active hardback.
Product is not in the results of any of ‘USD price under $100’ and ‘CAD price under $110’ and ‘GBP price under* £80’.
Products will be returned in the result as long as they do not have any of these prices

At a basic level this allows you to save a search that you commonly use, and then refer to it from multiple other searches without needing to modify your original search.

For example you might have a general interest in recently published, active digital products. That condition, on publication date, product form, and publishing status, can be saved as Recently published active digital products, and can now be referenced from other searches if you wanted, for example, to:

list their AUD RRP consumer prices – which requires adding between one and three additional conditions,* depending on the combinations of price types and qualifiers you have
and list their editors – requiring one more condition on contributor role
and list their reviews – requiring a condition on marketing text variant

So that’s an example of being able to refer to another search based on products being present in its result set.

However the new feature goes beyond allowing one search simply to reference another, because it also allows you to reference the results of the other searches.

Let’s work through the examples.

Find the paperbacks that do not have an accompanying hardback.

What we mean by accompanying here is critical – we mean on the same work. (We might more loosely have meant by the same author or in the same series).

So what we’re looking for, reworded, is Find the paperback products on a works that don’t have a hardback product. While works that don’t have a hardback is a difficult search, works that do have a hardback is simple – we use a single condition on the product’s form, and if we listed the works then that would be the result we need.

We can save that search, Hardback products, and reference it from another search to say Works search not in result of ‘Hardback products’ and we have the works that don’t have hardbacks. Adding a new condition on product for gives us the conditions we need, and then we can display the works works with paperback products and no hardback product, the products (paperback products without an accompanying hardback product),

Find the works that are audio only

Finding audio products is straightforward. Finding products that are not audio products is also straightforward.

But what we’re looking for here is: Find audio products that are not on works that have non-audio products.

Search 1: Non-audio products (excluding the audio product forms that you publish)

Search 2: Audio products not on works with non-audio products

Find the products with a USD RRP consumer price but no USD RRP library price

Search 1: USD RRP Library prices. USD RRP prices are always excluding tax, but other currencies might be stored as including tax – both are shown here. Prioces for libraries might be codes with a qualifier of 06 or 10.

Search 2: USD RRP consumer price, product search not in USD RRP Library prices. Consumer prices have a qualifier of 05

Find the contributors who are both editors and authors

Search 1: Author roles. You might additionally consider A32: Contribution by to be authors, so they could be included here.

Search 2: Editor and author. Look out for the multiple editing roles that are supported by ONIX.

That’s the new feature in a nutshell. Although the mechanics of this in the interface are pretty straightforward, these searches can be a big leap conceptually.

If you have trouble working out how to do a complex search, or would like us to verify that you’re on the right track, do email support@consonance.app and we’ll be happy to help.

Project management in Consonance – keep the data near the dates

2025-04-09T00:00:00+00:00

There is no shortage of project management systems available for you to choose.

As a team, we thought long and hard about whether to even bother including workflow and programme management features within Consonance. After all, couldn’t a publisher just use Monday.com, or Basecamp, or a simple spreadsheet to manage their publishing schedule, and keep Consonance focused on bibliographic, production, rights and royalties processes?

But that would deny our customers a really big productivity pay off. They’d put all their publishing dates into the system – all the manuscript delivery dates, the print and reprint dates, the availability and shipping and publication dates – but not be able to use them to figure out what needs to be done, by when.

And all for the want of a publishing scheduling system that joins everything up – that takes dates, and turns them into deadlines.

Here’s an example. This product’s pub date is 4th October 2024:

If I alternatively used generic software like Monday.com, or JIRA, or Basecamp, or a home-baked system like a spreadsheet, I’d have to type that date in somewhere again (or export it, or maintain a system integration). If I relied on email, I would have to trawl through endless 20-deep threads, and hope I got copied in on all the detail. Or… I can use it directly in the same system. Here’s the to-do edit page in Consonance. See that the publication dates are right there, ready to be used as deadlines. (You don’t even need to have put the actual date in yet – this to-do’s due date could be set relative to the MS delivery date, when it’s entered, but its current absence won’t stop you setting up the to-do right now.)

Publication dates immediately there, ready to be used as deadlines. You don’t even need to have put the date in yet.

If we’ve learned anything in all our years as publishers and systems developers, it’s that the pain comes in the joins between systems. So it makes a lot of sense to choose a system that keeps all the important things close together – like pub dates, manuscript delivery dates, and task management.

And that’s why we also have the following workflow features as part of the workflow ecosystem in Consonance:

Roles

If a task is going to get done, someone needs to do it. That someone might be a team member, or an external freelancer. Or you might want responsibility to lie with an organisation. Or your planning might be so far in advance that you only know what role the user, contact, or organisation might have, like “managing editor” or “designer”. In Consonance, you choose from any of these – or leave blank to keep the to-do as a simple checklist item, with no responsibility assigned. Mix and match roles and contacts, for greatest flexibility:

Discussions

Hate scrolling through twenty-message-deep email threads to find the latest decision on which printer should be used for the hardback reprint? Discussions in Consonance keep discursive data close to the more structured metadata so you can find it – now, and again in 18 months. Discussions can be cc’d to your email anyway, but having them in the system is a game-changer for recording the essence, as well as the outcome, of conversations.

Throughout Consonance

To-dos, roles and discussions are discrete headline features, but workflow management pervades throughout Consonance. Dates are used meaningfully, and in context. Consonance exports dates into the iCal format as well as Excel; incorporates dates into ONIX and advance information sheets; shares dates and statuses in contracts, royalty statements and briefing notes.

Use Consonance: publishing’s alternative to Monday.com, JIRA and spreadsheets

The long timescales in publishing, plus the sheer number of tasks required to get a book out of the door, means complexity so great that you do need a tailored tool.

Unlike off the shelf project management tools, Consonance is not generic.

It strikes the right balance between a structured record, being next to all your other data, and with the capacity for free text and ad hoc to dos.

Being close to other data means there’s no extra log in, and no interruptive mental shift for your users.

And consider: retaining what works for your processes is intellectual property, just like rights, just like your content. It needs storing, preserving, and reusing, to maximise its value and to ensure your organisational knowledge does not get lost when a team member leaves.

Taylor & Francis ONIX, by Consonance

2025-03-21T00:00:00+00:00

Consonance.app now manages all of Taylor & Francis ONIX for Books.

A few years ago we were approached by a team from Taylor & Francis Group to work with them on replacing their ONIX for Books solution, then running on a Klopotek instance, with feeds from Consonance.

Architectural background

The proposed architecture involved a custom bi-directional integration between a client product hub (a publisher’s single database accepting and distributing data between multiple dedicated services) and a dedicated Consonance instance, by exchange of JSON messages via Amazon Web Services (AWS) Simple Queueing Service.

The Taylor & Francis product hub consolidates metadata, production, stock and distribution, and other relevant data, and would send SQS messages of around 20kb each to a Consonance service which ingests them into a Consonance system, hosted on Heroku and backed by a PostgreSQL relational database hosted on AWS RDS.

Development

Starting with limited quantities of metadata for print products, we demonstrated a limited functionality proof-of-concept system, and expanded gradually to include all the metadata required for producing ONIX for print products.

Using a lightly modified version of the normal Consonance automatic ONIX scheduling system we started sending production-quality ONIX to a limited set of recipients, gradually expanding the number of recipients.

After adding audio and ebook feeds for some recipients, the teams worked on replacing the existing ONIX feed to Ingram Content Group Coresource, a critical metadata distribution mechanism for Taylor & Francis ebooks.

Consonance also added:

automatic calculation of agency prices in twenty-one currencies, applying Apple iBook logic for new and digital original products.
application of custom discount coding logic.
custom logic for retail, institutional, and library price territoriality in multiple currencies.
incremental application of new pricing rules as annual price changes were rolled out across the catalogue.
application of ebook accessibility and content type coding.

Consonance and Taylor & Francis also worked with Hachette Distribution, establishing the first ONIX feeds into the Hachette UK state-of-the-art Hely Hutchinson Centre (HHC) in Didcot, Oxfordshire.

The team also worked with OCLC to establish their first ONIX 3.0 feed, providing a high-quality and varied basis for their mapping of accessibility and open access metadata.

Results

Data exchange between Taylor & Francis and Consonance runs on a reliable cloud hosted message transfer service, ingesting new and modified metadata into a dedicated cloud hosted Consonance system.

Taylor & Francis staff have access to a conventional Consonance interface, providing a fast, reliable, and intuitive modern interface for their product metadata.

Lightly modified Consonance backend logic automatically sends ONIX on a daily basis to over 100 recipients without manual intervention, most receiving daily updates of multiple files limited to between 750 and 10,000 products depending on recipient.

Consonance maintains a full history of every transmission to every recipient for every product, accessible through the standard interface where ONIX product fragment can be viewed.

Work continues on creating further feeds, and adapting to industry changes such as EAA and GPSR.

As of March 2025, the legacy Klopotek ONIX delivery was completely replaced by Consonance.

Key statistics

Metadata update messages passed per month: 500,000 / 10GB
Products hosted in Consonance: 1.2 million
ONIX files sent per month: 7,500 / 375GB
ONIX product fragments sent per month: 28 million

2024 in review

2025-01-01T00:00:00+00:00

2024 was a busy year! We:

🌟 Managed 1.3 million products.

📎 Sent 85,000 ONIX files on behalf of our clients to 100+ recipients containing 175 million ONIX product updates.

🚀 Supported existing and new clients with their ambitious strategic developments, e.g. Liverpool University Press’ Distributed Press initiative.

⚖️ Supported emerging legislative requirements e.g. GPRS, EUDR.

💰 Funded half a million pounds’ worth of development, from user licence revenue, in our bid to make Consonance.app the best-maintained publishing management system available.

Some of the developments we shipped:

✅ Upgraded all our settings pages: lists of publishers, imprints, in-house subjects, formats and editions, AI templates, briefing templates, catalogue templates, sales channels, discount codes, supplier configs, contract sets, contract templates, and groups management (phew!)

🔄 Upgraded existing features: briefings, pipelines, batches, issue management, series, custom reports, advanced pricing and ONIX management.

🎭 Added automated accessibility testing and visual regression tests, powered by Playwright, to our already robust testing suite.

🔎 Shipped our incredibly powerful new Search, allowing users to join up and report on their data in unprecedentedly powerful ways.

📊 Shipped Plans, our forecasting performance tool.

🏭 Shipped Grids, our bespoke reporting filter.

📨 Shipped Notifications, to make comms with clients available in-app and on email.

🦾 Upgraded core libraries such as React, Rails and their dependencies.

📐 Upgraded to the latest industry standards such as ONIX 3.1.2, and Thema and BISAC upgrades.

✨ Retired legacy code libraries to keep our codebase maintainable and secure.

💖 Welcomed a rich array of new clients to Consonance.

A wonderfully busy year, all in all! Jolly well done to our hard-working team for such fruitful productivity, and thank you to our clients for making our work so meaningful: it is a privilege to support you.

And now we’re back with big expansion plans for 2025. It’s the time to join our roster of progressive, growthful clients, to take advantage of the best publishing management system on the planet, and it’s more achievable to switch than you’d think. Get in touch!

Liverpool University Press

2024-10-15T00:00:00+00:00

We have had the pleasure of working with LUP since 2015 when they migrated to us from a legacy platform with the intention of establishing a solid, organised base from which to strategically grow. Fast-forward to today, and their plan has worked. In that time, LUP have established strategic partnerships with The Littman Library of Jewish Civilization, Voltaire Foundation, Northcote House Publishers, Historic England and more, integrating the lists into their own programme and applying their rigorous processes to publish wider, faster and more successfully.

For each partnership LUP established, we at Consonance imported the list’s data to LUP’s account on Consonance, often against tight deadlines to fit with launch dates, enhancing the data on import to tidy up legacy data issues. We then incorporated the data into existing ONIX feeds to recipients such as JSTOR, CLOCKSS, The Co-Op, EBSCO, ProQuest, Cambridge CORE, PLS, British Library Legal Deposit, iGroup, CNPIEC, CCC, Turpin, Nielsen BookData and more, ensuring an uninterrupted flow of data to these key data aggregators and recipients.

Since LUP started using Consonance, we have sent over 11 million updates of product metadata in ONIX for them.

Our collaborations with Liverpool University Press are ongoing and a testament to their innovative approach. In 2024, we worked closely with the team to deliver the mechanism that underpins the Liverpool Distribution Services, the …boutique sales, marketing and distribution service offered by LUP that aims to provide a genuine sense of transatlantic university press partnership. Consonance takes multiple live ONIX feeds from service partner The University of Michigan Press (UMP), cleans the data for the UK market, and provides feedback mechanisms to keep data flowing without impediment.

Heather Gallagher, Books Marketing Manager at LUP, says:

“Consonance is instrumental in keeping our data organised and getting it out to our trading partners. They have (time and again) been able to facilitate our changing needs and work with us to bring the highest quality data to our website and beyond. With regular updates on new and improved features, and a highly responsive team, Consonance is always a pleasure to work with and we highly recommend them to anyone wishing to streamline workloads and improve their business”.

In offering congratulations to LUP on celebrating their 125th anniversary, we are proud to have been able to simplify their data management and improve their data quality, whilst at the same time ensuring its wide dissemination, and facilitate new business models, and are honoured to continue to support such an important press in their ongoing innovations.

Book Dash

2024-02-19T00:00:00+00:00

In 2014, a group of friends with a background in publishing launched Book Dash in South Africa. Their goal was simple yet ambitious: to flood the country with affordable, high-quality books for children, especially in African languages. The founders, Arthur Attwell, Michelle Matthews, and Tarryn-Anne Anderson, started this venture to address the lack of access to appropriate storybooks for children. This initiative quickly grew into a non-profit organisation committed to creating, printing, and distributing these books at low cost.

The Challenge

As Book Dash’s library of charming books grew, so did the challenge of managing the metadata for an ever-increasing number of products. The organisation needed an efficient way to handle this information to ensure that the books reached their intended audiences quickly and the creative volunteers could see the impact of their efforts.

The Solution from Consonance

Consonance provided Book Dash with a personalised metadata management system designed to meet their needs. Our system features a robust and flexible platform for managing their extensive book catalogue (800+ books), combined with a user-friendly interface. Now, with all metadata centralised in one location, Consonance has become the single source of truth for Book Dash. Gone are the days of scattered spreadsheets and databases; processes ranging from managing book metadata and dashboards to updating the website are now aligned and streamlined according to international standards following Consonance’s structure of categories and tags.

This automation has significantly reduced Book Dash’s administrative burden, freeing them to focus more intently on their core mission. Seamless integration with Consonance’s GraphQL API has revolutionised how Book Dash updates its book records online, ensuring that the latest metadata is automatically and efficiently incorporated directly from Consonance.

Following a recent website upgrade, users also now enjoy an improved capability to search and filter books by language and theme. This enhancement, powered by BISAC and language data already stored in Consonance, allows users to customise their browsing experience, making it easier for them to discover books that align perfectly with their interests and requirements.

Enhanced Decision-Making with Dashboards

The introduction of management dashboards at Book Dash has made a big difference in how they plan and report on their activities. These dashboards pull together data from Consonance’s GraphQL API and other sources, automating the process to give a full picture of Book Dash’s book catalogue and operations. This setup makes it much easier for the team to keep an eye on how things are going, see the real effect of their efforts, and tweak their approach as needed—all more efficiently and with better transparency. Thanks to this use of technology, manual data handling is cut down, freeing up more time for Book Dash to focus on getting books into the hands of children. Plus, it helps them keep a clear and detailed record of what’s working well and what could be better, guiding them to make meaningful improvements in making books more accessible.

Tracking impact with Creatives Dashboards

Since partnering with Consonance, Book Dash has improved its approach to engaging with creative volunteers, transitioning from a labour-intensive, manual method of compiling and disseminating updates to a streamlined and effective strategy. The introduction of a Creatives Dashboard template, which incorporates real-time data from Consonance, enables Book Dash to furnish volunteers with personalised insights. These dashboards provide a detailed summary of the volunteers’ contributions and the tangible impact their work has made on the world. This shift not only conserves time but also greatly enhances the volunteer experience by offering a quicker and more meaningful feedback mechanism. The creation of these individual dashboards, showcasing updates on the books contributed to and their influence, marks a significant improvement over the previous system, where gathering and sharing such information was a cumbersome annual task. This innovative approach underscores Book Dash’s commitment to recognising and valuing the vital role of its creative community.

Results

Consonance supported the transformation of the operations at Book Dash, streamlining the data management of their ever-expanding book collection and enabling more informed decision-making through effective data integration. This change increased the organisation’s accountability and transparency with stakeholders but also allowed Book Dash to concentrate more on its core mission rather than being bogged down by administrative tasks. The improved system noticeably enhanced their metadata management and the integrity of their data, ensuring that more children have access to good quality stories.

The collaboration between Book Dash and Consonance showcases how the power of technology when used well can support social initiatives to succeed and grow. We are delighted to support Book Dash to advance their goal of making quality storybooks easily available and boosting book ownership among South Africa’s youngest children and wish them every success!

How to use RSS

2023-11-15T00:00:00+00:00

To be the first to know about new blog posts from Consonance (I know! It is exciting, you’re right!), subscribe to our RSS feed. Then, once you’ve set up an RSS reader, add many more feeds, from other blogs that you like to read. Here’s how I do it.

Find an RSS reader that you like

I use https://feeder.co because it’s free (to a point).

Get our blog’s RSS feed URL

Spoiler: it’s https://www.consonance.app/feed.xml. You can also click on the RSS icon (at the bottom of this post) to go to that URL. Copy the URL to get it on your pasteboard.

Paste the URL into Feeder

This will be different for different readers, but the process is probably similar. Find the button that reads Add new feed, click RSS, and paste in your URL.

Enjoy reading!

Bedford Square Publishers

2023-11-04T00:00:00+00:00

Bedford Square Publishers, rooted in the rich history of London and Brighton’s Bedford Square, has quickly made a name for itself as an independent publisher. Known for selecting stories with a worldwide appeal, they focus on bringing compelling and universally resonant narratives to a global audience.

Established by publishing veterans Hodder & Stoughton c.e.o. Jamie Hodder-Williams and ex-John Murray sales strategy director Laura Fletcher, Bedford Square Publishers understood the necessity of an advanced publishing management system and quickly partnered with Consonance to enhance their operations. This strategic collaboration has sharpened their publishing processes and broadened their global reach, ensuring accurate product representation with major industry platforms, including Amazon, Nielsen, and BDS.

Following the swift acquisition of No Exit Press, Bedford Square Publishers faced the substantial task of integrating an legacy catalogue of over a thousand titles. The consolidation phase was made smoother by Consonance’s advanced metadata management system, which played a crucial role in facilitating a seamless transition.

To showcase Bedford Square’s extensive experience in the publishing industry, their team also sought to create an advance information sheet that reflected this depth of expertise. Embracing this vision, the Consonance team transformed Bedford Square’s detailed layout into a reality, crafting beautiful, bespoke Advance Information sheets that incorporated elegant typography and a clean, professional layout that effectively communicates Bedford Square’s industry prestige and proficiency, marrying informative content with high quality design.

As Bedford Square Publishers carves its path in the literary world, the scalable solutions from Consonance continue to support its growth and commitment to introducing new literary voices. This powerful combination of traditional storytelling zeal and thoughtful little innovations from Consonance position Bedford Square Publishers not only for growth but also as a trendsetter in the independent global publishing arena.

Leuven University Press

2023-10-24T00:00:00+00:00

Established in 1971, Leuven University Press’ foundation goes hand in hand with the long-standing academic tradition at Leuven, which dates back to 1425. Leuven UP has a rich history of publishing academic titles across a wide range of disciplines and this broad spectrum reflects the diverse research areas at KU Leuven. Partnering with Consonance in 2017, Leuven transitioned from their older platform and through our system they have been able to trace back, access, and manage their publications with ease, maintaining a digital footprint of their publishing journey while they continue to develop and grow.

Leuven University Press has an international focus, publishing works in several languages, making its publications accessible to a global academic audience. Leuven UP effectively manages a diverse catalogue of more than 1600 active products through Consonance and publishes about 45 books a year, with the overall majority being in English, and to a lesser extent in Dutch, German, French and Spanish. Consonance seamlessly facilitates the complex metadata management required for global distribution and ensures that the necessary metadata aligns with international standards, making Leuven UP’s publications available to distributors and retailers worldwide.

With its home in Belgium, being in the European Union presents specific considerations and opportunities for Leuven University Press, especially regarding data protection, standardisation, and inclusivity across a diverse market. Consonance handles the EU’s GDPR requirements for safeguarding personal data sensitively and helps Leuven navigate the legalities of these regulations through user account permissions that prevent unnecessary disclosure of contributors’ details such as addresses and phone numbers beyond business necessity.

Consonance also supports the EU’s directive to make digital content accessible to all and through our ‘thoughtful little innovations’ helps Leuven UP to meet these accessibility standards. Incorporating metadata fields that indicate the accessibility features of their products, and integrated DAISY file accessibility checks, Leuven is able to communicate to retailers and libraries that their ebooks are accessible, with ease.

By addressing these EU-specific requirements and more, Consonance ensures that Leuven University Press maximises its potential in the European market, adhering to the necessary standards and regulations while also taking advantage of the unique opportunities the EU presents.

In line with the global trend in academic publishing, Leuven UP has been growing steadily in open access publishing since 2015, offering selected book titles to readers for free online while still maintaining their high academic standards. This initiative aims to disseminate scholarly knowledge more widely and democratically. As Leuven UP progresses on their open access journey, Consonance continues to effectively manage the specific metadata requirements for open access publications, ensuring they are appropriately tagged and discoverable.

For each partnership that Leuven UP formed, we at Consonance seamlessly integrated the list’s data into Leuven UP’s Consonance account, enhancing the information on upload to rectify any previous platform’s data inconsistencies. This data was then smoothly incorporated into existing ONIX transmissions to major recipients worldwide including Baker and Taylor, Biblioboard, BDS, Boekenbank, CEPIEC, IPS UK, EBSCO, Gardners, JSTOR, OAPEN, Project Muse and ProQuest. Since the start of Leuven UP’s collaboration with Consonance, we have dispatched over 5000 updates of product metadata in ONIX for them and continue to support their distribution requirements.

With Consonance’s state-of-the-art publishing management system, Leuven University Press is poised for an exciting future. While honouring their academic publishing heritage, they confidently navigate the challenges and opportunities of today’s digital global publishing landscape.

Annemie Vandezande, Marketing Manager at Leuven University Press, says:

“Good metadata is crucial for optimal findability of our publications. Thanks to Consonance we can efficiently manage, update and distribute our metadata to all our different publishing partners. If new requirements are needed, such as the new accessibility standards for example, Consonance takes care of the necessary adjustments. This way we are always up-to-date with new developments.”.

Thoughtful little innovations, at the London Book Fair '23

2023-04-18T00:00:00+00:00

I’m happy to share this playlist of a few short videos that highlight some of the little innovations in Consonance that add up to a greater whole. We’ll be adding to it as we go, so do like and subscribe, as they say!

GraphQL at Christmas

2022-12-03T00:00:00+00:00

Pretty exciting times over here at Consonance Towers, as we gear up for the launch of our new metadata page at Christmas. Heck, I’m even running a webinar!

I’m going to post about it quite a lot as it’s been five, count ‘em, years in the making. We’ve learned some things, taken certain approaches, and I always find it interesting to hear about other people’s really long projects. How do they keep motivated? Do they plan it all up front, or follow their noses? How do they make five years of work make sense as a single deliverable? And if nothing else, writing about it will be a useful way to exorcise the demons of it being our lockdown project, suffused with the weirdness of the last few years, as well as it drawing a very solid line between the start-up-ish-rapid-development phase, to make-the-best-goddamn-app-in-the-world phase of our business.

Anyway, to wet your whistle (wet? whet? I had to look it up. It’s wet, although it should be appetite, not whistle. Tut.), here are some docs – with sample code! – for the data source for this new page. It’s our GraphQL API. As well as us building cool things like the metadata page, and the inevitable Advance Information template, with it, some of our customers have built their own things, too, which is just about the best outcome I could have dared to hope for.

Anyway, more to come, watch this space, etc…

A non-technical, beginners' guide to ONIX for Books

2022-10-24T00:00:00+00:00

ONIX is a type of XML (whatever that is)

ONIX is built using something called XML. Let’s not worry what those letters stand for. (It’s ‘Extensible Markup Language’, but you don’t need to know that.)

XML is one of those boring ideas that can make businesses run more smoothly, like ISBN-13 numbers or barcodes. Really it’s just some general rules for how to write down information so that computers as well as people can read it (but mainly computers). It’s not even a full set of rules; it’s just enough to help people make a start on designing their own formats for sharing information.

If there’s a particular kind of information you want to store in a standardised way, you can take the basic rules of XML and add your own extra rules appropriate to the type of data you care about. When you’re finished, you can share that combined set of rules with your friends and call it a standard.

Within publishing, people wanted to share information about new titles, so a consortium of publishing experts called EDItEUR took the basic XML rules and added a lot of book-related rules in order to create what they called the ‘ONIX’ standard.

Onix is short for ONline Information eXchange (but you’ll never need to know that). Frankly, it’s a terrible acronym because it gives no clue about its purpose; a name like that could apply to almost any form of electronic communication. On the other hand, the word ‘ONIX’ is fairly memorable, even if it doesn’t particularly make you think of publishing.

EDItEUR created rules for how to specify each piece of title-related info until they arrived at a standardised way for describing everything they thought a typical book shop, library or distributor would need to know about a new title – or an old one, for that matter. As you can imagine, that kind of standardisation has the potential to make it much easier for the whole industry to share information with thousands of organisations by sending them all a copy of the same ‘ONIX message’ file.

But XML itself wasn’t created by publishers. In other sectors, XML is being used as the starting point for storing a multitude of different types of information. There are XML standards for creating an invoice or describing a gene – or (to return to publishing) to store the contents of an e-book in a standardised way. With that in mind, we’ll cover the absolute basics of XML and then - long before your eyes glaze over - we’ll switch back to ONIX and talk about its pros, cons and practicalities.

The guts of XML (made palatable for non-techies)

The first thing to learn about XML is good news: it’s written in English. Or rather it’s written using ordinary words, with a few squiggles added, and not in some sort of computer hieroglyphics.

So, imagine that you’re sending out details of a new book that you’re publishing. Naturally you want everyone to add its details to their stock systems so they can easily order it. Let’s start with the title, ‘The Life and Times of Ned Lud’. A human being can take a guess that it’s a book title, but in XML you always label information to make it clear. So we might write this:

1
<TitleText>The Life and Times of Ned Lud</TitleText>

It’s like that maxim for giving an informative talk: tell people what you’re going to say, then say it, then tell them what you just said. So that line above says: Here comes something called TitleText, ‘The Life and Times of Ned Lud’, that’s the end of the TitleText. When you put ‘/’ in front of a label you’re marking the end of something.

Of course you can make up your own names for information. You could choose <NameOfBook> or <FieldDD6_Alpha_Gobbledygook>, but it just so happens that <TitleText> is the name that’s been agreed on by a large group of book publishers as part of the ONIX standard. The bit in the angle brackets is called a ‘tag’. It’s fairly easy to see why; you ‘tag’ information to say what it means.

For instance, if all you have is the piece of text ‘Winston Churchill’, it’s difficult to tell whether that’s a book about him or a book written by him – both are plausible. So everything gets tagged for clarity’s sake. Take a look at this:

1
2
3
4
<Author>Katie Daynes</Author>
<TitleText>Winston Churchill</TitleText>
<ISBN>074606814X</ISBN>
<Publisher>Usborne Publishing Ltd</Publisher>

Hopefully it’s pretty obvious what that all means. Each ‘tag’ has a start and an end, and the bit in the middle is the information you want to share – also known as the ‘contents’ of the tag. A computer can easily read it and so can a person (with a little effort). Unfortunately for us, information about books gets complicated and so the XML used to store it has to get complicated too.

For instance, what do we do if there’s more than one author? Or if there’s no author, just an editor and some contributors? And what about all the other pieces of information we might want to share, like publication date, price and distributor details? The people who wrote ONIX came up with a format that allows you store a vast amount of information about a title in a structured way.

One feature of XML that the ONIX designers made use of was the idea of putting one tag inside another. It would be helpful to show you what that looks like, but real ONIX documents are difficult to read, so this next example is just a made-up one; it doesn’t follow the ONIX standard. But on the plus side, it’s actually possible for a human to understand it.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
    <Book>
      <Title>
        <MainTitle>The Life and Times of Ned Lud</MainTitle>
        <SubTitle>Backward Looking Visionary</SubTitle>
      </Title>
      <Author>
        <FirstName>Emma</FirstName>
        <Surname>Barnes</Surname>
      </Author>
      <Illustrator>
        <FirstName>Rob</FirstName>
        <Surname>Jones</Surname>
      </Illustrator>
    </Book>

So in this made-up example, if a <Surname> tag is inside an <Author> tag, then it’s the name of an Author; if it’s inside an <Illustrator> tag, then it’s the name of an illustrator.

There’s lots more to be said about XML, but it doesn’t get any more interesting. Plus we’ve probably covered everything we need to in order to understand how it applies to ONIX and the publishing industry.

The ONIX Standard

If you want an easy way to tell Nielsen or Amazon or Waterstones about a new book, you can put all the relevant info in an ONIX message and e-mail or FTP it to them. In case you’re interested, the British contributors to the ONIX standard were the BIC, made up of the Library Association, The British Library, The Booksellers Association and The Publishers Association, so it’s got some weight behind it.

It’s a gigantic and complicated standard because it needs to be able to hold gigantic and complicated amounts of information for each title. For instance, it gives you tags for listing the back cover quotes on your book, and giving the names of each quote contributor and the organisations they work for. It lets you include details of discounts and promotions by date and region. It holds information on formats and rights and physical dimensions – and even what units the measurements are being given in.

Unfortunately for anyone who wants to open an ONIX message and actually read the contents, the standard also makes use of numbers where a name would have been easier to read. For instance, if you want to know whether a book has been published yet you could look at the relevant tag. Here it is:

1
    <PublishingStatus>04</PublishingStatus>

But what does ‘04’ mean? Well, if you hunt down a copy of the ONIX documentation you’ll find a list called ‘ONIX Code Lists Issue 11 List 64: Publishing status’, with entries such as:

1
  04: Active. The product was published, and is still active in the sense that the publisher will accept orders for it, though it may or may not be immediately available, for which see <SupplyDetail>.

and

1
    05: No longer our product. Ownership of the product has been transferred to another publisher (with details of acquiring publisher if possible in PR.19).

And many more. There are over 150 of these lists explaining what the various different numbers and codes mean. So while humans can get the gist of what’s in an ONIX message, the details are often hard to follow. The ONIX people could have chosen to use the words ‘Active’ and ‘No longer our product’ instead of the numbers ‘04’ and ‘05’, but they probably took the view that machines, rather than people, would be reading these messages and felt that numbers were more computer-y.

In what ways might I mess up an ONIX message?

Given all that opaque complexity, it’s easy to imagine trying to create an ONIX message and making a mess of it. In fact there are at least three different levels of mess that you could make.

The first hurdle to clear is whether an ONIX message is ‘well-formed’. For instance, if you’ve opened a tag but not closed it (like with the ISBN element below), then regardless of whatever riveting information your ONIX message contains, it’s going to be consigned to the bin.

1
2
3
4
    <Author>Katie Daynes</Author>
    <TitleText>Winston Churchill</TitleText>
    <ISBN>074606814X
    <Publisher>Usborne Publishing Ltd</Publisher>

The rules for being ‘well-formed’ are really just the rules for writing XML of any kind. So it doesn’t matter if you’re using the ONIX standard or an XML standard for describing molecules, if you don’t get the basics right, your message will not be readable by anyone’s systems.

It’s well-formed but is it valid?

That leads us to the next kind of mistake that one can make. An XML file can be ‘well-formed’ but not ‘valid’. To check validity you need a standard to compare it against, which in our case would be the ONIX standard.

So perhaps your XML is perfect, but by mistake you’ve used the Advanced Rocketry Asteroid Configuration standard. Commiserations! You’ve perfectly described an asteroid, rather than a book. According to the ARAC standard, your file is valid; according to the ONIX standard it is not.

A more likely scenario however is that you’ve attempted to use the ONIX standard but you’ve missed out something that’s mandatory or fallen foul of any of hundreds of other pitfalls.

The peeps in charge of XML have provided a way to specify all the requirements that a message must fulfil in order to be valid. They call that specification a DTD. (You don’t need to know what DTD stands for. It’s Document Type Description, but now you can forget that.)

Each standard should have a DTD. The DTD says which tags are required and which are optional. It lists the tag names that are allowed and the kind of data each one is allowed to contain. It says whether there can be more than one tag of a particular type and whether it’s allowed to contain other tags within it.

If you have the appropriate kind of software, you can show it your attempt at an ONIX message, make sure the software can find the DTD for ONIX and then ask it whether your message has passed or failed its validity check.

Don’t (necessarily) blame ONIX

The third and final level of mistake you can make when creating an ONIX message concerns the information it contains. Nothing within the ONIX standard can help you if you mistakenly set the TitleText of your book to ‘The Fridges of Madison County’ instead of ‘The Bridges of Madison County’.

Likewise, if you accidentally send out an ONIX message which details not just the cost price that the recipient of the message must pay but also the cost that the recipient’s competitors are being charged, then the resultant egg on your face is self-inflicted. The ONIX standard tells you what you must include and what you can include, but not what it’s wise to include or whether you spelled it properly.

Of course, after the third and final level of problems comes the fourth and most problematic level which arises when different companies and organisations within the world of publishing invent their own flavours, subsets and artificial dialects of ONIX.

Sometimes these take the form of additional information required or particular ways of specifying things. In many cases these requirements come from limitations in the software or processes that a particular organisation is using. Specify too many of a particular type of tag and that organisation might not be able to read your ONIX message. The standard allows it but their systems can’t handle it.

Standard? Which standard?

That fourth type of problem with your ONIX message can also arise from the fact that standards are often a moving target and not everyone manages to keep up.

Few standardisation processes manage to hit the bullseye first time. The ONIX standard is no exception. As of 2022, we’ve left version 1.0 far behind us, passed through minor revisions, then a big leap to 2.0, then more revisions, both big and small - with version 2.1 being very popular - to arrive at the most recent version, which is 3.0.x - where that x denotes which minor revision of 3.0 you’re using. At the time of writing, the current version is 3.0.8.

But not everyone is using version 3.0. Previous versions work well enough, and updating software or processes costs money. So despite the fact that it was superseded in 2009, version 2.1 is still as far as some companies have progressed.

Send a company whose systems only speak version 2.1 an ONIX message validated against the 3.0 DTD and the outcome is unlikely to be the one you hoped for.

How to create an ONIX message

In theory, if you only had a handful of titles to worry about, you could attempt to type out your ONIX messages by hand. They are, after all, just text files. But first of all there are all those pesky tags that require you to know that, say, according to ‘ONIX Code Lists Issue 11 List 7: Product form code’ you need to use the code ‘BC’ to denote a paperback. There’s also the need to check your message against the appropriate DTD to see if it’s valid.

Realistically, hand-typing an ONIX message that contains anything more than the most minimal and basic of information is completely impractical.

The nice thing about using a publishing management system such as Consonance to generate ONIX messages is that it will already know about all of your current and upcoming titles. So when you want to send out an ONIX message, Consonance can generate it for you, filling in all the relevant tags with information about your titles. And (like the example mentioned above) it will know about all the confusing codes such as the need to use ‘04’ for a title with an ‘active’ publishing status. In effect it can convert from the human-readable information you’ve set the system up with into the machine-friendly codes and tags of ONIX.

When you originally entered that information into Consonance, you would have used straightforward, familiar terms. Better still, during data entry many pieces of information will have been selected from lists of valid options so that there’s no possibility of entering something that’s mistyped or garbled.

And if you already have ONIX messages describing your titles and you want to start using Consonance, we can probably read those messages into the system to save you having to type any of it out again.

There’s a lot more to be said about the ONIX standard - much of it comprised of gotchas and cautionary tales - but if you’ve read this far you’ll hopefully know enough to join in fun dinner party conversations on the subject and look techies in the eye without flinching, so we’ll leave it there.

Unshackle your data and free your time with GraphQL

2022-05-17T00:00:00+00:00

It’s 2022 and instead of technology making your job easier it’s just adding another layer of inescapable complexity. You find yourself overworked and under-resourced, keying in the same product information into the same clunky software, meticulously copying that same information into the same monthly spreadsheets, and spending hours crafting catalogues only to discover that you’re working with out-of-date data.

When I first started working in Publishing nearly a decade ago, naive as I was, I didn’t expect so much of my time to be taken up with repetitive, administrative tasks. Ten years later very little has changed. Despite being an industry full of highly creative people, Publishing remains plagued at all levels with tedious, manual data entry tasks that take us away from the work that uses our skills. Everyone agrees good data is crucial to business success but no one has the time (or interest) to deal with it fully.

With Consonance’s new GraphQL interface, we can help free your time to focus on more creative, collaborative tasks, offer even more efficient ways of getting at your data, and deliver fully customisable solutions for presenting your titles in ways that suit your business needs. GraphQL lets you programatically get at the data that you need and gives you the creative freedom to show off your titles at their best with minimal manual effort.

Beautifully bespoke marketing materials

Spend more time working on making sales and less time creating marketing materials. Design a flyer or catalogue to your requirements once and use our GraphQL API to populate the data each time you need it. Planning a big presentation and want to make sure the titles you’re pitching are up-to-date? Use the GraphQL API to pull key title information straight from Consonance and make sure everyone’s on the same page.

Curatable reporting tools

No need to spend time filtering and stitching spreadsheets together or creating KPI dashboards from scratch each month, Consonance and GraphQL can help you produce custom reports using live data from our system, filtered and curated by you to your requirements. No middlemen required.

Forms that do the legwork for you

Keep your production details in Consonance and we can help make your next print run a less painful experience, using GraphQL to populate order forms at a single click. Get the data right in Consonance and you can eliminate costly errors introduced by last minute manual mistypes.

Powerful integration potential

Combine Consonance’s GraphQL API with a data visualisation tool like Google Data Studio and create beautiful, meaningful dashboards of your products with live data that shows off your publishing journey at a glance. Alternatively, use GraphQL to generate your website catalogue and ensure that your titles are as discoverable as possible.

When I joined Consonance at the start of the year, I was burned out from fighting with inflexible systems, frustrated by how unnecessarily slow and complicated it was to get at the data that I needed to do my job. As part of the Consonance team, my focus is finding ways to make people’s working lives easier and giving them the tools to help themselves.

One source of bibliographic truth empowered by Consonance can save you time, money and sanity, and now combined with our new GraphQL API your data can now be liberated from static sheets and systems with ease, getting out of the way and letting you get on with your day.

Pandemic update

2021-01-04T00:00:00+00:00

Update, Janury 2021

As England goes into another full lockdown today, with schools closed until mid February, we wish you all the best for 2021 as we face the new year with resolve, strength and a happy bank manager: as you might expect, cloud-based software companies are not in the category of businesses who have suffered commercially – lucky us. We celebrate the knowledgeable scientists who have given us our light at the end of the tunnel, so onwards, as we support you into 2021 and beyond.

April 2020

We’re lucky in that we write software for the web, rather than run a warehouse, serve people face-to-face, or even rely on on-site servers, so our pandemic journey is, to date, more gentle than others’, for which we’re grateful. Here’s what we’re doing.

Health and happiness

Staff and our families’ health is the obvious first priority, so we’ve all be working from home since March 12th, adhering rigidly to social distancing, not leaving our houses except for the weekly shop and daily exercise. Technically, that’s not a problem as all our work machines are laptops anyway. Ergonomically, we’ve kitted out our home offices with standing desks, monitors, microphones and other accoutrements to make things as comfortable as possible. Socially, it sucks, so we’ve had twice-daily team calls just to connect, as well as discuss work. At least it’s been fairly sunny…

Archery pic.twitter.com/l27mn8kj2a
— Emma Barnes (@has_many_books) March 26, 2020

Supporting our customers

We’ve not worked remotely as a team before the pandemic, other than the occasional day here and there. But we are natural online people. So after we’d got over the initial shock of the shape of our days changing so much, we agreed that our focus would be on helping customers to make the same transition to a new way of working. So we’ve put regular updates on our Community forum about the tools they have in Consonance that are now particularly useful to newly-remote teams, such as to-dos. And we’re responding as usual to support tickets and continuing the same pace on project communications in Basecamp, so that managing data and processes can be one less thing for customers to worry about.

All the usual things the system does continue: nightly feeds to websites, royalty runs, ONIX to Nielsen, BDS, Bowker and more than 50 other recipients, user support, onboarding, data updates, development and even a bump to the latest version of Rails (6.0.2.2)! Having well-maintained software makes things a lot easier.

Business continuity

Delivering our service is unlikely to be interrupted by the spreading of the virus:

– Consonance is accessed remotely by end users

– Our staff have no face-to-face contact with our users and are not required to travel for work.

– Our key suppliers have confirmed they will continue to meet their obligations, and have good disaster recovery plans in place for continuing emergencies.

– We have arrangements in place to ensure the continued smooth running of our business in the event of staff being ill with COVID-19.

Since we’re accredited by the UK government under their Cyber Essentials scheme, we already had a business continuity plan in place, which we’ve updated in parts based on this emergency. We have our own central store of data for things such as process documentation, insurance, financial and legal documentation, contact and log in information and so on.

Thanks to our suppliers

We also use some excellent web apps that have afforded continuity in much the same way as we hope Consonance has done for our customers. Freeagent for accountancy, Float for cash flow forecasting, Slack for team comms, GitHub, CodeCov, CodeShip and Heroku for code and hosting management, Basecamp for project management: all in the cloud, thank heavens. So thanks to all them for giving us the tools so we can focus on our customers’ communications and our work.

What we’re working on

Development-wise, we’re working on the things we were planning to work on anyway. I am working on revamping the metadata page. Dave is working on new client implementations. Sara is working on enhancing the product importer tools we have. Andy is improving Notifications in the system. For me, programming is proving to be a calming, distracting practice away from the more general worry.

Side projects

Just before the pandemic hit, I finished the https://sideprojectsummer.com website, ready for the summer. We’re a bit uncomfortable about promoting the idea of productivity during a time of emergency, but nearer to May we will suggest that if anyone wants to find solace in coding, we’re here to walk alongside them.

On the note of side projects, my https://makeourbook.com is rather popular at the moment for parents who find themselves homeschoolers, Andy’s https://paintpad.app is providing a hub for hobbyists to take comfort in their model painting, and Sara’s https://bookpenpals.com digital postcards will be a way for authors to connect with children.

We are also pleased to be supporting the newly-online version of Brighton Ruby (https://brightonruby.com/). I got on the list to do a talk which I’ll now deliver via video. And we’re producing a beautiful printed version of the fabled Ruby book Why’s (Poignant) Guide To Ruby as postable Brighton Ruby swag.

All in all, we as a team are proud to be doing things at the moment which provide security and calm for our customers and users.

Stay well, and we’ll update this if anything changes. But we’re expecting this is the new normal for the foreseeable. So buy lots of books from our customers in the meantime!

At times like this we appreciate service providers in our sector more than ever. Thanks especially to @has_many_books
and the team @consonance_app for helping us continue to do what we do best whilst the team works from home…publish quality books for a specialist market. pic.twitter.com/WhXreHHaHc
— Facet Publishing (@facetpublishing) March 31, 2020

Deanna joins the team!

2020-08-03T00:00:00+00:00

Some lovely news for us in all of this: we are delighted to announce that Deanna Marbeck joins our team today. Deanna is unique in that she is the only publisher-turned-web developer who has also run a Consonance implementation: she previously worked at our client the Royal Pharmaceutical Society’s Pharmaceutical Press, during which time she selected and implemented our software to support their publishing operations.

Now she’s on the other side, having left publishing a few years back to retrain as a software developer. But with books running through her veins (she holds a Post-Graduate Diploma of Librarianship and Information Studies from Victoria University of New Zealand) we’re just delighted to have her back!

It’s a funny old time to be growing the team, now we’re all fully remote, but this year our clients have often told us that Consonance has been a great source of stability and connectedness, and our business has grown rather exponentially. Deanna will be focussed on the ONIX part of Consonance initially, so expect to say hello on the help desk and the Community forum and give her a big welcome!

Brighton Ruby, why's (Poignant) Guide, and justsimply.dev

2020-06-14T00:00:00+00:00

For a weekend side project for the last few months, I’ve been producing this year’s Brighton Ruby conference’s companion book: a 2020 edition of Why the Lucky Stiff’s Poignant Guide to Ruby. It’s a bit of a seminal work, in Ruby circles. Read all about it on Wikipedia.

Our edition is rather beautiful and intended to be something nice for the Ruby programming language community to enjoy in this difficult year. And what could be finer than a lovely book, as I’m sure we can all agree! Well done Lightning Source for still being open for business…

I’m also a speaker at this year’s Brighton Ruby, which is remote this year. I’m talking about the importance of using editorial skills to make technical writing accessible and appealing, an idea encapsulated by a website we maintain called justsimply.dev.

If you want a copy of the book, and to hear my talk, alongside all the excellent speakers, it’s only £29 and tickets are available here: https://brightonruby.com/

Discussions in Consonance

2020-06-10T00:00:00+00:00

When the lockdown started, one of our first remotely-held planning meetings was to brainstorm what we could do to help our clients in their newly-remote working situations. We were living the reality ourselves – and will be doing so, of course, for the foreseeable future. (There’s another blog post brewing about our own working arrangements. Spoiler: remote working is going well for us, and it’s saving us money, and allowing us to spend more time with family and friends. None of us misses commuting. So it looks like we may well adopt remote working as our own normal working practice, after the current emergency abates.) At our brainstorm, we wanted to see if there was any helpful work to be done, or any priorities to be re-drawn, to ameliorate the working conditions of the new situation our clients find themselves in.

And sure enough, an idea that had been bubbling away for years on the one day list bubbled its way at last to the surface. The idea was about discussions.

The idea of Consonance being one version of the truth is one that we talk about a lot. We have written our software to blur the lines between departments. Editorial don’t maintain a product list separate from Rights, separate from Production: there’s one list for everyone to refer to, to see the latest publication dates, contributor credits, page counts, price and so on. One version of the truth means less confusion, less admin, less busywork, less duplication, less inefficiency, and more egalitarian access for everyone in the business to the data they need to do their job.

In recent times, we’ve extended this idea to types of data beyond bibliographic, contracts, rights and royalties, to workflow. Our to-dos functionality allows teams to maintain a shared list of what needs doing, when – even allowing users outside of the system to see lists of to-dos, via an iCal export that makes to-dos show up in Google calendars.

But there’s been a further, human, aspect of a shared truth missing in Consonance, and that’s the ability to manage discussions. Discussions are the fluid, un-plannable, unstructured conversations that flow through a project team, and whose content depends on shifting context and circumstance. Who’s to say whether a team will end up discussing an event, a problem, an idea? It’s the nature of agile projects that you can’t plan every last thing up front, and it’s the hallmark of a functional team that it can pivot and adapt to conditions as they change. Those teams need the tools to enable that discussion.

Now, back in the Before Times, the most natural thing to do might have been to bring things up in discussion up at the weekly team meeting, or wander over to a co-worker’s desk to chat it over: because, six months ago, most publishing teams were not remote. But now, the vast majority of publishing teams are, and for who knows how long. Some teams, like us, will stay remote, now they’ve tried it and discover the up-sides are greater than the down-sides. Others may adopt a hybrid approach and end up working from home a bit more often. Others still may go back to the office, but be aware that lockdown may come back, that circumstances can always change, and that PostIt notes stuck to computer monitors on a desk in an office on the Embankment in London are not the most convenient project management tool when you are in Hemel Hempstead. And those who’ve been juggling myriad systems such as Zoom, Google Meet, Microsoft Teams, Slack, Monday, emails, VPNs and more are only too aware of how much better it is to have just one place in which you get things done.

So we jiggled our planned development schedule around and set to work on building the ability to manage discussions within Consonance – conveniently alongside all the other data needed to manage a publishing list. Six weeks of hard work by the team means you now have the discussions picture above.

Start a discussion, add your colleagues to it, and before long you’ll have a rich, nuanced history of the thought process behind decisions in your projects. And, critically, these discussions are accessible to anyone, geographically, and temporally, where and whenever they’re reading and contributing from.

Being thrust into 100% remote working isn’t how any of us would have planned things. But here we are, and we’re impressed every day by how imaginatively our clients are managing. We hope this new ability to manage discussions helps you navigate the myriad tasks and considerations required to keep your publishing going.

Introduction to publishing management software

2020-05-28T00:00:00+00:00

Introduction to publishing management systems

If you don’t currently have access to a publishing management system (sometimes called title management, which bothers me because titles are the thing you put on the front of the cover. Precision matters!), it seems almost impossible to find out what one does. What does it look like? How do publishers use it? Why do they use it?

We realised that we could open the door a little and show some of how publishing works. When we offered to host a virtual Introduction to publishing management software on Zoom, we sold out 100 tickets plus a waiting list that same day.

It’s clear that this information is something people are hungry for, but they don’t know where to get it. So, we’re going to provide it!

First, we’d like to give a shout out to our blog and our system documentation for more in depth information on everything we cover here. It’s all publicly accessible, so you can dive into any area that interests you. Even if you aren’t lucky enough to end up using Consonance, the principles of how these systems work are the same, so spend a little time getting familiar with it. We’ve organised some of the basic documentation in Consonance 101 and if you want to challenge yourself, move on to Consonance Expert.

We’d like to highlight these particular articles for insight:

Here is the video of the webinar we ran, with Consonance CEO Emma Barnes talking through some of the top level ideas behind publishing management software, with insights into bibliographic data management, ONIX, contracts, rights and royalties, and workflow management.

It’s all about What good publishers want:

Links to some of the resources we mentioned:

Resources that some top book publishers point their new and aspiring employees to:

Publishers Association careers page
An excellent round up of industry resources from @AinChiara
@R_Nash’s What is the Business of Literature? with sentences like, … the book is a technology so pervasive … that it reaches the status of Nature
@kevin2kelly’s Better than Free with points such as: Trust cannot be copied… It cannot be downloaded..
@JaneFriedman for the business of publishing
For editors: Harts Rules and Judith Butcher’s Copyediting

Communities to check in on:

We highly recommend BookMachine for training, resources and support
Join a newly launched Facebook group for publishing hopefuls
Hashtags: #BookJobTransparency #WorkInPublishing and #JobsInBooks for employers/roles/salaries/people to follow
Interested in production? There’s a Twitter account for that @_prod_squad

And we’d love to add other resources to this blog post, or enhance the ones we’ve got. If you’ve got something to add or to ask or that needs clarifying, please contact us! @consonance_app, @has_many_books or @saramoohead on Twitter.

Internship report

2019-05-30T00:00:00+00:00

Ariana writes: “For the last month or so I have had the amazing opportunity to be an intern with Snowbooks, an independent publishing house in the village of Thame. Working two days a week, I have been warmly accepted and kindly tolerated as I’ve tried to take in as much knowledge and information as possible. It is an interesting place to work, because aside from being a publishing house, it is also a software company called Consonance. Emma Barnes, the CEO of both Snowbooks and Consonance, realised that the world of publishing was lacking an easy and elegant system to perform all the behind-the-scenes admin that goes into producing a book.

I think this amalgamation of publishing and software under the same roof is brilliant. I knew going into this experience that there would be a lot of reading and admin involved, and with Consonance, once I got over my fear of accidentally messing everything up by clicking the wrong button, the process has been so easy! From what everyone in the office has told me, and from some of my own research, publishing in general is quite behind on software, meaning that a lot of the tasks I have easily performed while at Snowbooks would be ten times more complicated somewhere else. I’m very proud to be able to say that I was a part of this group of people innovating the system, even if I had nothing to do with the software itself, having no coding experience.

Rather, during this internship, I have tackled the publishing process from a few different angles, thanks to Emma’s guidance. I spent the first week working with two very different books, both in the process of printing for their imminent release dates. One was an ACE Gamebook by Jonathan Green, which I thoroughly enjoyed exploring. The other was a somewhat meta book about writing by Paul Magrs, which I got completely lost in for a full day. For each book I was to come up with a way to promote it creatively, which was a fun brainstorm. I certainly gained a few skills in terms of research and the use of social media. I’m also proud to say that Jonathan Green ended up using my promotion idea in the end.

Having broken the ice with the finished product, I was then introduced to the scary process of putting it together. I had plenty of terminology thrown at me: meta-data, AI, typesetting, ONIX, P&L… I must admit, I was worried it would all go in one ear and out the other, but Emma is a good teacher, and very open to questions, and the software is designed to help you, and so, as I played around with it, inventing a book concept and creating all the data for it, I learnt. After that I got to go through the submission pile, a task both exciting and arduous, and once I had narrowed it down to a few I chose one of the manuscripts to take further. Once more I put together all the data I could for it, and can now say that I have produced an almost complete external and internal AI.

It’s been such a fascinating experience; from the start Emma informed me that she would be throwing me in to all the worst bits of publishing, so I could be aware of the good, the bad, and the ugly, and make an informed decision about my future career. Though it’s not the most comforting thing to hear when you are starting something new, I’m grateful for this attitude of honesty and helpfulness. I have survived everything so far, which gives me hope, and the whole team is eager to help me or answer my questions.

The idea of an internship can often seem arduous and pointless, especially if (like me) you are finishing your studies and looking at entering into the world of work, but I have found this time to be so useful. It’s been a time of reflection and learning, and it has given me an insight into the industry, meaning I will be informed as I move forward and make decisions about my future. Being at Snowbooks/Consonance has also shown me that a business can be small and independent but also creative and fun. I have felt so at home here, and I am very grateful to have had this chance.”

Money on the table

2019-05-26T00:00:00+00:00

Michael Tamblyn’s keynote at the BISG got a lot of heads nodding here at General Products. Here’s how to put his wise words into effect in Consonance.

1. Local time for local sales

Michael says: “Set your releases for sensible times in different time zones, so Australians can receive their UK- or US-rights-dependent pre-orders before they arrive at work.”

Geographically-specific release dates are communicated in the Supply detail market composite in ONIX. Consonance generates that composite from global dates.

And since there’s a relationship between supplier and territory, it accepts overrides of supplier-specific dates.

2.Market sensitive pricing

Here are two prices in ONIX: one NZD, one INR.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
  <Price>
    <PriceTypeCode>01</PriceTypeCode>
    <PriceQualifier>05</PriceQualifier>
    <PriceStatus>00</PriceStatus>
    <PriceAmount>49.95</PriceAmount>
    <CurrencyCode>NZD</CurrencyCode>
    <CountryCode>NZ</CountryCode>
  </Price>
  <Price>
    <PriceTypeCode>01</PriceTypeCode>
    <PriceQualifier>05</PriceQualifier>
    <PriceStatus>00</PriceStatus>
    <PriceAmount>1999</PriceAmount>
    <CurrencyCode>INR</CurrencyCode>
    <CountryCode>BD</CountryCode>
    <CountryCode>IN</CountryCode>
    <CountryCode>LK</CountryCode>
    <CountryCode>NP</CountryCode>
    <CountryCode>PK</CountryCode>
  </Price>

Michael’s point is not set a price. It’s set the right price for the market. Straight currency conversion almost never works, he says. It always ends up too high or too low.

This requires strategic thought: but how do you execute on the strategy you come up with?

So we have code behind the scenes which takes your price, and converts it according to your business rules into other prices: rounded, corrected, and optimised to perfection. We call them Price Directors. Here’s one, which is how we get a price from Belgium Euro to French Euro via the correct mathematical route. It’s quite readable, once you get your eye in:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
    def change_eur_inc_from_belgian_to_french_vat_via_exc
      builder.
      with_working_prices_as(
        currency_code: ["EUR"],
        price_type:    ["02"]
      ).
      for_tax_regime_be.
      assign_taxes.
      to_excluding_tax.
      strip_tax_components.
      for_tax_regime_fr.
      assign_taxes.
      to_including_tax.
      change(countries: ["FR"]).
      store_working_prices
    end

We have price directors that take GBP inc-VAT price values that you specify and add in the tax components automatically, and ones that send prices exclusive of tax instead, and ones that send agency prices based on your RRP prices as well. All in, Consonance is a hugely powerful tool for pricing management.

3. Use your rights.

Michael says: Because ebooks are so fantastically easy to sell across borders, use your rights to sell everywhere you can. Fix your data to make those books available in all the countries open to you, not just here at home.

Consonance provides shortcuts to enter the territoriality of rights: no-one should have to type in country codes. But the level of granularity you should be striving for is territorial rights at the price level:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
    <Price>
      <PriceTypeCode>01</PriceTypeCode>
      <PriceQualifier>05</PriceQualifier>
      <PriceStatus>00</PriceStatus>
      <PriceAmount>49.95</PriceAmount>
      <CurrencyCode>AUD</CurrencyCode>
      <CountryCode>AU</CountryCode>
      <CountryCode>AW</CountryCode>
      <CountryCode>BV</CountryCode>
      <CountryCode>CC</CountryCode>
      <CountryCode>CK</CountryCode>
      <CountryCode>CX</CountryCode>
      <CountryCode>FJ</CountryCode>
      <CountryCode>FM</CountryCode>
      <CountryCode>GS</CountryCode>
      <CountryCode>HM</CountryCode>
      <CountryCode>KM</CountryCode>
      <CountryCode>MH</CountryCode>
      <CountryCode>MP</CountryCode>
      <CountryCode>NC</CountryCode>
      <CountryCode>NF</CountryCode>
      <CountryCode>NR</CountryCode>
      <CountryCode>PN</CountryCode>
      <CountryCode>SB</CountryCode>
      <CountryCode>TC</CountryCode>
      <CountryCode>TO</CountryCode>
      <CountryCode>TV</CountryCode>
      <CountryCode>VU</CountryCode>
      <CountryCode>WF</CountryCode>
      <CountryCode>WS</CountryCode>
    </Price>

With data refined at the supplier level too. Here, we’re defining the countries that Amazon can supply in:

1
2
3
4
5
6
7
8
9
10
<SupplyDetail>
    <SupplierName>Amazon</SupplierName>
    <SupplierRole>08</SupplierRole>
    <SupplyToCountry>AD AE AF AG AI AL AM AN AO AQ AR AS AT AU AW AX AZ BA BB BD BE BF BG BH BI BJ BL BM BN BO BQ BR BS BT BV BW BY BZ CA CC CD CF CG CH CI CK CL CM CN CO CR CU CV CW CX CY CZ DE DJ DK DM DO DZ EC EE EG EH ER ES ET FI FJ FK FM FO FR GA GB GD GE GF GG GH GI GL GM GN GP GQ GR GS GT GU GW GY HK HM HN HR HT HU ID IE IL IM IN IO IQ IR IS IT JE JM JO JP KE KG KH KI KM KN KP KR KW KY KZ LA LB LC LI LK LR LS LT LU LV LY MA MC MD ME MF MG MH MK ML MM MN MO MP MQ MR MS MT MU MV MW MX MY MZ NA NC NE NF NG NI NL NO NP NR NU NZ OM PA PE PF PG PH PK PL PM PN PR PS PT PW PY QA RE RO RS RU RW SA SB SC SD SE SG SH SI SJ SK SL SM SN SO SR SS ST SV SX SY SZ TC TD TF TG TH TJ TK TL TM TN TO TR TT TV TW TZ UA UG UM US UY UZ VA VC VE VG VI VN VU WF WS YE YT ZA ZM ZW</SupplyToCountry>
    <AvailabilityCode>IP</AvailabilityCode>
    <ProductAvailability>20</ProductAvailability>
    <Price>...</Price>
...
</SupplyDetail>

In Consonance, to get this level of nuance, all I have to do is choose from the presets in the contract.

So we’re setting sales rights data in the contract – in a couple of clicks, using presets – which mean the author and agent is super-clear on what rights have been licensed. And that same data is used to produce the ONIX, so trading partners are similarly super-clear as to what’s available, where. Say it with me: one version of the truth, for the win.

4. Test price elasticity

Kobo …automatically re-promote titles that have experienced price drops, giving them coveted space on home pages, recommended lists, and CRM email. Compelling reasons to make strategic price changes throughout the life of a product.

You’ve seen that managing prices in Consonance is both comprehensive and low-touch, making bulk price changes and sophisticated conversions trivial to manage. In addition, Consonance’s discoverability pages have links to a range of retailers for that work, for easy access to online data.

5. Add series data. Every damn time.

To unleash this sales beast, says Michael, of the ease of selling series products, all you have to do is populate series metadata in a way that is consistent *and* machine readable, which means using the same format across the whole series. Amen.

We make series a first class citizen of Consonance. It’s there on the products page: here’s the Black Road series products:

And we provide checks to remind people that this is data worth adding.

Products can belong to more than one series.

And this tagging clearly works. Amazon set up series pages based on this data: no manual intervention required by the publisher.

Here’s the brilliant Canelo’s latest, all tagged up correctly:

Which lets people click to see the whole series:

6. Power up your synopses.

Michael reveals that indie authors pay good money for premium blurb writing services. You can be sure that anything this guy writes, he says, talking about one such blurb writing service, isn’t going to include “Now for the first time in paperback” in a blurb about the ebook.

The mortification! Blurbs for ebooks mentioning other formats. Blurbs for print formats citing the mellifluous tones of the audio book narrator. We see them all the time.

Whilst Consonance can’t write a good blurb for you, it can save you from this peril. Apply different short descriptions to different products to avoid the mortifying paperback-mention-in-the-epub-or-audiobook-blurb scenario Michael invokes, on the metadata page.

Furthermore, Consonance can check whether there’s a short description present; whether there’s just one of them and whether it has both enough and not too many characters.

Better metadata, better sales.

As Michael says, “what goes in those ONIX files becomes the store that we present to the world. And we want it to be a great one.” I think we’re doing our bit.

The hidden dangers of spreadsheets

2019-04-01T00:00:00+00:00

A cannabis-growing firm recently had to issue an embarrassing correction to the financial authorities for underreporting their losses. Reason: an error in a spreadsheet. They’re not alone: for instance, the “theory” behind the Tory government’s woeful austerity programme was based on a spreadsheet error. Errors in spreadsheets are rife: indeed, a study from the University of Hawaii found that 88% of audited spreadsheets have an error.

At General Products Ltd, we develop consonance.app, the leading publishing management system. In professional, modern software development, it’s a given that when we write code, we test it. Each piece of code has a corresponding test that ensures the code works now, displaying and calculating what it should — and, crucially, continues to work in the future when other changes are made. Every time new code is written and deployed, all the thousands of previous tests run, providing assurance that none of the new code has broken anything. Spreadsheets, however, are like the most unreliable code: they have no tests. And no one wants their business to depend on untested, unreliable code.

Another problem: spreadsheets don’t enforce validation. Good programmers write validations to restrict the data that can be stored in a particular field. But spreadsheets, without validations, allow for harmful duplication. Whilst on-boarding new clients to Consonance, we’ve seen some doozies in old unvalidated spreadsheets. Take contact information. We once saw an author’s name spelled 17 different ways. The name was something like Professor J.D. Pope; the spreadsheet contained entries such as “Pope, JD”, “Prof Pope”, “Professor J Pope”, “JD Pope, Prof”, “Prof J.D. Pope”, and on, and on. It made it impossible to know which books were written by which real-life person, and which royalty payments had been made. And it’s why identifiers such as the ISNI (ISBN13s, but for people and organisations) and ORCID have taken off in popularity, particularly in academic publishing where academics’ careers depend on publishing credits.

The danger is even more insidious than mere error and duplication. In an increasingly-complex publishing world, “one version of the truth” of data is a baseline requirement. The moment you put data into a spreadsheet, though, it’s prone to be emailed to eight people, who save it to eight desktops, and edit it eight times each, often, in the case of P&Ls, to get cells to reflect the number a person wants. And if any or all of them are printed out on A3, further scribbled edits are too tantalising to avoid.

Before you know it, there’s real confusion about what the price is, what the revised manuscript delivery date is, what the pub date is — because there’s the system version, and the Printed-Out-Colourful-A3-Spreadsheet-From-Someone’s-Desktop-From-Tuesday version. Add that to the PostIt-Note-on-So-and-So’s-Monitor version, the AI version, the Nielsen version, and the Second-to-Last-Email-in-the-24-Email-Thread version, and it’s a recipe for disaster.

Not only that, but publishers have let themselves become used to reading spreadsheets, nasty, denormalised things that they are, that lead to monstrosities like the ghettoisation of ebooks, when one row contains information about the paperback but also, as an afterthought, the ePub ISBN13. As Edward Tufte wrote in his seminal The Visual Display of Quantitative Information, “give to the viewer the greatest number of ideas in the shortest time with the least ink in the smallest space.” Spreadsheets trample over this notion. A beautifully-laid out advance information sheet is much more readable and interpretable than a 42-column row on a spreadsheet. Publishing deserves its software to be able to present our information in the format that’s right for the viewer, whether computer or human: sometimes as XML, sometimes as an API endpoint, sometimes as an iCal feed to a calendar app, sometimes as a Slack notification, sometimes as a beautiful fixed-format PDF, sometimes as a re-flowable ePub.

So this is a rallying cry to confirm your likely hunch: spreadsheets can be a dangerous way to run a business, and the wise publisher will seek to mitigate the risk they pose. If you aren’t at the stage where you need a purpose-built system, you must build a standard into your spreadsheet and stick to it.

Nine hard-earned pieces of advice for publishing start-ups

2018-12-01T00:00:00+00:00

Being an indentured employee is how most people pay the bills. But about 12 years ago I started down a different path.

I’m the founding CEO of ~~two~~ three companies: one publisher, one software house, one publishing platform. It’s been a hell of a decade-and-a-half, and I’ve learned plenty along the way. I’d never actively persuade someone away from the perceived comfort of receiving a steady paycheque at the end of the month (although you’re only ever a couple of months’ notice away from insecurity): people have to really want to strike out on their own. But if you’ve ever daydreamed about being in control of your own fortune, and are considering setting up a new company in the publishing sector, read on.

Make your mistakes on other people’s money and time

The best thing about working for other people is that you can use their resources to learn, to test and to explore your ideas. The first seven years of my career (at a global retailing group and then as a management consultant) was a boot camp in how organisations, customers and supply chains work. And even though your new venture will have fewer people than most companies (at least at first), the same lessons about human nature, politics and influence apply. At an established company, you learn which products and processes work, and which don’t. Reflecting on the reasons can help you with your own business planning. Most of the time, of course, the lesson will be in how not to do things, but that’s just as useful.

Know your domain, solve real problems

When I started Snowbooks, I knew nothing about publishing. I just figured that making books would be much nicer than making PowerPoint slides (I worked for Deloitte, and I was right). Snowbooks became known for its innovation, mainly because we didn’t know what the norms of the industry were. Things that we considered to be a fairly sensible approach to things turned out to be interesting and new. But I did know retailing and business process, and so I could talk to buyers at the large chains in a way they appreciated. Later, when we started our software venture General Products in 2011, it was because we knew only too well what sort of software a publisher needs, having run one for more than a decade, and having desperately needed a decent, affordable system which we ended up writing ourselves. Knowing the intricacies of your industry, from whatever your angle of specialty, means you’re more likely to achieve product-market fit from the start, without all of this “pivoting” that the kids talk about nowadays.

Interrogate your values and do something that matches

You may as well keep working for the man if you’re going to set up a company that doesn’t make you happy and proud. I reflected on what made me properly happy: it came down to caring about one’s craft and having a life with the minimum of arguments. So I set things up that way.

Stick with what you’re good at.

It’s true that I’ve spent the last five years learning a brand new skill: how to code. But that’s still entirely compatible with the sort of person I am: learning new things and practicing till I’m perfect plays to my innate strengths. Managing people and doing non-product-related, non-revenue-generating admin, on the other hand, I’m hopeless at — which is why our team is small and I choose alternative ways to grow the businesses, such as automating processes. For too long, previous employers tried to get me to become someone that I’m not. Life is a lot more enjoyable when you play to your god-given strengths.

Don’t be someone else’s product

I’ve been guilty of chasing things that make me feel better about myself which don’t necessarily contribute to the health of the businesses. Having a boss means you get a pat on the head when you do something well, but when you’re your own boss, that validation is missing. I seek to fill that gap from time to time by entering business awards. It feels nice to put on a frock and get a round of applause. But these things rarely bring any actual money in. In a small business, every waking hour has to be spent on either product development or revenue generating activities. Entering awards, going to peripheral conferences: it’s a way for someone else to make some money out of you. Arthur Attwell, founder of now-folded Paperight, wrote about this eloquently on Medium.

Be organised so you can focus on the creative

There are lots of things that you have to do for the first and only time when you’re setting up a company. You have to register with all sorts of organisations: HMRC, Nielsen, the Data Protection people, Companies House. And then, once you’re set up, there’s no end of stuff you have to do just to keep the show on the road. Royalty calculations, contract management, supplier invoices, bookkeeping, printer negotiations, metadata management, sales report aggregation: all this and more can fill your days entirely so that you don’t have time left for the actual creative challenge. Whilst it might seem odd for me to say it, considering that I hawk our publishing management software for a living, you don’t necessarily need to buy any software when you’re tiny. You just need to be super-methodical, and organised. (And use Google docs and other cloud-based software, because no-one backs up their hard drives enough.) Recently, the manager of a new start-up told me he likes to keep all his data in his head. Why fill your head with ISBNs, pub dates, multi-currency retail prices with their tax statuses, and royalty rates when you could keep more interesting, creative, bookish things in it instead?

Be adequately capitalised and cut your costs to the bone

It is very, very hard to make money. Think about how willingly you’d relinquish a whole £600 — how amazing the product would have to be, how much time or effort it would save you, how much your life would have to be improved. Then think about how far £600 after tax and expenses goes towards your monthly bills: it’s a drop in the ocean. How many books do you have to sell to just cover your monthly costs?

Go to the warehouse and look at a pallet of 250 copies of a novel. It’s a pretty huge pile. Think how hard it would be to sell all of them, and then calculate how much money you’d make if you did somehow sell them all (Answer: about £200, all told.) That’s the gap I have to fill every day and, honestly, it’s energy-sapping. You have to really hate the idea of being an employee, and really love building your own world, which, thankfully, I do.

When you’re planning your new venture, divide your estimated sales by three and multiply your estimated costs by four. If your new venture still makes sense, you’re on to something. If it doesn’t, think creatively. Can you excise printing costs altogether and keep things digital? Can you use POD effectively? Can you invert the usual publishing cash flow curve and crowdfund? Can you remain salaried for 12 months until you have a revenue stream?

Eat your own dog food

This rather strange saying comes from an anecdote about a premium pet-food factory, which employed actual humans to taste-test their product. If it was good enough for the dogs we’re hoping to feed, they reasoned, it should be good enough for us. I use my own Consonance software every day to run Snowbooks. With my coder hat on, I’ll write a new feature — tracking review copies, for instance — and be all pleased with myself. The next day, with my publisher hat on, I’ll start to use the new functionality. ‘Who coded this rubbish,’ I’ll mutter to myself, ‘it’s difficult to use and doesn’t take into account the fact that I need to track 50 copies in one go, not just one book at a time.’ So I’ll rewrite the code. Rinse and repeat, back and forth. Add it up over seven years and you end up with software that’s pretty useable, and focussed. Same with the books: I’ve got a copy of a book we published in 2007 in my bag today. I’m enjoying the cover design and the paper stock we chose and I’m loving rediscovering the story. If you expect other people to enjoy your products, you should enjoy them yourself.

It takes a long time to be an overnight success

The lens we see success through tends to collapse timescales. You’ll read a profile in The Bookseller of a company doing well after a prize win or similar, but it’s hard to fathom the years of effort that led to that moment. Running your own show is emotional hard graft. You’ll only know if you have the stamina to work for years on the knife edge of cost control if you try it. But worst case? You’ll end up having to get a similar job to the one you’ve got now.

I said I wouldn’t actively persuade anyone to branch out on their own. But life is short. What do you want to look back on with pride? What will your legacy be?

Grants and sources of funding for software development

2018-11-12T00:00:00+00:00

Ring the good news bell! We have been awarded a ~£20k Innovation Support for Business government grant.

ISfB is a £5.2 million programme to encourage innovative business ideas within small and medium sized enterprises (SMEs). As part of that, Go-Create Grants are available on a competitive basis from £1,000 to £50,000 for innovation projects within tech and non-tech businesses. The application process was rigorous and required us to demonstrate the value of delivering key aspects of our development strategy, which is creating software that harmonises publishers’ workflows.

Software development is an expensive undertaking, but we keep our prices as low as possible to bring the benefits of “one version of the truth” to as many publishing professionals as possible – so support from grants like this is really helpful. It’s also good to have the importance of our innovation validated from government outsiders: we had to compete with other business sectors for this grant so it is heartening that publishing is seen as a worthy sector of support.

Here is a launch video produced by Oxfordshire Local Enterprise Partnership (OxLEP) in which Andy and Emma appear at the 56 second mark!

Grants are one way to fund software development, and is viable if you have a compelling case that aligns well with the funders’ objectives. Another avenue we have benefited from is the UK government’s R&D Tax Credits programme. That’s a case of asking your accountant for advice, but it’s well worth it if you are innovative and undertake R&D.

Book machine unplugged

2018-10-01T00:00:00+00:00

On the road again! Emma & Sara were on a Book Machine panel with Lola Odelola and Janneke Niessen to share our stories and our mutual sense of the potential of tech in publishing, as well as to draw attention to the hurdles that need navigating in order to use tech well.

There’s a comprehensive write-up by Abbie Headon which is well worth a read.

What’s great about this sort of event is the promise that we might have budged someone, who may otherwise have faltered, in the direction of discovering the liberating joy of code. So we were delighted to receive multiple emails after the event from people who have applied for the next RailsGirls event. Do apply now: we’d love to see you there!

SYP Oxford Coding at the Castle

2018-09-20T00:00:00+00:00

Last night, two of us (Emma & Sara) were pleased to be invited to speak at the Society of Young Publishers’ Coding at the Castle event, along with Ben Bisset. We promised to publish some notes and provide links to the resources we recommended: here they are.

Emma’s slides

Emma both wielded a stick and dangled some carrots in an attempt to provoke and inspire the full-house audience to improve their technical literacy.

Here are her slides. And here’s her code-as-poetry.

To run it, open up IRB (which stands for Interactive Ruby).

If you’re using Mac OS X, open up Terminal (Google open terminal mac) and type irb, then press enter.
If you’re using Linux, open up a shell (Google open shell linux), type irb and press enter.
If you’re using Windows, install Ruby, then open Interactive Ruby from the Ruby section of your Start Menu

You’ll be at a prompt, just like a a blinking cursor at the start of a Word document. It will look like this:

Paste all the code in to the irb window. Then press enter so that the irb console can accept the code, ready to execute it at your command.

You’ll see the prompt again. Paste in the following text to execute the commands.

send_the_jacket_to_the_shops(my_books)

Notice if anything happens, and read back through the code to see if you can follow what happened.

Then paste in the following text, press enter, and see what happens:

my_books.each { |book| book.send_if_approved }

Sara’s slides

Sara wowed folks with code that allows Harry Potter to defeat a dementor. Here are her slides.

Resources

Here are the resources we mentioned:

Consonance publishing and tech blog
Consonance documentation
Non-technical intro to ONIX
Ruby code and why you should care
Menial jobs are destroying your future “Word” and “Excel” are not “IT skills”. They are typing. We recruit young, pretty women (go on, deny it), and we give them secretarial jobs.
A Designer’s Guide to XML & InDesign
15 minute Ruby tutorial
Learn Enough to be Dangerous (Highly recommended reading to every last person in publishing)
Rails Tutorial (create Twitter!)
PR Coverage tool (the pricing is higher than I remembered, sorry. All the more reasons to write your own!)
The Pickaxe Book
Ruby Mechanize. Their guide is good.

Please keep in touch and let us know how your foray into coding goes. We’ll be here for you!

The clouds have parted... introducing Consonance

2018-09-08T00:00:00+00:00

After a 10x increase in customers, Bibliocloud has outgrown its start-up roots to become a mature and sophisticated enterprise software product now called Consonance.

The last three years have seen General Products Ltd enjoy successive double digit growth, a 10x increase in customers, and a handful of major industry awards wins. In celebration of our achievements, we are proud to announce a new identity to better reflect our position as the leading hands-on expert in publishing process, software and data management.

CEO Emma Barnes, who also founded and runs 15-year-old indie publisher Snowbooks and schools publishing start-up Make Our Book, says:

“Our tight-knit team of publishing and technology experts has worked quietly and steadily since 2011 to cement our position as the go-to provider of modern, affordable software for small- to medium-sized publishers. We are delighted to unveil a new identity which provides assurance to current and future customers that we are the right choice of partner if they want to dramatically improve their data quality and operations capability to grow their business.”

Speaking on the reasons for the rename, Barnes explains: “It’s a question of differentiation. The word ‘biblio’ doesn’t differentiate us from other products and implies we are limited to bibliographic data management, when in fact our system spans the full range of publishing operations from acquisition and workflow to royalties and beyond. Additionally, ‘cloud’ software is no longer the point of strategic difference it was when we started in 2011: most modern software can be accessed over the internet. Moving away from both ‘biblio’ and ‘cloud’ is an opportunity to align our brand identity with the points of difference we’ve worked hard to make our own: expertise, modernity and customer success.”

The new name for Bibliocloud is “Consonance”, which means harmony and agreement – a nod to the software’s ability to harmonise publishing teams and smooth the publishing process. The new identity is also accompanied by a new logo, style guide, social media handles, a new website, re-written documentation, and a simplified user interface in the app.

Light logo (download svg)

Bibliocloud – known as Consonance from 10th September 2018 – is the publishing system of choice for over forty trade and academic publishers.

The Consonance team will be on the road speaking at two upcoming publishing tech events:

We will be competing at Deloitte’s The Pitch on 14th September, having been shortlisted in this year’s competition. We will be interviewed at VentureFest Oxford on 12th September, and we’ll be at the IPG conference on 18th September.

And we’re showcasing various parts of our redesign process here on our new website, including the clients’ books that inspired the new colour palette, telling our brand story through design, showcasing our beautiful publishing software and providing behind the scenes technical insights.

At this pivotal coming-of-age point for us, we say thank you to our brilliant clients who inspire us, and who have been a joy to work with over the last few years. It’s all for you and your imaginative, important, transformative books, which the world so badly needs at present. We’re grateful and proud to be a part of your story, and look forward to the chapters to come.

This post is part of our branding series:

The clouds have parted… we’re rebranding!

How we unbranded our software company

No longer an oxymoron: Beautiful publishing software

The technical story

The technical story of our rebrand (for non-technical readers)

2018-09-07T00:00:00+00:00

Everyone in our team is a programmer. But we also cover all the other business functions between us, such as sales, design, and customer success, so we like to think that we combine the best of both worlds: deep technical knowledge as well as business savvy.

And so in both Consonance’s UI and our communications, we’ve been working to provide a coherent, consistent experience to people, whether they’re a current or prospective user of Consonance. As well as the logo and other design elements, we want the Consonance UI itself to project our promise:

to harmonise publishing businesses’ processes, by sharing our expertise through our app and all our communication, so our customers sell more books with less effort.

To do that, we needed to revise the navigation. This was because:

The navigation appears on every page but its code was slow to run – making every page slower than it could be.
The design of the navigation was odd: a fairly standard bar down the side for the global nav, but then a bar along the top, intersected by another local bar, with dropdowns. This was not an extensible pattern, and caused some user confusion and unpleasant visual tension.
The palette of the navigation was a rather alarming coral red, which users told us was off-putting. Red for danger!

We needed to provide a solid foundation for all the development we want to do in the future:

To have code that ran quickly
To be able to extend the code in ways we couldn’t yet imagine. This is at the heart of object-oriented programming: our code needed to be revisable. The first chapter of Sandi Metz’s Practical Object-Oriented Design is inspirational on this topic.

We ran three 6-week pieces of work to redesign our navigation, two in parallel. Inspired by Basecamp, this year we’ve adopted the approach of working in 6-week blocks. It’s a great way of keeping scope tight on a project, and keeping momentum going. Having delivered three huge projects using this method this year – the navigation, the home dashboard plus grid implementation, and our data checks functionality – we are completely sold on it being the right way for us to work, to deliver value, quickly, and to help us plan and execute our work in a productive, low-fuss way that we trust.

At first, we thought the work would fit into one 6-week block, but the beauty of the approach is that we can re-scope as we go along.

The kick-off meeting took an initial stab at the scope, and laid out our objectives (which were informed by user feedback from our annual survey, and individual tickets and conversations with users), but avoided big design up front:

The project ended up being as follows (with the main person doing the work in brackets, with discussions between us all at our daily meeting):

Pre-work:

Deciding the technical approach. React? Pure Rails? Stimulus? Turbolinks? An off-the-shelf component such as Atlassian’s? (Andy)
Planning the links themselves and the terminology to be used (Emma)

First 6-week block:

The creation of the React component, and its implementation for the global sidebar (Andy)
The design of the page header (Andy)

Second 6-week block:

The refactor of the component, so it could be re-used for the local sidebar (Andy)
The breadcrumb and header code (Andy)
New pages required including an exports page and revised work and contact pages (Andy)
The implementation of the global nav, page header, breadcrumb and local nav (Emma)

Parallel 6-week block:

the home dashboard and rework of index pages made more visible by the new nav (Sara)

The planning stage falls outside of the 6-week cycle. In fact, it’s fair to say that our thinking about the new navigation has been ongoing for a number of years, although we started planning in earnest on this project around February 2018. We’d done some preparatory work, such as the removal of legacy bookmarks functionality in favour of using browser bookmarks, and we’d started to think through solutions for managing both global and local navigation. Here, for example, is an early Adobe XD mock up, inspired by Atlassian’s navigation component (the password is V8kUZKTT). Mock ups like this showed us the benefits and flaws of each approach we considered, and let us prototype ideas quickly. We also employed spike branches of code to good effect in this and other projects – creating throwaway code that let us rough out an approach without worrying about test coverage or code quality whilst we’re still at the dibbling stage. Some code survives these spikes, but the idea is that anything goes, to encourage creativity.

Here are some of the tickets on the JIRA epic that we used to manage the detailed work of this project.

Side projects

Another aspect of our work which had a huge effect on our ability to undertake this ambitious project was our practice of Friday afternoon side projects. Senior programmer Andy deepened his understanding of React by embarking on his own very ambitious side project: miniatures painting recipe app Paint Pad. His project enabled him to spend meaningful amounts of time delving deep into how React can work, and provided assurance and proof that we could use it on Consonance. We are huge fans of side projects as a safe, motivational way to try out new technologies on the job.

Programming

The planning stages gave us enough insight to allow us to decide to roll our own React component, and to write it as an engine.

Here it is, sitting alongside some other engines (checks, dashboards, and our importers, for example). This keeps the code nicely organised, and easier to work on in the future, rather than dotting around every corner of our monolith to find all the relevant code.

Here’s one of the files for the ONIX area. It’s known as a decorator, because it takes raw data and decorates it to make it presentable for appearing in the UI. You can see RuboCop — our automated code-quality evaluator — complaining about the length and the ABC size of the method: perhaps we’ll refactor that in the future.

We were particularly pleased to be able to write a React component that could have multiple instances: both the global and the local sidebar are instances of the same component.

Testing

The navigation feature has unit and integration tests. Here is an integration test to check that the global nav appears as expected:

Here is the fixture — or previously saved file — that is used as a comparison, when the test on line 28 runs. Imagine the test runs and draws its output on tracing paper. The test overlays the tracing paper version on the fixture version. If all the pixels line up, the test passes. If not, the test fails and we know we need to fix the code before deploying it.

Here’s an example of a unit test for that ONIX decorator.

Implementation

The rollout of the new nav was quite laborious. Each view in the app (there are over 500) needed the addition of:

The breadcrumb
The current page
The appropriate local nav
The appropriate header

And we made CSS changes on:

Links
Buttons
Fonts
Search bar
Colours

The difficulty was compounded by wanting to avoiding having a long-running feature branch, with a frightening big go live at the end. Instead, we wanted to be able to merge the new code into our main branch as we went. This problem was solved with the marvellous Flipper which meant we could allow beta users to access the feature before it was made fully live, allowing us to take on board feedback in a timely fashion.

After the final feature was presented to clients and had a favourable reception, we stripped out the flipper code and all the original nav code too, which removed many hundreds of lines of legacy code.

We shipped the new nav two weeks before the main Consonance rebrand announcement, to decouple the implementation of this major new feature from the hullaballoo of the actual rename.

Website

As well as the major navigation project in Consonance itself, the marketing website, which you’re reading now, has had an overhaul. It is a Middleman app, a static site generator which allows us to write in Markdown and HTML. The styling uses CSS grid, with fallbacks for older browsers provided by Modernizr. It uses SVG graphics for crispness, and our new brand colours and fonts. It has been pleasing to migrate all our documentation data from a third party to easily-maintained Markdown files, and to write a complete style guide.

Roll out

The third major technical aspect of the rebrand was the change of domain name and emails. This required a lot of project planning, considering:

API calls to Consonance
References to the old bibliocloud.com emails
Heroku custom domains
FTP locations
Social media handle updates
AWS configuration
Other third party integrations
DNS updates
Clear communication to all relevant players

Summary

The rebrand has been a fantastic opportunity to address the long-running desire we’ve had to improve the intuitiveness and code quality of the navigation, and we’re really pleased it’s been such a technical success and so well received by our customers. And it lays the foundations beautifully for all the exciting developments we have planned on our roadmap. We feel that the way we conducted the project was also in line with our values of harmony and expertise, modernity and customer success, which we’re really proud of.

This post is part of our branding series:

The clouds have parted… we’re rebranding!

How we unbranded our software company

No longer an oxymoron: Beautiful publishing software

The technical story

How we unbranded our software company

2018-09-07T00:00:00+00:00

The Consonance promise is:

to harmonise publishing businesses’ processes, by sharing our expertise through our app and all our communication, so our customers sell more books with less effort.

How do you communicate a desire to share knowledge and improve sales through colour, imagery, tone and design?

With difficulty, it turns out. We’ve been on an eight month journey, wrapped around the day-to-day running of the business. We wanted to find a way to communicate our message, and so we embarked on a rebranding exercise. However, we chose not to hire an agency, not least because the cost of an agency rebrand is not to be underestimated. In any case, as we dug deeper into what we were trying to achieve, it became clear that design has very little to do with, well, design.

First, we had to distill our message down to its bare essentials. The fuzziness that our early messaging displayed (‘Make businesses better!’ ‘Help publishers be efficient!’ ‘Encourage more effective data!’) meant it was too vague to be encapsulated by a logo, a typeface, a palette. The design process we needed was as much to hone our message and our intent as anything. I’m not sure that an agency could have done that hard, personal work for us, other than be expensive facilitators to make us ask and answer the right questions.

We used a number of tried and tested management devices to whittle our story and plan our strategy. The Business Model Canvas. The Customer Success movement. The all-customer survey. The rather dated, yet trustworthy, SWOTs and 7Ps and balanced scorecards. We got a great business plan out of all the work and varied approaches:

But one of the most compelling and relevant tools was to use Jungian archetypes. Stay with me…

Brand archetypes

Carl Jung said that there are a limited number of archetypes that reside in our collective subconsciousness. These archetypes are used wherever story is found, repeatedly through history. This is a particularly pleasing concept for a publisher to enjoy: try to think of a story that doesn’t have an Underdog, or a Jester, a Caretaker, Rebel, Sage, or Hero.

In their own way, brands are stories, too. Our own story is that over time we have worked to amass certain secret knowledge — programming, ONIX, how retailers work, the secret to hitting the publication date, how to get Amazon to index keywords — and our purpose is to enlighten publishers who seek to pursue efficiencies and achieve either enlightenment, or higher sales, or both. But we have to fight to get our knowledge out there, our foes the incumbent legacy players in the supply chain, who don’t want to have to innovate or change. Like Dumbledore, we are the Sage, tempered with a dash of Rebel to liberate us to speak plainly and call out complacency.

The Sage as a planning framework

The Sage/Rebel archetype provides the perfect shorthand to represent our message. It also provides a helpfully restrictive framework, because having less choice about tone and voice makes for clearer messaging. What font style should we adopt? Something Sage-like: solid and trustworthy, timeless and also contemporary enough to indicate that we are a software business as opposed to, say, a day spa. What tone of voice should we adopt in our documentation, articles and interface labels? One which projects Sage-like confidence, establishes authority, and communicates complex information clearly, without condescension and with the objective being to impart knowledge, not to crow or obfuscate. We’ve captured the details of how we achieve this tone in our style guide.

What sort of logo should we adopt? This is where our message had to be very clearly articulated before we could start. We want to communicate that we are a trusted partner, one which shares knowledge and provides insight and infrastructural capability through our app that help publishers grow. An upward trending line, coupled with that icon of stability — the triangle — made up of many smaller triangles spoke to the team effort, solid infrastructural underpinning, sales uplift and simplicity that beautifully encapsulates our message. Read more about our logo in this post.

Light logo (download svg)

From here, with the fundamentals locked down, further refinements were easier. We were inspired by our customers’ books themselves in defining our new palette, to be used throughout our interface and messaging.

The checks page show some of the colours, hard at work: Nasty Red from 404 Ink, Boundaries Green from UCL Press, and Reimagined Gold from Academic Studies Press. All 48 accessible colours are presented in our style guide.

Unbranding

In all, the process of realising our position as a teacher and enabler, and the feedback from our customers which prove that we’re achieving our goals, gave us the confidence, ironically for a branding exercise, to mute any brashness or attention-grabbing. Our voice is secondary to the bigger aim of getting knowledge and insight into our customers’ hands.

So gone is the sweet shop candy-coloured old interface, and fuzzy messaging, in favour of the papery, quiet tones and solid, deep expressions of expertise that allow customer results and insights to take centre stage. And gone is any mention in the UI of our brand. Instead, we have created high-quality SVGs of each of our clients’ logos, which sit proudly on their sidebar. It’s our clients’ space, not ours.

Rather than rebranding we have, to some degree, unbranded. Our success is, after all, our customers’ success. So read our thoughtful, informed writing about the publishing supply chain and data standards. Absorb our in-depth, opinionated, experience-based advice. Learn from our clients’ successes in our case studies. Notice the insights our customers get from their use of the system. And draw your own conclusions about our brand from the evidence.

This post is part of our branding series:

The clouds have parted… we’re rebranding!

How we unbranded our software company

No longer an oxymoron: Beautiful publishing software

The technical story

No longer an oxymoron – beautiful publishing software

2018-09-07T00:00:00+00:00

In early 2011, our CEO Emma Barnes sat at the kitchen table and wrote the first lines of Ruby code for Bibliocloud, a system created to manage her publishing company Snowbooks’s data efficiently, so she could ditch the drudge and focus on publishing creatively.

The idea was always to build a system both beautiful and functional: a system where you wanted to spend the best part of your day; a system which provided you with everything you need to run the business, smoothly and intuitively. A system whose design was so good, it gave you what you needed and got out of the way, so you could get on with publishing.

Seven years later, what started as an in-house dream is now a fully-fledged, mature software business staffed by publishing and technical experts, with a wide range of professional, academic, scholarly and trade publisher clients around the world sharing in that original vision.

We deliver a lot of value, and we have always done that with some style. But despite clients a year ago telling us that they liked the clean design of the software, which was vaguely based on Google’s Material Design, we knew that we could do a lot better, in particular on consistency. Consistent design, across all communications, whether that’s through software or not, removes a layer of mental effort.

Light logo (download svg)

To achieve coherence and consistency, we had to formulate a look and feel across a number of different elements. Here follows a list of those elements, designed to complement each other and work to form something greater than the sum of their parts.

Product name

The name Bibliocloud has felt generic and over-literal for a while. Lots of software includes the word biblio in their name. And cloud is hardly a noteworthy feature nowadays: calling attention to it feels embarrassingly early ‘00s.

We chose Consonance for its lyricism, its literary connotations and its meaning: harmony, agreement and compatibility. Our intention with the software is to bring harmony and smoothness to our customers’ data and workflows. Consonance reflects that beautifully.

Font

The font is from the Mont family: Bold with optical kerning for the light logo, with Semi Bold used with a 0.5pt stroke and manual kerning for the dark logo to counter the irradiation illusion.

Dark logo, using the lighter Mont Semi Bold and adjusted mark (download svg)

We chose this font for its symmetry, consonance between letter forms, its simplicity and boldness. We use this font elsewhere in applications of our identity, such as the website.

Mont hard at work on the website, paired with Lato 400

Logomark

The logomark is an upward trending line, built with that icon of stability, the triangle, made up of many smaller triangles. It speaks to the importance of team effort and solid infrastructural underpinning. It says that we are a trusted partner, who provides the building blocks of publishing capability.

The Gestalt principle of closure also serves to reveal the hidden triangles within the mark, made in whitespace.

The logomark: made up of lots of little triangles, including the whitespace

Further triangles are revealed from the text alignment guides.

The text aligns along logical divisons to create more triangles

The mark is, in all, the essence of stability and growth.

Variations

There are a number of variations to the logo, including a lock-up with a descriptive strapline.

Variations and lock-ups

Colour

The logomark purple is our brand colour: Trusted Purple, taken from our new colour palette. The key primary and secondary colours are named after some of our clients’ most striking book cover designs. The style guide contains all 48 colours.

Applications

We’ve designed all the components of our identity – font, colours, primitive triangle shapes, the name and the logomark – to be malleable and put to work across a range of media, both now and in the future.

Among the most important application, of course, is in our software. The rebrand included designing new navigation and implementing the new colour palette, for a knocked-back, papery, quiet feel that lets clients’ data shine.

Consonance’s interface: works

The checks feature embodies our message of expertise, providing insights into your data in rich ways to guide you towards selling more books.

Consonance’s interface: checks

Website design

Blog design

Presentations

Report layout (this is a spread from our business plan)

In conclusion

This eight-month-long in-house project has resulted in a strategic, coherent, flexible identity that communicates our core messages of expertise and stability, within our software and beyond. And, without doubt, it’s also a way to celebrate and showcase the effort we put into our development process. Yes, Consonance is a back-end admin app. But why shouldn’t business software be beautiful? Our customers have to live in their software for their entire working day. It’s unacceptable that such a large part of your working life should be spent mentally unpicking confused interfaces and workflows. So it’s our own working life’s work to make yours better.

This post is part of our branding series:

The clouds have parted… we’re rebranding!

How we unbranded our software company

No longer an oxymoron: Beautiful publishing software

The technical story

Ruby code and why you should care

2018-04-09T00:00:00+00:00

Ruby is the primary programming language that Consonance is written in, chosen for its readability and maturity. And last month, we were lucky enough to spend a thought-provoking and inspiring two days at the 2018 Bath Ruby conference.

I know that if you’re reading this post, you’re likely more interested in books than code. But I think you would have enjoyed the conference.

Because so much of Ruby is about the things that bookish people love. Ruby is about story, and its shifting shapes. It’s about becoming lost in something so beautiful you forget about time. It’s about feeling that you belong, and that your work matters, and that whilst much in the world might be awful, there are pockets that you can carve out for yourself which make everything worthwhile.

In the same way that books have history – and by books I mean everything from story and character to author relationships and production values – Ruby has history. There’s a rich, deep context to this language’s development and use which gives it grace and humility.

Publishing, as an industry, is not a fad or a flash in the pan. It has the quiet, solid confidence that comes from having been around for 500-odd years. In absolute terms, the Ruby programming language is young: a mere 25 years old this year. But in computer years, that’s about as established as it gets. And Ruby has the feeling, like book publishing, that we’re all in it for the long term. We can sagely ride the peaks and troughs of fashion, and wisely tolerate the bright frenzy of the new, because there are timeless truths at work.

Those truths will be familiar to you. The importance of clear words to convey complex thoughts, simply. The need to be kind to those around you, in order to get their best work. The fact that it’s the dance, not the destination, which matters. The idea that it’s the relationship between notes, not the individual notes, which make music.

The reason why I wanted to mention that we’d been to a Ruby conference, though, was not to draw parallels between code and books, fascinating and relevant though it is. It was to explain why you should care about our code.

One line in one talk in particular jumped out for me at Bath Ruby. Valerie Woolard, in her talk about code and coding as art, said your clients don’t care about your code. Only you care about your code.

This troubles me. She’s right. Why should you care about our code? It’s like me caring about what sort of pipes the plumber uses when they come round to fix a leak: just so long as the tools they use stop the leak that’s wrecking the furniture, I don’t care.

But our code affects you a lot more than the plumber’s choice of pipes affects me.

Not all code is created equal

Before I was a programmer, I fell into the trap of thinking that code was code: it either existed or it didn’t. I failed to realise there could be good code and bad code. You can have two web pages that, to the casual observer, look exactly the same and do exactly the same thing. But the code that renders them can either be diabolically complex, repetitious and strangely structured, or elegant, terse and readable. You might not see the difference, but it matters what’s under the hood, because the quality of the code affects how easy it is to edit, and how likely it is to break with new data, system upgrades and interactions.

Not all programmers are created equal

I also fell into the trap of thinking that programming was programming: you could either do it or you couldn’t. Of course, turns out reality is more complex. The gulf in capability between a struggling beginner and someone with thirty years’ experience is vast. And there’s nothing to say that becoming a good programmer is a function of sheer hours put in. There are plenty of okay programmers who’ve been at it for years. What I feel is that good programmers are those who work hard to understand the fundamentals of their specialism, such as object orientation, and apply that to their daily work. That means a lot of admitting that you’re wrong and being open to change: not traits that everyone is blessed with.

Not all teams are created equal

There are yet more things I didn’t realise. Good code is created by a team, not an individual. It’s the process of conversation, of peer review, of coaching up and down and sideways, of being able to change your mind without embarrassment, of having honest conversations without ego, that creates good code.

Good code doesn’t write itself

What is good code? It’s readable. Simple. Considerate to others of all abilities. The sort of code that does what it says on the tin. It’s well-structured, well-tested, so that if later code breaks it, an alarm goes off. The famous Mark Twain quote about not having enough time to write a short letter, so he wrote a long one, holds true: good code, like good writing, is the result of editing, reflection, redrafts and rigour. It’s the result of craft.

Good code comes from the right environment

So good code doesn’t happen unless you put the infrastructure in place for it to be created. We still have some legacy code from the very early days, but then we built the right team, the right working environment, the right strategic message that says where we work, quality is the most important thing. We don’t have client-facing deadlines. We don’t have death marches. We’re not flat-out perfectionists because then nothing would get shipped, but we don’t cut corners and accrue technical debt.

Good code futureproofs you

Why should you care? The code we write is good and maintainable, which means that when you contact us to ask for a change or an improvement, we can probably incorporate that change because we have built the code to be edited. It’s not a dangerously-teetering stack of cards, brittle to the touch. It’s well-organised, with test coverage and sensible conventions.

And because we write good code, we’ll also know when it’s wrong to incorporate your suggestion – because our spidey-sense will tell us that it would result in a garbled interface, strange convention-breaking or misplaced complexity. Much better to enquire what the business reason is for your suggestion to get to the root of the problem and fix that, than expect our customers to be systems architects.

This is a rather strange conference write-up, being about code quality rather than the actual talks per se, but the thing about Ruby is that it gets you thinking. And I write this on the eve of the London Book Fair 2018 – another event in the calendar that gives one a chance for reflection and inspiration, for seeing the bigger picture and the shape of the winds of change.

We’re one of the more technically-minded teams present at the book fair, I expect. Perhaps people like us are meant to embrace and exploit trends such as blockchain and the like. But that’s not for me. Craft, harmony, pride and doing the job properly have to define the future so that the code we write, that our customers rely on, rides out shrill trends and remains solid, planted and long-lived: just like the book trade, just like Ruby.

'Continuing to solve real problems': Futurebook 40, London Book Fair 2018 and the Works page

2018-04-07T00:00:00+00:00

Just in time for the London Book Fair this week, check out the new works page.

As you probably know, we’re making our way through the list pages in the system, applying the patterns we’ve designed and standardised in our component library. So far we have improved:

Products
Contacts
Royalty runs
Royalty statements
Schedules
Tasks
Contracts
ONIX fragments

And now, Works joins the list of improved pages. Now that it’s a far more useful page, we would encourage you to try it out, because it provides a lot of information in one place:

Work level information, with links to refined lists of works with the same subject
The products list
The list of contributors, arranged in sequence order descending, with roles, contact details, professional affiliation and tags, just like on the main address book page for consistency.

London Book Fair 2018

We’ll be there with bells on, and this year, as members, we’re thrilled to be exhibiting on the ALPSP pavilion, which is in the National Hall, Stand 7C19, on the ground floor. Do come and say hello to us and the ALPSP team.

Futurebook 40

In other news, I was delighted to be included in the Futurebook 40 list of innovators this week. Thanks to The Bookseller for recognising my work on Consonance as an important innovation for publishing. Here’s my face amongst some other great faces:

From The Bookseller article:

…What the Futurebook 40 can do is provide a representative selection of the innovative work going on around books. On the inaugural list, you’ll find a mix of disruptors working from within the establishment, entrepreneurs rapidly proving their worth, and hungry new talents just starting to elbow their way in. You’ll find publishers, agents, writers, booksellers, academics, events organisers, designers, illustrators, consultants and a good few hybrids. You’ll discover people innovating across every area of the industry—in a way that is focused on solving real problems, rather than simply getting buzzwords in the press.

Here’s to continuing to solve real problems!

How many authors is too many?

2018-03-29T00:00:00+00:00

How big is your company’s contact database? How many authors has your company ever published? How do you fancy inputting each of them one-by-one into your chosen publishing system?

In academic publishing, a single book can have dozens of authors — even more than a hundred. Who wants to input all of these names one-by-one?

Individually filling in each name and associating it with a work — or even associating fifty authors already in your system with a new work — can be an endless tedium of clicking.

However, the tedium must be endured because each of those fifty authors brings along an interested audience. Each and every one of those names can have a direct impact on sales if it is included in the metadata of the book and disseminated properly into the supply chain. (Even if an ONIX recipient does not read or catalogue 100+ contributors to a work, you still need it in your metadata management system.)

Enough with the tedium! Down with the clicking! The answer to “How many authors is too many?” should be “There’s no such thing.”

Consonance is proud to launch our bulk contact importer, which can bring in brand new contacts, update existing contacts and/or associate contacts to a work via any of the ONIX compliant contributor roles.

You can now import:

All contact name fields, whether key names, a single name or an organisation name
All address fields, from standard street addressed down to sub-building detail level
A biographical note, ISNI number, ORCID, In-house customer ID, In-house supplier ID, Phone number, Fax number, Website, Email address
Professional affiliations to existing or new organisations

You can update all of those fields via the Consonance contact ID. You can associate a contact with a work via Consonance work ID and a ONIX contributor role.

Not only will the contact importer help you get in large amounts of contact data fast, it will validate all the incoming data to make sure that you are getting it right the first time, and corrections won’t be needed in the future.

ORCIDs, ISNIs, email and website formats, ONIX compliant contributor roles and more are all validated before getting into the system; we’re doing sense checks on phone numbers and post code/country matching; we’re checking that the information is not already in the system.

You can be confident that the importer does what you expect it to, because the code is covered by fully automated tests that describe the exact behaviour of what we want the importer to do.

What does that mean? Well, there are 177 examples of expected results that are programmatically checked every time new code is added to the system. If something changes, the test will “break” and the new code won’t be allowed in until the test is fixed. There are 23 scenarios - or overarching user requirements - that are broken down into 270 individual steps that are also checked every time code is changed.

1
2
3
4
5
6
7
8
  Scenario: Viewing a contact import error messages
    Given I have uploaded "two_invalid_imports.xlsx" for the client "Fauxbooks"
    And the draft items for the "contact" import "two_invalid_imports.xlsx" have been validated
    When I am on the "error" messages page for "two_invalid_imports.xlsx"
    Then I should see the following messages:
      | Column name | Data                 | Error                    |
      | Website     | iainduncansmithorguk | Website invalid          |
      | ISNI number | 0000 0004 047195     | ISNI must have 16 digits |

We know our importer performs as it should now, and that it will when the system changes in the future, because we’ve created a program to check that it does. Automation is a beautiful thing.

So, once you’ve got your contact data together, challenge the Consonance importer on the question of “How many authors is too many?” Because, to a computer, one takes pretty much the same amount of time as a thousand — and that’s what automating your administrative work is all about.

When I joined Consonance as a developer last year, I said I wanted to build the publishing system I wish I had as an editor. Today, the editorial assistant part of me is doing a happy dance.

The insiders' guide to an ONIX file

2018-03-13T00:00:00+00:00

There’s a new way of seeing your previous ONIX in Consonance. It’s called the ONIX fragments page and it looks like this.

What are ONIX fragments?

ONIX fragments are pieces of XML which contain a single product’s data at one particular point in time. Here is a small ONIX fragment, with very little data because the book was cancelled.

ONIX fragments are the building blocks of an ONIX message. An ONIX message is the large file that gets sent to data recipients from Consonance, and it contains lots of ONIX fragments: one per product.

Click on the row on the ONIX fragments page to see an example of your own data.

The reason for this new page

This new page came about because we field many sensible questions from clients about their ONIX:

When did the ONIX last go for this product to my distributor?
Has data for my product been sent in ONIX to my distributor / Nielsen / etc?
Which book data has not yet been sent in ONIX to my distributor / Nielsen / etc?
What ONIX has my distributor received?
Which contacts are set up to receive ONIX and when?
How do I set up a contact to receive ONIX?
How do I ensure that Amazon receive the sort of ONIX that they say they accept?
I want to see the vanilla ONIX for my product, and the Amazon flavour
Did this image / epub file go out in ONIX?

We wanted to make answering these questions more intuitive, to save our clients’ time so they don’t have to ask, and to save our time so we don’t have to answer.

The project

This new page is the first of quite a few which are still in development. Here’s how the project has gone so far.

The first stage was to brainstorm and review all the questions we’ve received over the last year or so, which is how we came up with that list of questions. The project, we knew, needed to allow clients to get answers to these frequently asked questions.

The approach

We don’t usually do this, but this time we decided to try Documentation Driven Development, which I think we’ve made up, but it might be an actual software development approach.

Here’s how our (currently unpublished) documentation page looks like for these new features.

The idea here is that the docs are drafted, and will be gradually replaced by real screenshots.

This has proved really helpful, as a developer. If you ever write code, you’ll know that there’s a question and answer website called StackOverflow. It’s an old joke that most questions posted to StackOverflow never get posted, because the act of writing out the question answers it. We found the same in writing out formal documentation: it was a great way to check that the code we were planning to develop was going to answer real user questions, in an explainable way.

You’ll also see some ticket numbers and developer notes in those docs.

These relate to our JIRA project management board. The ONIX epic looks like this.

Next steps

We have another eleven tickets’ worth of development to do before this piece of work is complete. But you can see that the work we’re doing is customer-question led, and so will hopefully be a helpful addition to Consonance which will save us all time and effort.

Update, some weeks later!

All these tickets are now complete so now you can track an ONIX file from soup to nuts in Consonance.

Burleigh Dodds Science Publishing

2018-03-12T00:00:00+00:00

Burleigh Dodds Science Publishing are just three years old, but the founders come from rich stock, being former directors at Woodhead Publishing. Burleigh Dodds use ‘smart-publishing’ to help achieve ‘climate-smart’ agriculture. As Editorial Director Francis Dodds says:

It is widely recognised that agriculture is a significant contributor to global warming and climate change. It has been estimated that agriculture is responsible for 10-12% of greenhouse gas emissions. Agriculture needs to reduce its environmental impact and adapt to current climate change whilst still feeding a growing population.

Consonance partnered with Burleigh Dodds to provide specific metadata management features that have underpinned their ability to deliver this important content via a new publishing model. And we’re particularly excited to share our story now, because Burleigh Dodds have just won the Nick Robinson Newcomer Award at the IPG Awards 2018.

Congratulations to @bdspublishing, winner of the 2018 Nick Robinson Newcomer Award #ipgsc #ipgawards2018 pic.twitter.com/v3p6lwDLP9
— IPG (@ipghq) March 9, 2018

The vision

We first met Rob Burleigh in the John Lewis cafe in Milton Keynes – a suitably central meeting point for our two companies, based in Oxford and Cambridge respectively. At that meeting, Rob sketched out on the back of a napkin his vision for the metadata management environment for his newly-founded company.

Experts in their field would be invited to be series and book editors. The books would contain contributions from further experts, sometimes up to 40 chapters’ worth. And Burleigh Dodds’ key point of difference? The ability to manage each of the chapters as its own work.

As chapters were delivered and edited, Burleigh Dodds would publish them as standalone ebooks, delivering the time-sensitive subject matter to the readership as soon as possible. When all the chapters were delivered, Burleigh Dodds would publish one large combined work, derived from all the chapters and linked in the metadata system, in hardback and ebook, with the option of combining chapters in multiple ways in the future to create new products with a different main focus.

Consonance would need to accommodate this complex work derivation model in order to help. And we did want to help, because it was evident that Burleigh Dodds were going to be changing the world for the better in more than one way, and we wanted to be part of that story.

The development

Armed with the napkin, and full of enthusiasm for a new enhancement to Consonance which we felt would help not only Burleigh Dodds but other clients with multi-layered work relationships, we established a formal development project. This project did the following:

Designed the underlying system architecture to relate works to each other.
Designed the UX: users create an original work at any level of the hierarchy, which can then be used as the basis for a derived work, or be the parent work.
Allowed metadata on the combined works to be derived automatically from the chapters, saving tedious and error-prone manual data entry for long contributor lists and tables of contents.
Planned the enhancements to the ONIX feeds to select partners able to ingest and interpret this part of the ONIX standard.
Communicated with Rob at Burleigh Dodds to iterate on our plan, to ensure it was meeting his strategic needs.
Developed and tested the code to deliver the new feature.

The commercial side

We also confirmed back to Burleigh Dodds that our pricing model would not penalise them. In practice, the derived work approach meant that on day one, Burleigh Dodds had thousands of products in Consonance, although from a traditional publishing point of view they only had around 15 main works. Other bibliographic systems that charge by the product made it impossibly expensive. Our more flexible approach of pricing by the user meant that Burleigh Dodds could have thousands of products in the system, for £55 / user / month.

The result

In short order, Burleigh Dodds were able to store their works at a much richer level than previously possible. As well as the new derived work functionality, they immediately understood the importance of rich metadata. They also chose their distributor very wisely. We find Plymouth-based NBN International to be by far the best UK distributor and are able to ingest our enhanced ONIX feed without a hitch, which includes:

Related products
Derived works
Multi-part tables of contents, automatically generated in Consonance from the derived work associations and structured in valid XHTML
Multiple, ordered Thema, BIC and BISAC codes
Multiple contributor associations: helpful when some of the derived works had upwards of eighty contributors
Marketing texts, multi-currency pricing
Non-trade products having no ISBN

As a bonus: market-specific AIs

We also developed two market-specific AIs, incorporating amongst other variances different publication dates for North America and the UK and Europe. Perhaps you can spot the differences: they are both produced from the same source data that forms the ONIX feeds. Consonance generates exports in the right format for the recipient, whether they are a computer or a retail buyer.

Conclusion: strategic feature development without breaking the bank

We were honoured to develop this new functionality, at no cost to the client, to fuel Burleigh Dodds’ innovative publishing approach based on the provision of excellent, rich, deep and automatically generated structured metadata. And hearty congratulations to them for winning the Newcomer of the Year IPG award: as close partners we are able to say it is richly deserved.

New website

2018-02-25T00:00:00+00:00

Never ones to rest on our laurels, here’s our new website. In my previous post (originally for our customers’ eyes only, but now public) I promised that, by way of thanks for their helpful feedback, we’d have a new documentation site up and running in the first half of this year. Well, it’s two weeks later, and here it is. And it’s not just a new documentation site. You’ll find our blog (with many archive posts rescued from the Wayback machine after the Digital Book World blog shut down) and useful information about Consonance all in one place. This speedy development is thanks in no small part to the sort of tools that are available to programmers nowadays.

Our new website is a Middleman app, a static site generator. Hosting and a ton of amazing deployment features are provided by Netlify, the single best web app of any type I have ever used. Effortless DNS management comes from DNSimple, and a really great new search is provided by Algolia Docsearch. We’ve got a direct integration with our CRM tool, Pipedrive, on the Request a demo page, which helps us to get back to prospective customers quickly. Testing is done with Rspec, and git version control is done by Github, which has a Continuous Integration, erm, integration with Netlify which builds and deploys the static HTML and CSS files each time we push the code to the main branch. (And, as a minor point of personal pride, we wrote it without any CSS framework, or jQuery.)

All these bulletproof tools mean we have been able to write this website from scratch in our spare time in two weeks. It’s a work in progress, but the structure is in place to build what we hope will be the best bibliographic software website, bar none.

For example, we’ll post news about our new style guide in due course, once we’ve applied all the rules to our existing content. This style guide builds on and complements our component library and brings the sort of consistency of language, tone, colour, typography and more that makes our documentation and application straightforward to use, search, read and understand. Here’s to consistency and harmony!

We’ll also be refining the documentation search, in particular. It’s fresh out of the box at the moment: we’ll be refining it to make sure the top results remain the most relevant, over time. We’re delighted with its speed, relevance and coverage already.

We’ve started to post regular product updates on the blog, too, so do subscribe to our feed or bookmark our blog to keep up to date with product news, as well as our musings. The whole team pitch in with thoughts and contributions, so you can look forward to hearing news from a combination of Sara, Dave, Andy, Rob and me.

I hope you enjoy having a look, and seeing how it unfolds. We’re looking forward to it, too!

2018 Customer survey report

2018-02-11T00:00:00+00:00

This is a long post, so here’s the summary:

* We’re going to work on the things you have told us to work on in 2018

* Skip to the bottom for some exciting news!

Just before Christmas, we once again asked our customers for feedback about Consonance and the service you receive from us, using a short form. We asked you for a score out of ten in response to the question how likely are you to recommend Consonance to another publisher? Then we asked you why you gave that score: What do you like and what still needs to be improved. We also asked what one thing would you like us to focus on in 2018. The results are in, and this post shares with you the results, and what we’re doing about them. Once our customers have all read this post and we have discussed any follow ups, we’ll make this post public.

Methodology

91.5% of respondents gave us at least 5 out of 10, with 61% giving us at least 8 out of 10. Those numbers are fine as far as they go, but the real actionable meat of the feedback is in the written comments, so that’s where we focussed.

We took the comments, and broke them down so that each time something in particular was mentioned, it received a count: +1 for a positive, -1 for a negative. For example, the following answer was broken down into +1s for

+1 Intuitiveness
+1 Everything in one place
+1 Staff support

And the next answer broke down into

-1 Navigation
-1 Validations

The feedback split into the following categories:

Existing features:

Metadata
Schedules
Gantt
Contracts
Production
Royalties
Contacts
Briefings
Imports
Exports
P&L
Works
Search
Validations

New feature requests:

Journal management
Tagging
Summaries / dashboards

Integrations, imports and exports:

Shopify integration
Marketing materials

Usability:

Data entry usability
Data entry duplication
Speed
Navigation
Design
Notifications
Everything in one place
Intuitiveness
Pagination on index pages

Support:

Communication
Client data specific
Staff support
Price
Documentation

A note on the response rate

Thank you so much to the 56% of invitees who took the time to so carefully and generously share their thoughts with us. If this summary doesn’t reflect your own feelings about the system then please do let us know at the next survey. These surveys, followed by the support tickets we receive, are the number one way we prioritise our development work. And, according to the stats, the form took an average of 5:39 minutes to complete, so not too awful! If you want to have a say in how we develop Consonance, the surveys are the best way to let us know, although our ears are always open: raise a ticket to share your thoughts!

Analysis

Here are the main insights that we took away.

The single most popular thing about Consonance is that it provides everything in one place.
The other things you like are the design and the intuitiveness of the system.
The main things you think need work are schedules and data entry.

Key insights

These are the key actionable learnings we have taken from this analysis and used as the basis for our 2018 work plan.

1) Documentation We could do a better job of keeping the user documentation up to date. We push new code almost daily, and it can be a challenge to actually document and notify people about the changes.

What we’re doing about it: We knew we were falling a bit behind on documentation, but for it to be raised as a concern in feedback makes it a big priority. So work has started on improving the infrastructure of the docs, to make them more appealing for us to maintain, and also to make them more consistent. There will be a newly edited version of the docs, with new content and radically improved search, coming in the first half of this year.

Hand-in-hand with documentation goes support. In a review of roles at the start of this year, we have decided that I, as CEO, am best placed to be on duty on the front line, picking up all the tickets. We are big fans of the Customer Success movement, and, by having the chief decision maker fully aware of the ebbs and flows of customer sentiment, we can make sure we keep customers at the heart of the business. It’s a golden opportunity to extend the conversation from just the issue at hand to rootle around in and solve the underlying problems. And it makes the customer service function much more strategic: now I have a very clear insight into both the detail of what customers are grappling with and the larger swathes of their experience, which will feed in to future planning. First response time is down to just over 5 hours (down by 18 hours, gosh) too.

The takeaway? Raise a ticket if you want affect how we work!

2) Schedules are too complex and hard to use.

What we’re doing about it: We’ve heard that you find schedules – particularly the Gantt view – unfriendly to use, and we’ve been working with a core team of customer representatives who are being kind enough to spend time with us to capture the specifics. The survey was taken before the Christmas break, and since then we have released two new important improvements: a new tasks page and a new schedules page. There’s a write up of the work so far, but it’s still work in progress. Please use the new schedules and tasks pages, and tell us what’s still lacking – we’d love to hear from you so we can continue to improve this feature. Notably, if you choose to have a simple schedule with no dependencies between tasks, you can now edit the dates entirely through tables rather than using the Gantt chart.

UPDATE, January 2019: To-dos are now live and schedules are on the path to retirement! Thanks for the feedback! UPDATE, October 2019: Schedules are now retired from the system!

3) Data entry. Much work in 2017 focussed on being able to find and review data better, resulting in a well-received new pattern for pages such as the products, the contacts and the tasks pages, and being able to get data out, resulting in huge performance improvements behind the scenes in ONIX and in a new Advance Information Sheet default. However, being able to get data in remains at the core of the system and there’s still work to be done. A detailed reading of your feedback here reveals that are two things at play, here: the ease with which you can get your data into the system, and the confidence you have about whether this means it’s complete, accurate, timely and optimised for sales.

What we’re doing about it: Two things.

First, Sara is nearly ready to launch her simply amazing spreadsheet contact data importer, and then will start work on another importer for product data. I won’t steal her thunder on it and there will be a full write up soon: suffice to say you will be able to upload, validate and clean contact data from a spreadsheet in Consonance. Game changer.

Second, Andy has just started work on a major new feature which will allow you to check your data in Consonance against any number of rules, and receive actionable feedback about how complete, relevant and accurate your data is. We’re looking at the start of summer for this to be ready for prime time.

UPDATE, January 2019: Data checks went live last summer! Thanks for the feedback!

There will still be more work to do, particularly on the Metadata page. And of course these projects aren’t the only work we do. There is:

Work prompted by support tickets
Ongoing ONIX configurations and improvements
Standardising the layouts of existing pages using our patterns
Integration projects
Other roadmap projects (there’s a post coming soon on our roadmap!)
Here’s a nice insight into the thorough way we work, too.

But both these major strategic efforts will help you to produce better data in a shorter amount of time, in order to sell more books, which is why we have chosen this prioritisation.

Where these plans sit in the wider picture

Customer success is at the heart of what we do, because our own success and revenue model is predicated on recurring revenue from customers sticking with us.

Our value proposition is to provide one version of the truth to the sorts of publishers we feel we can help best, so that they achieve their desired outcomes over time and stay with us year after year.
We say no to potential customers who we feel have a different desired outcome to that which we know we can support – because we know they won’t be successful and won’t renew.
We use many channels to keep the conversation flowing between us and our customers, and have multiple touch points to actively solicit ever-changing feedback. ZenDesk tickets, this survey, specific projects and scheduled calls are just a few of those channels.
Our key activities revolve around building the right system to make our customers successful.

So you can imagine how important the results of our surveys are to us. It’s high customer retention that has driven our results over the last few years (you’ll have to email me privately to ask about the y-axis scale!)

And finally

As part of our endeavours to keep the conversation flowing, we are excited to be organising a Customer Conference in 2018. We hope everyone will be able to make it and so, to help our planning, we would be super-happy if you could let us know what would make it a great day out for you on our survey. We’ll look forward to seeing you there!

This is not the formulaic project management of other industries

2018-02-11T00:00:00+00:00

As publishers ourselves, we know that one of the big challenges of running your company is to manage the vast number of tasks that have to be done on time, and ensure that your metadata meets industry best practices.

We need to constantly create, send, receive, confirm and update systems, or to monitor and help those who do.

We also need early warning that trouble is brewing, which may be due to delays in a manuscript, or unavailability of a proof-reader, or breakdowns at the printer.

All tasks are equal, but some tasks are more equal than others

There are the milestone tasks that you know you need, the headline dates on the big spreadsheet. Perhaps half-a-dozen to a dozen, often representing go/no-go decision points: receiving a manuscript, handover to production, sending the files to the printer, etc..

Then there are the tasks you know you need, but which make the spreadsheet too big to manage. Maybe they are managed at a departmental or functional level, with another Big Spreadsheet for Marketing or Digital. Per department you might have another dozen of these: updating the final version of the marketing copy, confirming the per-unit print price, sending the marketing material to the sales agency.

And then there are the tasks that your people know are critical for heading off trouble, but they’re too small to be on any of your lists. Very often they are the small checks that follow up on another task. Perhaps they’re on a Post-it note, but because you might never know that they are being done, the people doing them never get the credit for helping the business to run smoothly. If they leave then you’ve lost the institutional knowledge that they held and not only do Things Start To Go Wrong, you do not know how to Make Things Go Right Again.

How many of these are there? Who knows, but who is checking that the uploaded cover image has propagated to major retailers before the author notices that they haven’t, or verified that the website has the new price?

For the complete development of a new work you might be officially tracking thirty tasks currently, but below that level there may be one or two hundred.

This is not the project management of other industries, and it cannot be tackled with generic tools or a one-size-fits-all template. It is the coordinated management of an ongoing series of complex projects, with similar structures and their own variations, across a team of in-house professionals and third parties, and is intimately connected with your works, series, products, authors, and metadata quality.

It’s what keeps us up at night.

So what’s to be done?

On a day by day basis, everyone need to have a reliable store of what needs to be done, by whom, and by when, presented through a familiar interface and shareable with co-workers and third parties.

You need to be able to plan at a weekly and monthly level to see what you have coming up, and whether everything has been done in preparation.

Strategically you need to know how soon you can publish, and whether you are pushing your capacity close to the limits.

You want to plan for smooth continuity during periods of maternity and paternity leave. You want to reduce the number of planning and coordination meetings you’re holding, and make them run more efficiently.

You need to identify risk of slippage early, so you can react and re-plan intelligently.

That’s exactly what Consonance does

In Consonance we have developed a system that shoulders the burden of managing this for you, where no task is too small to be recorded, and nothing gets forgotten. Where you can be agile in responding to problems, see trouble approaching, plan your workload, and use your learned experience to continually improve your working methods.

Book your demo today to see it in action and talk through your specific challenges.

A range of Consonance customisations

2018-02-11T00:00:00+00:00

“We see how well you service publishers day in and day out.”

–NBN International via Twitter

We plan our roadmap based on what our customers tell us they want. That means that a lot of “custom” work is actually delivered for free, as part of our ongoing development of Consonance. Here are some of the developments we’ve shipped for specific customers, many of which are fully available to all users of the system.

Work derivations

We added work derivation features to Consonance to enable sustainable agricultural publisher Burleigh Dodds to deliver their strategic point of difference: the ability to manage each of their books’ chapters as its own work. Burleigh Dodds subsequently won the IPG Newcomer Award and achieved BIC Gold accreditation the same year.

RESTful JSON API

“Zed Books had a storming year and Consonance played a big part in our success.”

–Zed Books

We radically transformed Zed Books’ data over two years, and implemented a number of data feeds including a JSON API to their new website. This collaborative investment of time and effort contributed to a 25% uplift in sales for their 40th anniversary year.

Royalty implementation

Vertebrate’s royalty agreements are typical of a successful, mature medium-sized publisher: complex, with a number of edge cases, long-lived backlist titles, multi-author agreements, multiple contract start dates and opening balances. We migrated their legacy data and provided guidance on using Consonance’s built-in royalty functionality. Consonance now produces their royalty statements automatically and accurately, twice a year.

Pharmaceutical Press, the Royal Pharmaceutical Society publishers of the annual British National Formulary, used Consonance to produce an XML export of their metadata, which they imported into InDesign to automatically create their printed catalogue. The result was a sales tool displaying the perfect combination of standardised pages with added editorial creative flair.

Automated catalogue feed

We implemented the Belgian NUR and French CLIL subject classification schemes for Leuven University Press (whose website is fed directly from Consonance), and the ability to automatically translate prices through various permutations such as from Belgian inc. VAT to Belgian ex. VAT to French inc. VAT, to allow them to enter prices inclusive of Belgian VAT then send them to French trade partners in ONIX.

Automated advance information PDFs

“The automation of ONIX metadata to distribution channels saves us a huge amount of time and effort. The relationship with your team allows us to develop our existing metadata, and develop new product metadata and mechanisms too, using Consonance as a source. This is really valuable.”

–Institute of Physics Ebooks Product Manager

We implemented IOP’s advance information sheet design in Consonance, combining the efficiency of automation with the sales benefits of their pixel-perfect design. Now, IOP can export a zip file of hundreds of PDFs in one fell swoop, avoiding copy-and-paste and manual errors.

Advanced advance information!

2018-02-10T00:00:00+00:00

If you are a Consonance client, you have always been able to click a button to download your metadata directly from Consonance into one beautiful PDF layout. You can do that for one, or a thousand, products in one go. It’s a hugely time-saving feature, and one directly related to selling more books.

AIs remain at the core of the selling-in process, taken into all types of sales meetings between publisher sales teams and their customers: at sales conferences, head office presentations, to wholesalers, at Meet the Buyer events, and at store level. We see no sign of them being superseded by technology any time soon!

Over the years, we have often been asked to implement our clients’ own designs in our code, as part of their onboarding. We take our client’s design, and write the code and tests which allow Consonance to produce AIs in that style on demand. We’ve thus had the chance to see all manner of expert designs, and to learn what works and what doesn’t. We wanted to take all those learnings and produce our own super-AI – and make it available to all our clients for free as a built-in benefit of their licence fee.

This has been an important project for us and many of our clients so I thought you might enjoy the background story.

The brief

Back in April 2017 we wrote up a detailed brief of what we needed our new Advance Information sheet to do, and, along with many examples of our existing AIs, sent them all over to super-designer Tom Spindlow. Our Andy had worked with Tom on many successful prior projects and knew him to be an excellent designer.

The sketch

Tom soon sent back his first impressions – keen to reinforce the point that this wasn’t a design, but a sketch, intended to ensure that all the required elements were present and weighted according to their importance.

We did some back and forth, demoting certain elements and promoting others, until Tom had enough insight to be able to provide a second cut.

The design

From there, Tom worked his magic and produced some beautiful, clean designs: one serif, one sans. The idea was that the designs be modular and extensible: as we encountered as yet unknown new requirements in the future, we would be able to incorporate them into the basic layout.

At this point we could share the designs with some key clients who we knew were looking for new ideas for their AIs, and refined the design further based on their feedback.

The programming

At last, the programming could begin! Andy implemented a future-looking design pattern which would gift us the option to adapt this feature in the future, whilst only doing the programming that was needed at the moment. We pragmatically adjusted the spec to deliver the project in the most time and cost-effective way, balancing the desire to achieve design perfection with the need to deliver value for our customers as rapidly as possible.

The testing

In order to check that Consonance produces AIs as expected, we don’t just click on a few links to see what happens.

Our development process

When we write code, it’s on our laptops, on a copy of the main codebase called a branch. Imagine a tree: the trunk of the tree is the official codebase (called main), and our branch of code is an offshoot, which we can edit without sullying the official version.

Before we share that code with anyone else, we write automated tests to make sure that the code does what we expect it to do and that it’s formatted according to our style guide. We run these on our computer. Green dots mean the test has passed, red means it’s failed, and we can find out what the problem is. We can run tests just for the bit of code we’ve edited, to save time, as the whole test run takes about twenty minutes.

We then share that code with colleagues on a code storage service called Github, using something called a pull request to invite comment and sign-off. It’s called that because we request that our new code is pulled into the main version of the Consonance codebase.

When the code has been buffed to perfection, it’s approved by colleagues and merged into the main branch. It’s now ready to be deployed to the real website.

If the code has been in development for a long time, there will be many tens, even hundreds, of cycles of pull requests. On this project, there were 13 main pieces of work, each with multiple pull requests and commits to the feature branch:

Depending on the scale and nature of the change, we will either send that code to the Consonance website, or to a test or demo website for review.

Before the code is allowed onto the live website, it runs through a continuous integration service called Codeship which runs the whole suite of our tests again. So if our change has broken something inadvertently in a far flung corner of the application, this process will catch the problem before the code is released.

If the code is a proposed structural change, we will often configure it so that users can flip between the old and the new version, until we have solicited feedback and everyone is up to speed.

Special sorts of tests for PDFs

Normally our tests look a bit like this:

or a bit like this:

These tests check what the data is, or how the browser looks, in certain circumstances. But PDFs are neither data nor browsers, and needed something extra. As well as testing the classes which generate the data, Andy came up with a new sort of integration test to see whether the generated PDF was exactly as expected.

First he generates the AI, programmatically, which we store in our codebase:

Then he wrote tests which generate that same AI, using the current version of the code, and literally overlay one on the other to see if there are any differences. Any differences get reported on; the test fails and we can amend the code to make sure that our changes haven’t altered the expected behaviour of the system.

The launch

Once the feature was completed and all the necessary tests written, we pushed the code to the main site. We will be inviting all clients who don’t have a bespoke AI template to review their data in our new format, and hope that they soon begin to enjoy the benefits of this rigorously produced design through selling many more books, as a result!

Zed Books

2018-02-09T00:00:00+00:00

Zed Books had a storming year in 2017. In this post, we explain how Consonance played a part in their success. It’s a great case study and an inspiring example of a publisher really committing to a long-term vision and seeing it through. Here’s how the journey began, how it evolved, and what we’ve achieved to date.

Zed Books in 2014

Zed Books came to us three years ago with an ambitious plan. They aspired to modernise their systems, transform their data and invest in a major rebrand. Adopting Consonance was one of their first and most fundamental steps to meet their objectives:

Invest in a three-year transformation project
Improve metadata to improve discoverability and sales
Automate a supply of rich content from Consonance to a new website
Automate ONIX feeds to third parties
Invest in bespoke AIs and press releases to convey Zed Books’ brand

Metadata transformation

We provided hands-on support and advice to import Zed Books’ data from their existing system - both products and also contacts. We worked over several months to review, complete and optimise their metadata to improve discoverability of front and backlist - for example, adding in secondary contributors and keywords. A nice example was adding the well-known travel writer Hilary Bradt to the metadata for Thank you, Madagascar as contributor of the foreword. The book now also appears in searches for Hilary Bradt on Amazon and other retailers, improving discoverability.

An automated workflow

Automated daily ONIX feeds to Nielsen, NBNi and other recipients, including POD arrangements to NBNi
Automated bespoke AI, Author profile and Press releases, designed to match new Zed branding (as below)
Partnership with Zed Books’ developers, Burgess and Beech, to power the new Zed Books website with the Consonance API feed.
Streamlined the set-up and maintenance of our API by making it possible to find out if data has changed instead of checking every product.

Reflections

As one of our earliest clients, Zed Books’ success is very satisfying and the result of huge amounts of work on both sides - and much learning along the way. It’s brilliant to see the benefits of a single, reliable source of truth play out in a really impressive website (one of the best in the industry) - and higher sales. Zed Books are unique in their business model and their mission to champion marginalised voices is increasingly important in our changing times. As they mark their 40th anniversary, we’re especially proud to be supporting them and look forward to many more successful years.

Takeaways

Good data is the backbone that makes creativity possible. When you trust your data source and can automate and flex it, you can do the creative branding that helps you sell more books. Contact us to see how we can help you get your data into Consonance and optimised for better sales.
If you’re considering building a new website, Consonance can supply your book data automatically. Our API is documented here. Using the Consonance API, you and your developers have the freedom to design the website that’s right for your business, while Consonance provides an accurate source of your data. Check out Zed Books’ website here, and as below.

Hidden benefits of a single source of bibliographic truth

2018-02-08T00:00:00+00:00

I’ve noticed an interesting side-effect to using Consonance. If you use one of the features that presents data in a human-readable way, it completely alters your data-management-motivation levels.

Take websites. Over Christmas, I released the new Snowbooks.com website. From the design point of view, I hope it’s good: legible, navigable, easy on the eye, a great showcase for our wonderful books, and helpful for customers to be able to choose where they can shop.

(As an aside, from the technical point of view, it was a complete joy to write. It’s a Jekyll app, which is a way to write static websites. That means you use the Ruby programming language to combine data about your books with templates for the website to create all the HTML files on your computer, then upload the finished files to the internet – you don’t rely on a server to draw together data on the fly. And it uses the response from a request to Consonance’s API as its data source. As part of General Products’ Side Project Friday Afternoon Initiative, I’m preparing the code to be open sourced, so hopefully other people might consider writing adapters to other data sources. Drop me a line if you’re particularly interested!)

The point is that when I was developing this website, it made me want the pages to look good. I mean, I was spending time creating something which is our shop window. I wanted it to look as nice as possible. And, with that hat on, one’s eye is drawn to ugly blanks and missing data. Cue a big flurry of metadata updating, as I variously:

uploaded higher-resolution images when the one I was pulling from Consonance was a bit on the fuzzy side
made sure everyone was credited, and in the correct order
made sure the latest reviews were front and centre

and, most interestingly

came up with new series groupings of books which, post-publication, I decided sit together nicely on the page. Welcome to the world, Snowbooks Gothic, Snowbooks Fantasy Originals and friends! Which additionally appeared on websites around the world the next day, as ONIX carried the good news:

It might be a bit extreme to spark up brand new series on a whim, but it’s interesting how seeing your data presented in a new way can inspire new ways of looking at the list. And now the books are related to each other in a new and discoverable way in our ONIX.

Catalogues

As a minimum, it certainly makes you notice where data completion could be improved. Treasured client Pharmaceutical Press used an XML export from Consonance to populate their catalogue this week, and found the same thing as me: their bundled student packs now include images where previously the metadata hadn’t necessarily needed to be so rich. Their catalogue benefits from another image, and in the process, almost as a side-effect and certainly with no additional work, their metadata is that much richer.

Advance information sheets

The classic part of the system that prompts this sort of work is the advance information sheet. We’re all guilty of only getting our data up to date when we need it for the sales conference – and it makes it so much easier to see data when it’s in a human readable format. I often output a whole bunch of AIs as a ZIP file in one go from Consonance, and flick through them on Finder on my laptop, to get a sense of whether I’m pleased with the blurbs, the pricing and so on.

Crowdsourcing quality

When you put your data into a human-readable format, you hope there’s a chance that a human other than yourself might read it. This is great: the more eyes the better. This just in from prized and beady-eyed author Jonathan Green:

The right format for the job

Consonance is not just about getting data into a format suitable for computers to share: just as valuable is getting data into a format that works for your brain. I’m a sucker for a pretty picture, but I’m happy that it’s improved my metadata quality.

So where are we with the frontlist?

2018-02-06T00:00:00+00:00

It's the question everyone in publishing dreads.

Like Anna, an editorial assistant at your medium-sized academic press. She went into publishing because she loves books, and has a real eye for language. But her job just seems to be updating Nielsen, the distributor, and myriad spreadsheets – and she's behind. There were a load of price and pub date changes at yesterday's production meeting: more copying and pasting for her.

Then there's managing editor Tom, who joined to help grow the academic social sciences list. But his time is consumed with trying to keep things on track. Did we say at the handover meeting that we are delaying twelve February titles because the line edit wasn't finished? Is anyone managing the freelancers?

And there's Juliet, a commissioning editor, who knows for sure that five out of the seven authors on her list will be late delivering their manuscripts. Again.

Juliet craves just one clear day to work on her list's strategy – but she's always busy firefighting. Everyone wants desperately for the list to grow, but there's too much confusion, too many moving parts.

Forget growth: keeping the wheels on is hard enough.

Sure, there's the rickety old ONIX database, and the publishing schedule on Excel. But everyone uses their own spreadsheet. There's endless copying and pasting into the distributor's system, to Nielsen and Bowker and Lightning Source and Coresource, to the Waterstones and Barnes & Noble grids, to the wholesalers: there's no way they all match.

Casting your eye around the office, you see multi-coloured A3 print-outs of scribbled-on spreadsheets, and monitors festooned with PostIt notes, providing further cause for concern.

More dates. More changes. More mismatched versions of the truth.

You long for some perspective. Do all publishers work like this? Surely there's a better way?

Imagine if there was.

What if your whole team – from editorial and sales to production and marketing – shared one system they didn't hate, set up from spreadsheet and ONIX-based importers that handle your enormous backlist and muddled contact data.

That checks not only the presence, but the quality of your data.

That automatically syncs with external systems. Coresource, Nielsen, retailers, wholesalers, your contracts, rights and royalties records, University systems, JSTOR, EBSCO – up to date, all the time.

That generates custom spreadsheets and beautiful advance information sheets, professionally designed to sell, just as easily as ONIX and JSON API feeds. The right format for humans, the right format for computers: both from the exact same source.

A system accessible from anywhere – Frankfurt, conferences, home offices, key account meetings – which the whole team edit at the same time on the web.

That assigns the thousands of to-dos in any publishing season to the right people, and relates them to a meaningful date. So when the print pub date moves, or the manuscript delivery is late, the relevant to-dos move in the system, and also in your team's Google and Outlook calendars.

A system backed up by unlimited access to publishing management experts, who've seen it all before and pool the combined knowledge of hundreds of other publishers who've overcome the same problems you're facing.

Instead of digging through endless conflicting spreadsheets, Post-its, notebooks, brains, email threads, Outlook contacts, Slack messages and Word docs: imagine the harmony from having a single, expert publishing system.

One that's beautiful, comprehensive, searchable, and a joy to use.

As publishers ourselves, we lived, breathed and suffered through the same problems you and your team face every day, for 15 years. No more. Publishing is hard. Consonance makes it possible.

If your team had the tools to work in harmony with each other, think how much time they would have to do the actual creative work. They can:

Coach and manage authors, breaking down the writing process into smaller deliverables, increasing the chances of delivering their manuscripts on time thus fixing the greatest source of pain in publishing: late manuscript delivery.
Sell more books. Writing better copy, briefing sales reps better, crafting manuscripts properly: adding the value that humans add best, expending effort where it can best be turned into revenue.
Use the insights from better-managed data, and the bibliographic tools provided, to innovate in their publishing: remixing backlist content, generating an audio books programme, or researching new imprints and partnerships.
Do the work instead of firefighting.
Stick around longer, because work is a pleasant place to be.
Result? Better organised, more creative, and under control.

Our rapidly-growing successful publisher clients don't have to dream. This is their reality.

And you don't have to imagine, either. Efficient publishing management doesn't have to be a dream. Growth is entirely possible. Our innovative, thriving clients prove it. We've love to talk to you about how you can join them. Book your demo today.

2017 in review

2018-02-06T00:00:00+00:00

It does give me a more than mild sense of vertigo to think about how much we’ve done. And whilst, at times, the tumultuous happenings in the wider world have felt overwhelming, Consonance continues to be a meaningful and tangible thing that I can do to help make the world better. We are honoured to be able to bring more organisation, more fluency, and more time to be creative to our publishers. And by freeing them up to do the work that matters, we can know that we’re helping them produce more of the sorts of books that will steer the world towards something better.

Books matter. It matters to us that we’re helping in their creation, and that the way we go about helping is something to be proud of, in itself. To those ends, our big moments of 2017 were oriented towards our goal of making our customers successful, and doing it in style.

Sara O'Connor joined the team!

As part of our plan to build a crack team of the best programmers in publishing, in April Sara O'Connor joined us as a full stack developer, bringing our technical team count to four and giving it a pleasing two-women, two-men gender balance. Sara was formerly editorial and digital director of Hot Key Books, a Bonnier imprint, who retrained as a programmer at Makers Academy, before working for business data company Exceedra. Domain knowledge is one of the hardest parts of programming: finding a team member who knows publishing and programming is rare and brilliant. Sara hit the ground running, first reviewing and improving the test suite for our royalties functionality and then diving into a hugely ambitious long-term project to allow user-controlled contact, product and other data uploads to Consonance. The fruits of her labours will be revealed in early 2018, but for now it’s enough to say that it’s a dream come true for me to be able to watch people such as Sara reskill and reorient their whole career towards something they know makes a difference.

Sharpening our focus on customer success

Throughout 2017, one of our main ambitions has been to get better and better at delivering customer success. The year started with a bang as we won the IPG GBS Services to Independent Publishers award in February, as nominated by our own customers, so it was nice to know that we were heading in the right direction.

Huge congratulations @Consonance on the IPG Award; we see how well you service publishers day in and day out… richly deserved #ipgawards pic.twitter.com/FsJLnW0GbD
— NBN International (@nbnibooks) February 9, 2017

In March, Emily instigated a rota for our online ticketing helpdesk, making sure that there was always a team member dedicated primarily to managing queries, and over the course of the year we have better than halved our response times to support tickets. It was great to talk later in the year in October at Frankfurt with many of our customers, all of whom reported that things are going great. Vidisha at Zed Books, for example, credited Consonance with underpinning their recent amazing success, which makes you tingle all over. (The link takes you to their stunning new website, proudly fed from Consonance via our API). And then, as we close the year in December, the results of our latest Net Promoter Survey are coming in, and they’re looking really good. (More in the new year about those results and feedback, and how it’s driving our plans for 2018.) We’re so pleased that our efforts are helping you succeed.

Listening

Because we’ve orientated ourselves towards customer success, we’ve also got better at listening. By hearing where customers have had twangles, ideas and troubles, we have been able to focus our efforts on the work that really matters to them. All in all, our stats show that we deployed 200 discrete pieces of work, ranging from maintenance tasks such as THEMA code updates and new integrations; small improvements such as adding fields to API feeds; the occasional bug fix; and major features such as:

a better, more usable, faster search functionality
a better products page
a better contacts page
a better tasks page
better royalties pages (and a special shout out to Liverpool University Press and Vertebrate for being the leading clients on that endeavour)
improved contract templates
better briefing notes

And coming in early 2018 are the fruits of our most recent efforts:

universal data importers that feed back on data quality and validations
a new default advance information sheet, designed by Tom Spindlow
a better schedules page

Using tools and partnerships to improve our own processes

We’re in the business of writing tools which help our customers run their companies more effectively, so it stands to reason that we would try to be as efficient as possible in our own work. A festive shout out to the partners who help us support you: Graham at Editeur, IPAC, Nielsen, Burleigh Dodds Science Publishing, the completely brilliant NBNi, ALPSP and the IPG. And to the tools that help us make Consonance better:

JIRA, which we use to manage our programming work
Bitbucket, where we store versions of our code
Codeship, which runs our tests before deploying code
Heroku, which hosts our applications
New Relic, which reports on how the applications are running
Zendesk, which keeps the conversation flowing between us and our customers
ReadMe, which provides our user and API docs
AWS, which provide database, storage and backup functions

We know that Consonance sits as one more application in your landscape of tools and services, and we try our hardest to be among the best, in terms of usefulness, beauty and support.

Out and about

We’ve attended some banging events this year, and we plan to do more of that next year, whether as speakers or delegates. There were the trade shows: the London Book Fair in March and Frankfurt in October.

⚡️ “Consonance at Frankfurt 2017”https://t.co/PWtpTpS50C
— Consonance (@Consonance) October 15, 2017

There was the new: the amazing Brighton Ruby conference in July and the Life Time Value conference in April, and the OpenTech conference in May. There was the annual IPG Spring and Autumn conferences (click that link for a brilliant reflection on the day by Emily), and the digital quarterlies.

As well as attending events which helped us reframe and reconsider some publishing truths, we contributed as much as we could to help other people find the joy of code. We ran our sell-out Try Coding for Publishers course in conjunction with Book Machine in April, which raised over £200 for Save The Children:

Lots of garish screens on show at #publisherswhocode workshop as our delegates get to grips with CSS… pic.twitter.com/ZAsNxUSnBn
— Emily Labram (@emilylabram) April 6, 2017

And we are regular and cheerful coaches at Railsgirls London.

Each day, getting better

We get our kicks from being competent in a field that matters. So it was a source of real pride to launch the Consonance Component Library in May, hand-rolled by Andy and used throughout the year and into next as we increasingly standardise the interface.

We have also made great strides with our ONIX provision. We have sent 5700 ONIX files this year alone, containing 571,000 ONIX product fragments, totalling 20GB of data. Phew!

We also find time to pursue personal projects, having instigated a new Side Project Friday afternoon initiative. On Friday afternoon, when the clients tend to go a little quiet, we crack open our personal projects. Andy is learning React and Electron by building a rules viewer for tabletop games. Sara is working on her family bingo app, which she uses herself at events that attract 100 players. Emily introduced herself to SQL. Dave contributed to a number of open source libraries, such as the LISBN gem. And I wrote my makeourbook.com schools publishing app. Whilst that sounds nice but not very relevant, it is actually a fantastic way to hone and grow our programming skills and try out new ways of working. It’s an easy, motivational and interesting way to ensure we undertake ongoing professional development and cross-fertilise new ideas across the team.

And helping more publishers!

We were delighted to welcome seven new clients to Consonance in 2017, who will be joined by 13 (and counting) in 2018. We plan to grow at a slow and steady rate and are glad to be able to curate close relationships with the sorts of publishers we feel best able to support, and most proud of helping. So a festive wave to these new clients: the Institute of Physics (– read our case study), Purdue University Press, Leuven University Press, the British Museum, What on Earth?, Innova Press, Rethink, and to those joining us in the spring. They join a fleet of publishers that we burst with pride to call our customers.

Although it’s lovely to work with new clients, you might be interested to know that our internal bonus scheme is based on renewals: 5% of the licence fee revenue from renewing clients is paid to non-director staff as a bonus. To be honest, our enthusiasm for Consonance means that we’re pretty good sales people. However, it’s one thing to to sell software to new clients; it’s quite another to have them want to keep using it, a year later. So I’m delighted to report that, in 2017, all of our active clients renewed their licenses. It’s a real measure of success, I think, and we’re hugely grateful to our customers for sticking with us.

Recommended. Consonance is light years beyond every other bibliographic data system, and that’s because it’s built with empathy and agility by some very smart people. https://t.co/AYvcP8SlXE
— Simon Collinson (@Simon_Collinson) November 30, 2017

And so, to 2018

So here’s to continuing the hard work and customer focus into 2018 and beyond. We will be in touch with all our customers at the end of January to update them on our firm plans for the year, based on their feedback in our survey. (If you’re a client, and you’ve not yet responded, please do – it’s a great chance to shape Consonance to your priorities, so it’s worth the five minutes!)

Thank you once again to our brilliant and important clients for 2017. This is all for you, and your books, and we hope you thrive and flourish in 2018 with us.

IOP Publishing

2018-02-05T00:00:00+00:00

We were extremely excited to hear from IOP Publishing. Science publishers do vital and inspiring work, and, at Consonance HQ, we get a real kick out of supporting them. We embarked on the RFP process with enthusiasm.

Why IOP Publishing chose Consonance

Despite stiff competition, we were delighted that Consonance’s usefulness and intuitive interface stood out.

Christian Box, Head of Sales Operations, explained their choice:

We were hugely impressed with the interface and user design elements of Consonance, and the modern approach to system architecture which we feel is well placed to grow with us as our programme grows.

IOP Publishing were also impressed by our expertise, and keen to work with Consonance’s David Aldridge on metadata, whom they’ve since described as a true expert in the field.

A smart team, investing in design and technology

IOP Publishing impressed us from the outset with their strategic mindset.

They had invested time in defining their value to the scientific community as a publisher and were committed to investing in the technology to support it.

Their investment in Design, too, shone through their unique, in-house Studio, whose design principles unified their books, covers and marketing materials and generated a palpable sense of pride throughout the team.

This was a skilled and technical organisation with a growing title count. Their manual systems had served them in the early days, but they were now outgrowing them. With talented staff spending increasing amounts of time chasing and correcting data, it was time to invest in a convenient, central source of truth.

IOP’s objectives

Streamline workflow
Improve metadata
Automate marketing materials
Automate data feeds to retailers and distributors

Measuring and learning

IOP Publishing were keen to publish ever more efficiently, from acquisition to publication.

To that end, they aspired to measure the entire process from acquisition to manuscript delivery, production and publication. Consonance would handle IOP’s workflow from contract to production, capturing data on key dates to help IOP streamline and shorten their process over time.

There was also the possibility of an integration with Salesforce down the line, which IOP use to streamline and manage their acquisitions process. This would be technically feasible given Consonance’s Platform-as-a-service provider, Heroku, which has a tried-and-tested Connect service with Salesforce.

It was an exciting brief!

What we did

Migrated IOP’s data from Confluence and ONIX Edit into Consonance
Designed a bespoke AI to match IOP’s original
Trained up the team
Integrated a daily price and availability feed from IPS
Prepared a reporting area in our database for IOP’s Business Intelligence team to directly access metadata
Set up production schedules on Consonance
Set up daily automatic ONIX feeds to their key trading partners and metadata aggregators.

IOP Publishing’s AI

Automatically generated, AIs can also be downloaded across titles in bulk in a few short clicks.

Briefing templates: a highlight

Consonance’s power is in being a ‘canonical source of truth’: one up-to-date, accurate data source. The beauty of this is the ability to reuse this data in many automatic ways.

IOP’s beautiful briefings templates are one of many examples, used for handing over work between departments:

The cover, title, description and other metadata fields feed onto the briefing document automatically, and the headers are templated. The briefing team adds in their unique instructions, and - bam - a delightful and impressive-looking PDF is created in Consonance.

Briefings save IOP Publishing from manually creating these documents and copying and pasting data and eliminate the risk of inaccuracy. More importantly, the templates are stored in Consonance for posterity. That’s invaluable for problem-solving down the line and for reflection, refinement and continuous improvement.

Next steps from here

The IOP Publishing team are up-and-running, feeling the benefits of having everything in one place. Their metadata - including their collections of ebooks, known internally as ‘releases’ - is stored and structured for the future.

Automated data feeds, AIs and briefings have already saved hours of manual data re-entry. And production schedules are enabling them to measure their workflow in readiness for a bumper 2018.

Nevertheless, this is just the beginning of a long-term partnership. We have several projects planned or underway to radically automate more of IOP’s workflow - and which we hope will benefit the client-base as a whole.

Ebooks Product Manager Callum MacKay, who expertly managed the implementation on IOP’s side, reflects on where we are now:

The automation of ONIX to distribution channels saves us a huge amount of time and effort. The relationship with your team - David Aldridge in particular - allows us to develop our existing metadata, and develop new product metadata and mechanisms too using Consonance as a source. This is really valuable.

We’re proud to be equipping this talented team to bring ever more benefit to the scientific community.

774 new Thema subject codes

2018-02-04T00:00:00+00:00

The latest Thema updates have been released with 744 new codes, bringing the total to 6,748, and are now available in Consonance.

As per the list below, many new place qualifiers are available, in particular for Holland, Portugal, Russia, Italy, Hungary, Greece, India… Actually, loads of countries have contributed more geographical detail, which is great to see.

On the education side, German professional/vocational qualifications and degrees are now available.

We strongly advise all clients to be as specific as possible in assigning Thema codes, as there is no risk associated with being too detailed, even if recipients of ONIX have not yet updated their systems.

Here is a list of the 744 new codes.

Geographical

1DDN-NL-BB: Breda
1DDN-NL-BE: Eindhoven
1DDN-NL-BH: s-Hertogenbosch
1DDN-NL-BT: Tilburg
1DDN-NL-DA: Assen
1DDN-NL-DE: Emmen
1DDN-NL-FA: Almere
1DDN-NL-FL: Lelystad
1DDN-NL-GA: Arnhem
1DDN-NL-GD: Apeldoorn
1DDN-NL-GE: Ede
1DDN-NL-GN: Nijmegen
1DDN-NL-HH: Haarlem
1DDN-NL-HM: Alkmaar
1DDN-NL-LM: Maastricht
1DDN-NL-LV: Venlo
1DDN-NL-NG: Groningen
1DDN-NL-RL: Leeuwarden
1DDN-NL-SA: Alphen aan den Rijn
1DDN-NL-SC: Dordrecht
1DDN-NL-SD: Delft
1DDN-NL-SH: The Hague
1DDN-NL-SL: Leiden
1DDN-NL-SR: Rotterdam
1DDN-NL-SZ: Zoetermeer
1DDN-NL-UA: Amersfoort
1DDN-NL-UU: Utrecht
1DDN-NL-VE: Enschede
1DDN-NL-VZ: Zwolle
1DDN-NL-ZG: Goes
1DDN-NL-ZM: Middelburg
1DDN-NL-ZV: Vlissingen
1DFH-CH-GVL: Lausanne
1DNC-IS-R: Reykjavík
1DSM-MT-G: Gozo
1DSP-PT-B: Norte (Northern Portugal)
1DSP-PT-BP: Porto
1DSP-PT-C: Centro (Central Portugal)
1DSP-PT-L: Lisboa (Region)
1DSP-PT-LL: Lisbon
1DSP-PT-LS: Sintra
1DSP-PT-N: Alentejo
1DSP-PT-P: Algarve
1DSP-PT-PF: Faro
1DSP-PT-R: Madeira - Autonomous Region
1DSP-PT-RF: Funchal
1DSP-PT-T: Azores - Autonomous Region
1DST-IT-NZ: Northern Italy: Places of interest
1DST-IT-NZB: The Northern Apennines
1DST-IT-NZD: The Dolomites
1DST-IT-NZL: The Italian lakes region
1DST-IT-NZLC: Lake Como
1DST-IT-NZLG: Lake Garda
1DST-IT-NZLM: Lake Maggiore
1DST-IT-NZLQ: Lake Iseo
1DST-IT-NZP: The Po River & its tributaries
1DST-IT-TRPT: Lake Trasimeno
1DST-IT-TSEB: Val d’Orcia
1DST-IT-TSLB: Elba
1DST-IT-TX: Central Italy: Places of interest
1DST-IT-TXA: The Arno river & tributaries
1DST-IT-TXC: The Tiber river and tributaries
1DST-IT-TXF: The Central Apennines
1DST-IT-TXM: Maremma
1DST-IT-UDSD: The Costa Smeralda
1DST-IT-ULME: Aeolian Islands
1DST-IT-ULTE: Mount Etna
1DST-IT-UMNC: Capri / Ischia
1DST-IT-UMNP: Pompeii / Herculaneum
1DST-IT-UMNV: Mount Vesuvius
1DST-IT-UMSC: The Amalfi coast
1DST-IT-UZ: Southern Italy: Places of interest
1DST-IT-UZC: The Southern Apennines
1DST-IT-UZCE: Monte Gran Sasso
1DST-IT-UZCP: Monte Pollino
1DST-IT-UZD: Sila
1DTA-RU-B: Russia: Central District
1DTA-RU-BK: Kursk
1DTA-RU-BM: Moscow
1DTA-RU-BS: Smolensk
1DTA-RU-D: Russia: Southern District
1DTA-RU-DB: Volgograd
1DTA-RU-DD: Rostov-on-Don
1DTA-RU-F: Russia: Northwestern District
1DTA-RU-FA: Archangel / Arkhangelsk
1DTA-RU-FC: Kaliningrad
1DTA-RU-FD: Novgorod
1DTA-RU-FP: Saint Petersburg
1DTA-RU-H: Russia: Far Eastern District
1DTA-RU-J: Russia: Siberian District
1DTA-RU-JZ: Siberia: places of interest
1DTA-RU-JZB: Siberia: Lake Baikal
1DTA-RU-L: Russia: Ural District
1DTA-RU-N: Russia: Volga District
1DTA-RU-NN: Nizhny Novgorod
1DTA-RU-P: Russia: North Caucasus District
1DTA-RU-PC: Chechen Republic (Chechnya)
1DTB-BY-M: Minsk
1DTD-LV-R: Riga
1DTE-EE-T: Tallinn
1DTF-LT-V: Vilnius
1DTG-GE-T: Tbilisi
1DTH-HU-B: Central Hungary
1DTH-HU-BB: Budapest
1DTH-HU-D: Transdanubia
1DTH-HU-DB: Lake Balaton
1DTH-HU-DD: Lake Neusiedl / Ferto
1DTH-HU-DF: Mecsek Mountains
1DTH-HU-DG: Transdanubian Mountains
1DTH-HU-DH: Little Hungarian Plain
1DTH-HU-DP: Esztergom
1DTH-HU-DQ: Győr
1DTH-HU-DR: Pécs
1DTH-HU-DS: Sopron
1DTH-HU-DT: Székesfehérvár
1DTH-HU-DV: Veszprém
1DTH-HU-F: Great Plain & the North
1DTH-HU-FD: North Hungarian Mountains
1DTH-HU-FDE: Eger
1DTH-HU-FP: Great Hungarian plain
1DTH-HU-FPD: Hortobágy National Park
1DTH-HU-FPJ: Debrecen
1DTH-HU-FPK: Szeged
1DTH-HU-FPW: Lake Tisza
1DTH-HU-Z: Hungary: Places of interest
1DTH-HU-ZD: Danube–Tisza Interfluve
1DTH-HU-ZT: Transtisza / Tiszántúl
1DTJ-CZ-A: Prague
1DTJ-CZ-B: South Moravian Region
1DTJ-CZ-C: South Bohemian Region
1DTJ-CZ-E: Pardubice Region
1DTJ-CZ-H: Hradec Kralove Region
1DTJ-CZ-J: Vysocina Region
1DTJ-CZ-K: Karlovy Vary Region
1DTJ-CZ-L: Liberec Region
1DTJ-CZ-M: Olomouc Region
1DTJ-CZ-P: Pilsen Region
1DTJ-CZ-S: Central Bohemian Region
1DTJ-CZ-T: Moravian-Silesian Region
1DTJ-CZ-U: Usti nad Labem Region
1DTJ-CZ-Z: Zlin Region
1DTJ-CZ-X: Czechia : places of interest
1DTJ-CZ-XB: Bohemia
1DTJ-CZ-XBF: Bohemian Forest
1DTJ-CZ-XBG: Krkonoše / Giant Mountains
1DTJ-CZ-XBV: Vltava river & tributaries
1DTJ-CZ-XM: Moravia
1DTJ-CZ-XS: Czech Silesia
1DTK-SL-B: Bratislava
1DTN-UA-K: Kiev
1DTP-PL-M: Masovian Voivodeship
1DTP-PL-MA: Warsaw
1DTP-PL-P: Lesser Poland Voivodeship
1DTP-PL-PK: Krakow
1DTV-AM-Y: Yerevan
1DTX-AZ-B: Baku
1DXA-AL-T: Tirana
1DXB-BG-S: Sofia
1DXC-HR-A: Zagreb
1DXC-HR-C: Central Croatia
1DXC-HR-D: Dalmatia
1DXC-HR-DD: Dubrovnik
1DXC-HR-DK: Šibenik
1DXC-HR-DS: Split
1DXC-HR-DY: Zadar
1DXC-HR-J: Istria
1DXC-HR-K: Kvarner & the Highlands
1DXC-HR-L: Lika - Karlovac
1DXC-HR-S: Slavonia
1DXD-MK-S: Skopje
1DXG-GR-E: Central Greece
1DXG-GR-EA: Attica
1DXG-GR-EAA: Athens
1DXG-GR-EAE: Eleusis
1DXG-GR-EAP: Piraeus
1DXG-GR-EE: Euboea
1DXG-GR-EEC: Chalcis
1DXG-GR-EF: Phocis
1DXG-GR-EFD: Delphi
1DXG-GR-EK: Aetolia-Acarnania
1DXG-GR-EKM: Missolonghi
1DXG-GR-ET: Phthiotis
1DXG-GR-ETA: Atalanti
1DXG-GR-EV: Boeotia
1DXG-GR-EVT: Thebes
1DXG-GR-H: Epirus
1DXG-GR-L: Thessaly
1DXG-GR-M: Macedonia
1DXG-GR-MC: Chalkidiki
1DXG-GR-ME: Pella
1DXG-GR-MP: Pieria
1DXG-GR-MT: Thessaloniki (region)
1DXG-GR-MTH: Thessaloniki
1DXG-GR-P: Peloponnese
1DXG-GR-PA: Achaea
1DXG-GR-PAP: Patras
1DXG-GR-PD: Arcadia
1DXG-GR-PH: Elis / Ilia
1DXG-GR-PHO: Ancient Olympia
1DXG-GR-PK: Corinthia
1DXG-GR-PKK: Corinth
1DXG-GR-PL: Laconia
1DXG-GR-PLS: Sparta
1DXG-GR-PLY: Mystras
1DXG-GR-PM: Messenia
1DXG-GR-PR: Argolis
1DXG-GR-PRA: Argos
1DXG-GR-PRM: Mycenae
1DXG-GR-S: Greek Islands
1DXG-GR-SA: North Aegean Islands
1DXG-GR-SAC: Chios
1DXG-GR-SAH: Lemnos
1DXG-GR-SAL: Lesbos
1DXG-GR-SAS: Samos
1DXG-GR-SC: Crete
1DXG-GR-SCH: Heraklion
1DXG-GR-SD: Dodecanese (Islands)
1DXG-GR-SDH: Karpathos
1DXG-GR-SDK: Kos
1DXG-GR-SDL: Leros
1DXG-GR-SDP: Patmos
1DXG-GR-SDR: Rhodes
1DXG-GR-SF: Ionian Islands
1DXG-GR-SFC: Corfu
1DXG-GR-SFF: Paxos
1DXG-GR-SFK: Cephalonia / Kefalonia
1DXG-GR-SFL: Lefkada
1DXG-GR-SFP: Ithaca
1DXG-GR-SFR: Zakynthos
1DXG-GR-SK: Cyclades (Islands)
1DXG-GR-SKK: Mykonos
1DXG-GR-SKM: Milos
1DXG-GR-SKN: Naxos
1DXG-GR-SKP: Paros
1DXG-GR-SKS: Santorini
1DXG-GR-SKY: Syros
1DXG-GR-SR: Saronic Islands
1DXG-GR-SRA: Aegina
1DXG-GR-SRS: Salamis
1DXG-GR-SS: Sporades (Islands)
1DXG-GR-SSA: Alonnisos
1DXG-GR-SSK: Skiathos
1DXG-GR-ST: Other Greek Islands
1DXG-GR-STK: Kythira
1DXG-GR-STM: Samothrace
1DXG-GR-STS: Skyros
1DXG-GR-T: Thrace
1DXH-BA-S: Sarajevo
1DXN-ME-P: Podgorica
1DXR-RO-B: Bucharest
1DXR-RO-Z: Romania: places of interest
1DXR-RO-ZT: Transylvania
1DXS-RS-B: Belgrade
1DXV-SI-C: Carniola
1DXV-SI-CL: Ljubljana
1DXY-CY-C: Nicosia
1FBH-IL-A: Tel-Aviv
1FBH-IL-H: Haifa
1FBJ-JO-P: Petra
1FBL-LB-B: Beirut
1FBN-IR-A: Tehran
1FBN-IR-S: Shiraz
1FBP-PS-G: Gaza
1FBQ-IQ-B: Baghdad
1FBS-SY-A: Aleppo
1FBS-SY-D: Damascus
1FBS-SY-P: Palmyra
1FBXS-SA-H: Hejaz /Hijaz
1FBXS-SA-HJ: Jeddah
1FBXS-SA-HM: Mecca / Makkah
1FBXS-SA-HN: Medina
1FBXS-SA-R: Riyadh
1FBXU-AE-A: Abu Dhabi
1FBXU-AE-D: Dubai
1FCA-AF-K: Kabul
1FCK-KG-B: Bishkek
1FKA-IN-A: Northern India
1FKA-IN-AB: Chandigarh
1FKA-IN-AD: National Capital Territory of Delhi
1FKA-IN-ADN: New Delhi
1FKA-IN-AG: Haryana
1FKA-IN-AH: Himachal Pradesh
1FKA-IN-AHS: Shimla / Simla
1FKA-IN-AJ: Jammu & Kashmir
1FKA-IN-AP: Punjab
1FKA-IN-APB: Amritsar
1FKA-IN-AR: Rajasthan
1FKA-IN-ARB: Jaipur
1FKA-IN-ARD: Jodhpur
1FKA-IN-ARF: Udaipur
1FKA-IN-C: Central India
1FKA-IN-CB: Chhattisgarh
1FKA-IN-CD: Madhya Pradesh
1FKA-IN-CF: Uttar Pradesh
1FKA-IN-CFA: Agra
1FKA-IN-CFC: Varanasi / Benares
1FKA-IN-CH: Uttarakhand
1FKA-IN-E: Eastern India
1FKA-IN-EB: Bihar
1FKA-IN-ED: Jharkhand
1FKA-IN-EF: Odisha
1FKA-IN-EH: West Bengal
1FKA-IN-EHC: Kolkata
1FKA-IN-EHD: Darjeeling
1FKA-IN-G: North East India
1FKA-IN-GA: Assam
1FKA-IN-GC: Arunachal Pradesh
1FKA-IN-GE: Manipur
1FKA-IN-GH: Meghalaya
1FKA-IN-GJ: Mizoram
1FKA-IN-GL: Nagaland
1FKA-IN-GN: Tripura
1FKA-IN-J: Western India
1FKA-IN-JB: Dadra & Nagar Haveli
1FKA-IN-JD: Daman & Diu
1FKA-IN-JF: Goa
1FKA-IN-JG: Gujarat
1FKA-IN-JM: Maharashtra
1FKA-IN-JMM: Mumbai
1FKA-IN-L: Southern India
1FKA-IN-LA: Andhra Pradesh
1FKA-IN-LC: Karnataka
1FKA-IN-LCB: Bengaluru
1FKA-IN-LE: Kerala
1FKA-IN-LEC: Kochi
1FKA-IN-LG: Puducherry
1FKA-IN-LGB: Pondicherry
1FKA-IN-LJ: Tamil Nadu
1FKA-IN-LJC: Chennai
1FKA-IN-LK: Telangana
1FKA-IN-LKH: Hyderabad
1FKA-IN-LN: Andaman & Nicobar Islands
1FKA-IN-LP: Lakshadweep
1FKB-BD-D: Dhaka
1FKN-NP-K: Kathmandu
1FKP-PK-B: Balochistan
1FKP-PK-D: Khyber Pakhtunkhwa
1FKP-PK-F: Punjab (PK)
1FKP-PK-FB: Lahore
1FKP-PK-H: Sindh
1FKP-PK-HB: Karachi
1FKP-PK-L: Islamabad
1FKS-LK-C: Colombo
1FMC-KH-A: Phnom Penh
1FMC-KH-B: Siem Reap
1FMC-KH-BA: Angkor
1FMM-MY-B: Kuala Lumpur
1FMM-MY-M: Melaka / Malacca
1FMM-MY-P: Penang
1FMM-MY-S: Sarawak
1FMM-MY-T: Sabah
1FMN-ID-B: Sumatra
1FMN-ID-D: Java
1FMN-ID-DJ: Jakarta
1FMN-ID-F: Kalimantan
1FMN-ID-K: Sulawesi
1FMN-ID-M: Maluku
1FMN-ID-P: Papua
1FMN-ID-S: Lesser Sunda Islands
1FMN-ID-SL: Lombok
1FMP-PH-A: Manila
1FMT-TH-B: Bangkok
1FMT-TH-C: Chiang Mai
1FMT-TH-K: Krabi
1FMT-TH-KL: Ko Lanta
1FMT-TH-P: Phuket
1FMT-TH-Q: Surat Thani
1FMT-TH-QB: Ko Samui / Koh Samui
1FMT-TH-Y: Ayutthaya
1FMV-VN-B: Ho Chi Minh City
1FMV-VN-D: Hanoi
1FPKS-KR-B: Seoul
1HBA-DZ-A: Algiers
1HBL-LY-C: Cyrenaica
1HBL-LY-CB: Benghazi
1HBL-LY-T: Tripolitania
1HBL-LY-TT: Tripoli
1HBM-MA-B: Tanger-Tetouan-Al Hoceima
1HBM-MA-BC: Tangier
1HBM-MA-F: Fès-Meknès
1HBM-MA-FE: Fez
1HBM-MA-H: Rabat-Salé-Kenitra
1HBM-MA-HR: Rabat
1HBM-MA-L: Casablanca-Settat
1HBM-MA-LC: Casablanca
1HBM-MA-M: Marrakesh-Safi
1HBM-MA-ME: Essaouira
1HBM-MA-MM: Marrakesh / Marrakech
1HBM-MA-P: Drâa-Tafilalet
1HBM-MA-PO: Ouarzazate
1HBM-MA-R: Souss-Massa
1HBM-MA-RA: Agadir
1HBS-SD-B: Khartoum
1HBT-TN-A: Tunis
1HBT-TN-D: Djerba / Jerba
1HFDH-GH-A: Accra
1HFDL-LR-A: Monrovia
1HFDM-ML-A: Timbuktu
1HFDN-NG-A: Lagos
1HFDS-SN-A: Dakar
1HFDU-GN-A: Conakry
1HFDY-CI-A: Abidjan
1HFGA-ET-A: Addis Ababa
1HFGK-KE-A: Nairobi
1HFGK-KE-M: Mombasa
1HFGR-RW-A: Kigali
1HFGT-TZ-B: Dar es Salaam
1HFGT-TZ-C: Zanzibar
1HFGT-TZ-E: Northern Tanzania
1HFGT-TZ-EB: Kilimanjaro
1HFGT-TZ-ED: Serengeti
1HFGU-UG-A: Kampala
1HFJC-CG-A: Brazzaville
1HFJZ-CD-A: Kinshasa
1HFMB-BW-A: Gaborone
1HFMB-BW-V: Okavango River & Delta
1HFMQ-MZ-A: Maputo
1HFMS-ZA-A: Eastern Cape
1HFMS-ZA-B: Free State
1HFMS-ZA-BB: Bloemfontein
1HFMS-ZA-D: Gauteng
1HFMS-ZA-DB: Johannesburg
1HFMS-ZA-DD: Pretoria
1HFMS-ZA-F: KwaZulu-Natal
1HFMS-ZA-FB: Durban
1HFMS-ZA-H: Limpopo
1HFMS-ZA-J: Mpumalanga
1HFMS-ZA-K: North West Province
1HFMS-ZA-M: Northern Cape
1HFMS-ZA-N: Western Cape
1HFMS-ZA-NB: Cape Town
1HFMS-ZA-Z: South Africa: places of interest
1HFMS-ZA-ZK: Kruger National Park
1HFMS-ZA-ZD: Drakensberg
1HFMW-ZW-A: Harare
1HFMZ-ZM-A: Lusaka
1HSU-MU-B: Rodrigues
1KJC-CU-D: Havana
1KJC-CU-V: Guantánamo
1KJD-DO-D: Santo Domingo
1KJH-HT-P: Port-au-Prince
1KJP-PR-C: Spanish Virgin Islands
1KJP-PR-CC: Culebra
1KJP-PR-CD: Vieques
1KJWB-BS-A: Nassau
1KJWJ-JM-B: Kingston
1KJWWT-TT-P: Port of Spain
1KJX-BL-B: Saint Barthélemy
1KJX-BQ-B: Bonaire
1KJX-BQ-E: Sint Eustatius
1KJX-BQ-S: Saba
1KJX-CW-C: Curaçao
1KJX-SX-M: Sint Maarten
1KJX-MF-M: Saint Martin
1KLCG-GT-A: Guatemala department
1KLCG-GT-AC: Guatemala City
1KLCG-GT-E: Guatemala: Central region
1KLCG-GT-EB: Sacatepéquez
1KLCG-GT-EBA: Antigua Guatemala
1KLCG-GT-F: Guatemala: South western region
1KLCG-GT-FB: Sololá
1KLCG-GT-H: Petan department
1KLCG-GT-HF: Flores
1KLCH-HN-A: Honduras: Western region
1KLCH-HN-AC: Copan
1KLCH-HN-C: Honduras: North Eastern Region
1KLCH-HN-CJ: Bay Islands
1KLCH-HN-E: Honduras: Central Eastern Region
1KLCH-HN-EA: Francisco Morazán (Department)
1KLCH-HN-EAB: Tegucigalpa
1KLCM-MX-A: Northwest Mexico
1KLCM-MX-AA: Baja California
1KLCM-MX-AAB: Tijuana
1KLCM-MX-AB: Baja California Sur
1KLCM-MX-ABB: Los Cabos
1KLCM-MX-AC: Chihuahua
1KLCM-MX-AD: Durango
1KLCM-MX-AE: Sinaloa
1KLCM-MX-AEB: Mazatlan
1KLCM-MX-AF: Sonora
1KLCM-MX-B: Northeast Mexico
1KLCM-MX-BA: Coahuila de Zaragoza
1KLCM-MX-BB: Nuevo Leon
1KLCM-MX-BC: Tamaulipas
1KLCM-MX-E: North-Central Mexico
1KLCM-MX-EA: Aguascalientes
1KLCM-MX-EB: Guanajuato
1KLCM-MX-EBB: San Miguel de Allende
1KLCM-MX-EC: Queretaro
1KLCM-MX-ED: San Luis Potosi
1KLCM-MX-EE: Zacatecas
1KLCM-MX-F: South-Central Mexico
1KLCM-MX-FA: Mexico City
1KLCM-MX-FB: Mexico State
1KLCM-MX-FBM: Teotihuacan
1KLCM-MX-FC: Morelos
1KLCM-MX-C: West Mexico
1KLCM-MX-CA: Colima
1KLCM-MX-CB: Jalisco
1KLCM-MX-CBA: Guadalajara
1KLCM-MX-CBD: Puerto Vallarta
1KLCM-MX-CC: Michoacán de Ocampo
1KLCM-MX-CD: Nayarit
1KLCM-MX-D: East Mexico
1KLCM-MX-DA: Hidalgo
1KLCM-MX-DB: Puebla
1KLCM-MX-DC: Tlaxcala
1KLCM-MX-DD: Veracruz
1KLCM-MX-H: Southeast Mexico
1KLCM-MX-HA: Campeche
1KLCM-MX-HB: Quintana Roo
1KLCM-MX-HBB: Cancun
1KLCM-MX-HBC: Cozumel
1KLCM-MX-HBD: Playa del Carmen
1KLCM-MX-HBM: Tulum
1KLCM-MX-HBN: Riviera Maya
1KLCM-MX-HC: Tabasco
1KLCM-MX-HD: Yucatán
1KLCM-MX-HDA: Merida
1KLCM-MX-HDM: Chichen Itza
1KLCM-MX-HX: Southeast Mexico: Places of interest
1KLCM-MX-HXP: Yucatan Peninsula
1KLCM-MX-G: Southwest Mexico
1KLCM-MX-GA: Chiapas
1KLCM-MX-GB: Guerrero
1KLCM-MX-GBB: Acapulco
1KLCM-MX-GBE: Ixtapa-Zihuatanejo
1KLCM-MX-GC: Oaxaca
1KLCM-MX-GCA: Oaxaca de Juarez
1KLCM-MX-Z: Mexico: places of interest
1KLCM-MX-ZC: Gulf of California / Sea of Cortes
1KLCN-NI-M: Managua
1KLCP-PA-A: Panamá
1KLCP-PA-C: Colón
1KLCP-PA-D: Darien
1KLCR-CR-A: San José
1KLCS-SV-A: El Salvador: Western
1KLCS-SV-B: El Salvador: Central
1KLCS-SV-BA: San Salvador
1KLCS-SV-C: El Salvador: Eastern
1KLSA-AR-A: Northwest Argentina (NOA)
1KLSA-AR-AA: Catamarca
1KLSA-AR-AB: Jujuy
1KLSA-AR-AC: La Rioja
1KLSA-AR-AD: Salta
1KLSA-AR-AE: Santiago del Estero
1KLSA-AR-AF: Tucuman
1KLSA-AR-B: Northeast Argentina (NEA)
1KLSA-AR-BA: Corrientes
1KLSA-AR-BB: Chaco
1KLSA-AR-BC: Formosa (AR)
1KLSA-AR-BD: Misiones
1KLSA-AR-C: Cuyo
1KLSA-AR-CA: Mendoza
1KLSA-AR-CAM: Aconcagua
1KLSA-AR-CB: San Juan (AR)
1KLSA-AR-CC: San Luis (AR)
1KLSA-AR-D: Centro
1KLSA-AR-DA: Buenos Aires
1KLSA-AR-DB: Córdoba (AR)
1KLSA-AR-DC: Entre Rios (Mesopotamia)
1KLSA-AR-DD: La Pampa
1KLSA-AR-DE: Santa Fe (AR)
1KLSA-AR-E: Patagonia
1KLSA-AR-EA: Chubut
1KLSA-AR-EB: Neuquén
1KLSA-AR-EC: Rio Negro (AR)
1KLSA-AR-ED: Santa Cruz (AR)
1KLSA-AR-EDM: Parque Nacional de los Glaciares
1KLSA-AR-EE: Tierra del Fuego
1KLSA-AR-EEA: Ushuaia
1KLSB-BR-A: Brazil: North Region
1KLSB-BR-AA: Acre (state)
1KLSB-BR-AB: Amapa
1KLSB-BR-AC: Amazonas (state)
1KLSB-BR-AD: Para
1KLSB-BR-AE: Rondônia
1KLSB-BR-AF: Roraima
1KLSB-BR-AG: Tocantins
1KLSB-BR-B: Brazil: Northeast Region
1KLSB-BR-BA: Alagoas
1KLSB-BR-BB: Bahia
1KLSB-BR-BBB: Salvador de Bahia
1KLSB-BR-BC: Ceara
1KLSB-BR-BD: Maranhão
1KLSB-BR-BE: Paraíba
1KLSB-BR-BF: Pernambuco
1KLSB-BR-BFB: Recife
1KLSB-BR-BG: Piaui
1KLSB-BR-BH: Rio Grande do Norte
1KLSB-BR-BJ: Sergipe
1KLSB-BR-C: Brazil: Central-West Region
1KLSB-BR-CA: Distrito Federal
1KLSB-BR-CAB: Brasilia
1KLSB-BR-CB: Goias
1KLSB-BR-CC: Mato Grosso
1KLSB-BR-CD: Mato Grosso do Sul
1KLSB-BR-CZ: Brazil: Central-West Region: places of interest
1KLSB-BR-CZP: Pantanal
1KLSB-BR-D: Brazil: Southeast Region
1KLSB-BR-DA: Espirito Santo
1KLSB-BR-DB: Minas Gerais
1KLSB-BR-DC: Rio de Janeiro (State)
1KLSB-BR-DCA: Rio de Janeiro
1KLSB-BR-DD: São Paulo
1KLSB-BR-E: Brazil: South Region
1KLSB-BR-EA: Parana
1KLSB-BR-EB: Santa Catarina
1KLSB-BR-EC: Rio Grande do Sul
1KLSC-CO-A: Colombia: Amazonian Region
1KLSC-CO-B: Colombia: Andean region
1KLSC-CO-BA: Antioquia
1KLSC-CO-BAA: Medellin
1KLSC-CO-BB: Boyaca
1KLSC-CO-BD: Cundinamarca
1KLSC-CO-BDA: Bogota
1KLSC-CO-BF: Norte de Santander
1KLSC-CO-BJ: Santander (department)
1KLSC-CO-C: Colombia: Caribbean Region
1KLSC-CO-CB: Bolivar (department)
1KLSC-CO-CBA: Cartagena
1KLSC-CO-CG: San Andres, Providencia & Santa Catalina
1KLSC-CO-D: Colombia: Orinoco Region
1KLSC-CO-E: Colombia: Pacific Region
1KLSC-CO-ED: Valle del Cauca
1KLSC-CO-EDA: Cali
1KLSE-EC-A: Ecuador: Coastal region
1KLSE-EC-B: Ecuador: Andean region
1KLSE-EC-BA: Azuay
1KLSE-EC-BAA: Cuenca
1KLSE-EC-BE: Chimborazo
1KLSE-EC-BF: Cotopaxi
1KLSE-EC-BJ: Pichincha
1KLSE-EC-BJA: Quito
1KLSE-EC-C: Ecuador: Amazonian region
1KLSG-GY-G: Georgetown
1KLSH-CL-C: Chile: Zona Central
1KLSH-CL-CD: Santiago
1KLSL-BO-A: Pando
1KLSL-BO-B: La Paz
1KLSL-BO-C: Beni
1KLSL-BO-D: Oruro
1KLSL-BO-E: Cochabamba
1KLSL-BO-F: Santa Cruz
1KLSL-BO-G: Potosi
1KLSL-BO-H: Chuquisaca
1KLSL-BO-HA: Sucre
1KLSL-BO-J: Tarija
1KLSP-PY-A: Asunción
1KLSR-PE-A: Peru: Amazon Region
1KLSR-PE-AA: Amazonas region
1KLSR-PE-AAB: Chachapoyas
1KLSR-PE-AC: Madre de Dios region
1KLSR-PE-ACT: Tambopata
1KLSR-PE-B: Peru: Andean Region
1KLSR-PE-BD: Cusco region
1KLSR-PE-BDC: Cusco / Cuzco
1KLSR-PE-BDD: La Convención
1KLSR-PE-BDM: Machu Picchu
1KLSR-PE-BDV: Ausangate & the Cordillera Vilcanota
1KLSR-PE-C: Peru: Northern coastal region
1KLSR-PE-D: Peru: Central coastal region
1KLSR-PE-DA: Ancash region
1KLSR-PE-DAB: Huaraz
1KLSR-PE-DAS: Cordillera Blanca & Huascaran National Park
1KLSR-PE-DAY: Yerupaja & Huayhuash
1KLSR-PE-DC: La Libertad region
1KLSR-PE-DD: Lima region
1KLSR-PE-DDL: Lima
1KLSR-PE-E: Peru: Southern coastal region
1KLSR-PE-EA: Arequipa region
1KLSR-PE-EB: Ica region
1KLSR-PE-EBN: Nazca
1KLSS-SR-P: Paramaribo
1KLSU-UY-A: Uruguay: North
1KLSU-UY-B: Uruguay: North West
1KLSU-UY-C: Uruguay: South West
1KLSU-UY-D: Uruguay: East
1KLSU-UY-E: Uruguay: Southern central
1KLSU-UY-EF: Montevideo
1KLSV-VE-C: Caracas

Educational

4Z-DE-UH: For specific German professional/vocational qualifications & degrees (dual education system)
4Z-DE-UHA: For German vocational qualifications working in the land sector
4Z-DE-UHAA: For German vocational qualifications in agriculture, husbandry, forestry, landscaping & horticulture
4Z-DE-UHAB: For German vocational qualifications in land surveying
4Z-DE-UHB: For German vocational qualifications in the food industries
4Z-DE-UHBA: For German vocational qualifications in baking, pastry making & confectionary
4Z-DE-UHBB: For German vocational qualifications as a butcher
4Z-DE-UHBC: For German vocational qualifications as a chef
4Z-DE-UHBD: For German vocational qualifications as a food & beverage specialist
4Z-DE-UHD: For German vocational qualifications in metal production & metal working industries
4Z-DE-UHDA: For German vocational qualifications in precision engineering & related professions
4Z-DE-UHDB: For German vocational qualifications in metal production & processing
4Z-DE-UHDC: For German vocational qualifications in metalworking, plant construction, sheet metalwork, casting, & fitting
4Z-DE-UHDD: For German vocational qualifications as an industrial mechanic or toolmaker
4Z-DE-UHE: For German vocational qualifications in stone, glass & ceramic production & related industries
4Z-DE-UHEA: For German vocational qualifications in stone, glass or ceramics processing & building materials
4Z-DE-UHEB: For German vocational qualifications in mining & quarrying
4Z-DE-UHF: For German vocational qualifications in the cloth & leather industries
4Z-DE-UHFA: For German vocational qualifications in spinning, weaving, textile finishing
4Z-DE-UHFB: For German vocational qualifications in textile processing & leatherworking
4Z-DE-UHH: For German vocational qualifications in engineering, manufacturing & construction
4Z-DE-UHHA: For German vocational qualifications in electrical trades
4Z-DE-UHHB: For German vocational qualifications as technicians or mechanical engineer
4Z-DE-UHHC: For German vocational qualifications as a drafter or drafting technician
4Z-DE-UHHD: For German vocational qualifications in vehicle or aircraft manufacture & maintenance
4Z-DE-UHHE: For German vocational qualifications in construction, wood & plastic processing
4Z-DE-UHHF: For German vocational qualifications in the chemical & plastics industries
4Z-DE-UHHG: For German vocational qualifications in paper manufacture, processing & printing
4Z-DE-UHJ: For German vocational qualifications in scientific, geographical and IT related professions
4Z-DE-UHJA: For German vocational qualifications in chemistry, physics or natural sciences
4Z-DE-UHJB: For German vocational qualifications in IT
4Z-DE-UHL: For German vocational qualifications in transport, logistics, security & safety
4Z-DE-UHLA: For German vocational qualifications in the transport sector
4Z-DE-UHLB: For German vocational qualifications in aviation or seafaring
4Z-DE-UHLC: For German vocational qualifications in quality control & inspection
4Z-DE-UHLD: For German vocational qualifications as packers, warehouse or transport workers
4Z-DE-UHLE: For German vocational qualifications in personal protection & security
4Z-DE-UHLF: For German vocational qualifications in the safety & security professions
4Z-DE-UHLG: For German vocational qualifications in cleansing & waste disposal
4Z-DE-UHM: For German vocational qualifications in commercial services, retail, distribution, hospitality and tourism
4Z-DE-UHMA: For German vocational qualifications in the retail sector
4Z-DE-UHMB: For German vocational qualifications in the wholesale sector
4Z-DE-UHMC: For German vocational qualifications as caretakers & property management
4Z-DE-UHMD: For German vocational qualifications in the hospitality industry
4Z-DE-UHP: For German vocational qualifications in the finance, business & administration sectors
4Z-DE-UHPA: For German vocational qualifications in banking or insurance
4Z-DE-UHPB: For German vocational qualifications in commercial office skills
4Z-DE-UHPC: For German vocational qualifications in management, accounting & business consulting
4Z-DE-UHPD: For German vocational qualifications in public administration
4Z-DE-UHPE: For German vocational qualifications in finance & bookkeeping
4Z-DE-UHPF: For German vocational qualifications in secretarial & office skills
4Z-DE-UHPG: For German vocational qualifications in the legal sector
4Z-DE-UHQ: For German vocational qualifications in the health, social care & educational sectors
4Z-DE-UHQA: For German vocational qualifications in personal care
4Z-DE-UHQB: For German vocational qualifications in health care (licenced)
4Z-DE-UHQC: For German vocational qualifications in health care (without a licence)
4Z-DE-UHQD: For German vocational qualifications in social work
4Z-DE-UHQE: For German vocational qualifications in teaching
4Z-DE-UHS: For German vocational qualifications in the cultural sector, creative industries & the media
4Z-DE-UHSA: For German vocational qualifications in advertising
4Z-DE-UHSB: For German vocational qualifications in art or music
4Z-DE-UHSC: For German vocational qualifications in design or photography
4Z-DE-UHSD: For German vocational qualifications in publishing, librarianship, translation & related sectors

A quick look at data visualisation and analysis

2018-02-03T00:00:00+00:00

I’ve recently been harking back to my roots as a veteran Business Intelligence architect, which was pretty much the entirety of my working life before joining Consonance (leaving aside the brief Merchant Navy adventure, MFI warehouse work, and extensive Baskin Robbins experience, all of which threatened my life in one way or another).

And something that has been nagging at me for the past few years is how best to make the most of the data that we are storing for publishers. What insights could we deliver beyond the usual sets of static reports and (shudder) pie charts?

One challenge to overcome is the wide variation in the data that publishers store in the system. Clients using the royalties functionality are pretty well placed – in general they will have good quality book metadata, contact information, sales, advances, and royalties calculation results. That’s definitely something to work with.

For clients who do not need royalty functionality, or who have not got to that stage in their adoption, we might have inventory data fed directly from a distributor from which some estimation of sales might be gathered.

Or we might simply have metadata – products, prices, subject codes, publication dates, contributors, audiences, etc. That’s not too bad – we can visualise the publication schedule in terms of how many works and products are in the pipeline in comparison to historical trends, and dive into metadata completion.

The second challenge has been to find the right technology for the task. In the initial stages of exploring functionality I do not want to spend the time setting up a server on AWS, and performing data migrations. So I’m looking for a price-and-time-economical starting point that has the potential to scale later on, and needs the minimum of data preparation.

I settled on Tableau Desktop Personal Edition, which is currently priced at USD35 per user per month, and is an easy install (on Mac at least – I don’t see it being harder on Windows). Tableau also provide a free Reader application, which can be used to explore data exported as a package from Desktop, allowing me to try out some data analysis and share it with clients.

Lastly, how to access data? At Consonance we are rolling out very fast and efficient CSV-formatted downloads from the system for all clients (I just dropped 200MB of daily inventory data to my desktop in about 30 seconds). And a CSV format, done correctly, is a great start.

Onwards, to the visualisations …

I looked at sales data for a client who has implemented the royalties functionality, and has loaded aggregated sales data for quite a reasonable historical period of about eight years.

Here is a very small taste of the work so far.

In What Part Of The Year Do Different Formats Sell?

Looking at the seasonality of sales by product form, the stand-out here is the relatively high level of hardback sales around the Christmas sales period – November sales are three times the June sales. Is that a surprise to anyone? We all know that everyone loves a hardback for Christmas.

And it’s trivial, of course, to look at this by subject, and to look for confirmation that biographies of football managers might be more prone to this effect than romance fiction.

On the face of it, that looks like an open-and-closed case, but there’s quite a list of caveats with this. Not the least of those is which month of the year the products are most likely to be published in.

When Do We Publish Different Formats?

Which would not be relevant if it weren’t that the post-publication sales profile for hardbacks was so peaky…

Do Hardback Sales Decline Faster Than Paperback?

Yes, they do. And that has interesting implications for inventory management – how closely do individual product sale profiles cleave to this average, and how much inventory are you holding ten months after publication?

And do we deliberately publish Christmas-friendly hardbacks in October?

More analysis required…

Forecasts

And just jumping sideways for a moment, here is a simple-to-generate total sales forecast.

Note how the linear trend and seasonality have been picked out here.

Early Learnings

So here are my conclusions with this mini-project so far.

Firstly, having thought about the range of publishers and their data that we currently store, data exploration of this kind is going to follow a very particular path for each of them. We have non-GB based clients with only a peripheral interest in BIC codes, or who only publish ebooks, or who publish only a few very high value products, and others who have to consider both trade and academic audiences (and who consequently have very different predominant sales channels for different works and products).

Secondly, systems such as Consonance are sitting on an absolutely vast range of data that should be very amenable to analysis, covering metadata, data sharing, sales, inventory, royalties, and when you combine these data sets together you have extraordinary potential for insight. At what stage prior to publication are you sending ONIX to different partners, and how often do different products have data changes? What’s the correlation between values of high-level BIC and BISAC main subject codes? And so on.

But make sure you are using a system that enables you to access that data.

Thirdly, it is entirely possible to do quick and efficient Business Intelligence exploration projects, when you have found the right tools. I’ve enjoyed working with Tableau so far, and the range of free learning materials on their support site has been excellent. If you’re trying to do non-trivial analysis in Excel, stop right now – we have at least two clients who are already using Tableau successfully, so find some time on your schedule to go and get yourself a trial.

And finally, no pie charts.

The ONIX Standard is not very standard

2018-02-02T00:00:00+00:00

Here at Consonance we send ONIX to over a hundred recipients, and I think it’s fair to say that no two feeds are exactly the same – different content goes to each recipient even for the same product at the same time.

This may be a surprise, since ONIX is a capital-S Standard in the book trade, or, more accurately, it is a set of standards that cover various different functionalities and versions. However, here we’re concerned with one form – ONIX for Books – for the exchange of product metadata.

But given that ONIX for Books is a Standard, why would a single product not have a single version at any one time, to be sent to all recipients? Isn’t that the point of a Standard?

If only it were so … and for the following reasons, it is not. What follows is a list of some of the features that ONIX recipients ask us for.

1. Proprietary Codes, Please

Identification is a perpetual bugbear of the publishing industry.

The ISBN-13 is thankfully well-established as a product identifier, but as far as the rest goes it’s still the Wild West out there. ISTCs appear to be dead or dying as a work identifier; DOI is well-established in the academic market; and ISNI has a strong and growing claim as an authoritative identifier of public personae (authors, primarily).

Outside of the English-speaking world there are pockets of strongly-established identifiers for publishers (e.g. the Fondscode Boekenbank) and imprints (e.g. Identifiant Marque Electre in France), and the ISNI can be used for such purposes. But in the global publishing market there are few, maybe no, widely-used organisational identifiers.

And therefore we have ONIX recipients, primarily distributors, who must have their code for an imprint in the ONIX feed, with specific requirements on how it should be included in the feed. Well, if they’re big enough then they can get away with it, but in practice I suspect that they have lumbered themselves with a requirement that is so infrequently fulfilled by ONIX vendors that their ONIX take-up by smaller publishers will be very poor. I have heard, anecdotally, of a medium-sized publisher being quoted in excess of £10,000 for the establishment of an ONIX feed to a major UK distributor, an offer which the publisher declined in favour of continuing to type metadata into a web form.

It probably goes without saying that if you start sending distributors imprint-specific codes to all of your ONIX recipients, you’re soon going to find problems.

Thus we have

Rule One:

For some ONIX recipients you must include their particular identification codes, and you’d best not be sending them to anyone else.

2. We Still Use The Old Way

ONIX is a standard, but it is an evolving standard, and particularly in the still-alive-and-kicking ONIX 2.1 there are almost always different ways of representing the same data. ISBN-13 could be represented in its own element, or as a type 15 Product Identifier, or even as a type 03 (GTIN-13) Product Identifier.

Rule Two:

For every new way of representing a data item in ONIX, there will be one new format of ONIX required by someone.

3. We’re Eight Code Lists Behind

Another way in which ONIX evolves is by the addition of new code values, and re-interpretations of old values.

The Price Qualifier 06 used to be Corporate price, described as Price for sale to libraries or other corporate or institutional customers. The use of or is a giveaway, because now, of course, 06 is Corporate / Library / Education price, and there are more specific codes (six of them) to allow differentiation between the subtypes.

None of which will stop some recipients of library prices from requiring that they be coded as 05.

Rule Three:

The same data is sometimes sent under different codes.

4. We Don’t Need That

ONIX is a broad format, and it covers many business cases for transferring metadata: publisher to distributor, publisher to sales agent, publisher to retailer, and so on. For some of these you need to include particular data that is not required for others:

Retailers need to know the consumer prices, not the library prices. They might need only particular currencies, and if they only price in a single currency then telling them which territories that price applies in is unnecessary.
Sales agents already know who the sales agents are (it’s them), but might need to know the full range of prices – consumer/library, GBP/USD/AUD – and in which territories each currency should be used.
Metadata aggregators quite often don’t need to know who all your distributors are, but if they’re broadcasting metadata round the world then the list of sales agents per territory is going to be useful.

It is not necessarily a case that sending the extra data is going to break anything (see Rule Seven for that), but every extra data item you send is another potential data change that you have to check for, which might cause data to be sent too frequently to recipients. If you change your sales agent for Algeria, do you then want to send a complete refresh for every product with world sales rights to every recipient?

Rule Four:

Not every recipient needs every item of data. Be prepared to trim off the excess.

5. ONIX Doesn’t Do What We Need

ONIX is also a narrow format. There is a wide range of metadata that it is not designed to carry, but the standard can be bent slightly to accommodate extra requirements.

One example of this is the identification of POD printers to a distributor. A POD arrangement might be in place with different printers in different territories, or a stock item in some territories and POD in other. It might be true POD, or could be an automatic stock replenishment program designed to keep a minimum number of units in stock.

This can require logic such as when sending this product to this recipient, against this supplier add one or more codes to represent this set of POD/ASR arrangements.

Rule Five:

Sometimes you will need to go beyond the natural capabilities of ONIX.

6. Not In That Order

We can read those codes, but only the first six, so please make sure that they are ordered according to the following arrangement.

Typically observed with Related Product composites, and reflecting a weakness in the capabilities of the recipient’s system, we sometimes cannot rely on sending all the metadata and letting the recipient pick out the interesting parts.

Rule Six:

It’s not just the data, it’s the order in which you include it.

7. That Breaks Our System

Just because ONIX is valid doesn’t mean it’s valid for everyone.

Particularly seen in composites that can be repeated an arbitrary number of times, some systems will only accept particular codes for those composites. Add the wrong one, and that’s your data not ingested.

Often expressed as We can only accept one Work Identifier.

Rule Seven:

One person’s valid ONIX is another person’s we can’t read this.

8. Different Market, Different Data

I think it is fair to say that publishers in the UK have a particular perspective on prices.

No tax on print books.
One rate of tax on ebooks.
No need to think about tax for the rest of the world.

And the slight variation in there is that academic publishers often want to specify ebook prices exc-tax, and trade publishers want to specify inc-tax. UK recipients of GBP pricing generally want inc-tax prices, and for the most part this is entirely compatible with the publisher’s viewpoint.

In Europe there appears to be a slightly different approach, in that specifying inc-tax prices in their home currency means picking their own VAT rate and applying it to their Euro prices. When the price is sent to a trade partner in a different country who also uses Euros, there are a few possibilities:

Use the same inc-VAT price, but with local taxes applied instead.
Use the same exc-VAT price, converted to new inc-VAT prices at the local tax rates.

Rule Eight:

The same data item can need to be presented in an entirely different way.

9. Send Different Data

Consider the Short Description – 350 characters of finely tuned, carefully crafted marketing wizardry, designed to entice the reader. Do you want to send the same text to Amazon.com as you do to Waterstones? Possibly not.

Rule Nine:

Not everything can be blamed on ONIX recipients. Sometimes you just have to do what you have to do.

10. Send Different Products

ebook distributors get PDFs, only send Kindle to Amazon, don’t send this to them unless it has a USD consumer price, OpenAccess doesn’t go there…

You get the picture.

Rule Ten:

You sometimes need to filter out products by varied criteria.

Summary

There is no such thing as Standard, and sometimes you have to:

Not send some data.
Change the order of the data.
Change the meaning of some data.
Add extra not-strictly-ONIX data.
Add particular identifiers unique to a recipient.
etc.

Next up, I’ll write about how we track changes to product-level ONIX on a per-recipient basis, to guarantee that they only get truly incremental feeds.

Stay small or scale? Be clever about your size

2018-01-01T00:00:00+00:00

In a barney with Amazon about terms, being massive makes for a fairer fight: if retailers are going to get big, then suppliers have to match them in size if they want to square up. Same with the government: if you want to lobby Whitehall about VAT, employing x-thousand people and paying £y-m taxes buys you an invite to an influential lunch or two.

But in a lot of ways, big businesses are obsolete.

I don’t mean they will fail. I mean that the reasons businesses become big are no longer relevant.

Businesses get big to take advantage of economies of scale. Being big means a company’s operations can specialise into functional silos. Being big means having negotiation leverage. Being big means you can get even bigger, by having the heft to acquire competitors. Being big means people flock to work for you because of a secure paycheck (an illusion, by the way, when your contract says you’re on a couple of months’ notice).

But these places suck the creativity out of people.

Big businesses are not where you look for innovation or fast-paced invention. Try to get a simple app development project signed off in a large company: what would take a small company a morning morphs into a 6-month-long series of vibe-killing process-hoops. If an industry’s character is dominated by big businesses, it’s static, frozen, condemned to a glacial rate of change. And this, in a world where technology makes lightning-fast change possible, is a threat to the survival of an industry.

Thankfully, our industry isn’t only composed of big businesses.

At London Book Fair this week, we are seeing what a diverse, interesting, varied marketplace looks like. Lots of companies, lots of points of view, lots of new ideas brought to market in different ways. The more diversity in our industry, the better.

So it’s good news that over the last few years, a multitude of new approaches have sprung up — in forms accessible to publishers of all sizes — which level the playing field of data and process excellence.

POD services have come of age, in terms of quality and price. There’s the notion of crowd-sourcing. Cloud-based services abound, making data accessible from anywhere and providing new capabilities in everything from back office organisation to content management. We discussed all these and more at the Digital Minds “Branching Out” session on Monday, headed by Alison Jones, and a walk round the aisles at the Fair confirms that we’re firmly into a boom period of new Web services and new business models.

These offerings mean that the problems that businesses have solved in the past by getting big can be tackled in other ways.

Need to develop specialist design skills? Tender for a provider on Elance.
Need to manage your finances professionally? Use Freeagent or Xero.
Need to raise capital? Use Crowdcube.
Need a way of managing your marketing to hundreds of thousands of customers? Use HubSpot.
Need a lightning-fast, gorgeous ecommerce Web site? Use Shopify.
Need to manage stock in the US, Australia, India and beyond? Use Shipwire.
Need to build a scattered team of home-workers? Use cloud-based systems ranging from Google Drive to Dropbox.
Need to collect micro-payments from chunked content sales from Facebook and bloggers’ Web sites? Use Valobox.
Need to manage your content workflow in XML? Use Librios.
Need to group together with like-minded folk to exhibit at the London Book Fair? Join IPAC, the Independent Publishing Agency Collective.
Need a cloud-based publishing management solution that doesn’t require you to remortgage? <plug>Use Consonance.</plug>
Integrate all the above? Rely on elegant, simple APIs between applications.

Not all the solutions are brand-new-digi-magic, although their ongoing strength lies in their use of technology to manage their members’ data. Aggregators continue to have a role, from trade bodies, such as the PA and the IPG, to wholesalers of stock (Gardners, Bertrams), services (Inpress, Ingram) and data (Nielsen, Bowker). Their services allow smaller companies to group together for the common good: lowering costs, improving data flow, aggregating spend and heft for negotiation leverage.

And yet despite all these ways of operating successfully as a company with just a handful of staff and a shed-load of creativity, there’s still this assumption that companies have to get big. The start-up culture has a lot to answer for: it’s baked-in that the correct order of things is to raise angel, then venture capital; to scale as quickly as possible before you burn through the money.

There’s no vocabulary in the start-up world to describe a tech company which starts small, stays small, doesn’t raise money, doesn’t aim for an IPO or buyout exit.

There’s nothing wrong with a company staying small, staying true to its founding principles, employing a few happy staff, and maintaining a focus on the product.

And despite my grumbling about big business, it’s not actually impossible to be innovative and large.

Take 3M: a company who try to stay small-at-heart by hiving off projects into their own autonomous, small business units. 3M have themselves built the tools they need to remain spry. We can take a lesson from them: as an industry we must build our own innovative infrastructure tools so that they’re fit for purpose, so that they answer the correct need and, crucially, so that they belong to us. If the infrastructure is created for us by third-party developers, then it won’t instinctively answer our needs.

Because whilst there has been a large number of new services come to market, there’s still plenty of headroom for tools to be developed that answer real publishing needs. Take APIs, for example. If a publisher signs up to the latest online POD management tool, an online rights marketplace, an ebook aggregator, and an online galley service, and if there are no APIs connecting those services to each other and to existing distributor and publishing management systems, then, rather than improving efficiency, the publisher now has to enter the same data in to more and more forms.

The answer is to develop APIs that link the systems together, allowing them to share data and taking the maintenance load off the publishers — entirely achievable for barely any cost with modern RESTful APIs. But some developers don’t feel the acute pain of a lack of integration between their solutions and their competitors’. There’ll only be the drive to develop the right tools that answer real-world problems if the people feeling the pain write the solutions. And too few publishers know how to code. (Have I mentioned that before?)

Not only that, but it seems every tech start-up following the raise-money-grow-exit model ends up being owned by Google or Amazon or another behemoth in the end.

If we don’t develop digital tools ourselves, our own infrastructure will be owned by outsiders.

If we do ever get to that happy state of there being a sufficiently well-architected infrastructure to let companies stay small, prosper, and in turn contribute to a thriving, richly diverse industry, what will there be left for those companies to do? What is the role of a publisher – small or otherwise? What do we aspire to do that makes us anything other than middle-men? Is our USP that we curate, edit, act as a hub?

I hope that technology will mean we can keep the focus of our work right where it should be: on the writing, and on getting our products in front of people who are interested in them.

We’re on the brink of being able to have a sufficient number of well-integrated, affordable tools to support a boom in innovation and, potentially, new companies, adding diversity to our already rich industry.

How wonderful if technology can help us to add to the diversity and vibrancy of the trade. How wonderful if we can write that technology ourselves, using it to build smaller, happier companies.

Because from happiness comes creativity.

Originally written for and published by The Futurebook in April 2015

A taste of code

2018-01-01T00:00:00+00:00

On Thursday, in conjunction with BookMachine, the Consonance team ran a workshop to teach 30-odd publishers how to write code.

Yes, it was as ludicrously ambitious as that. You can’t learn programming in a day: it’s quite possibly a life’s work. And yet I hope that we demystified a few elements of programming for some people whose future roles depend on being able to effectively navigate the digital world.

We prepared very thoroughly for this workshop, starting with a brainstorm of what we hoped to achieve. We decided that we wanted to introduce several key concepts, such as HTML, CSS, Ruby, APIs, and JavaScript, highlighting their relevance to publishing. Andy wrote a Sinatra app which queries the Google Books API, and over the following four weeks we iterated on, tested and documented it.

The results are here:

A Github page with a quick start link to download the web application code to your own Nitrous account.

To follow the course yourself at home, register for a free account at Nitrous.io [Update: now defunct] then visit the Github page to get started.

If you’d prefer to have been there in person, then you’re in luck. There was an 80 person waiting list for this course – there’s clearly demand for technical skills in publishing, so we’ll be running it again sometime soon. Watch this space.

Creative industries and the division of labour

2018-01-01T00:00:00+00:00

How do you arrange people in a modern company?

It’s an endlessly interesting question, and one that needs a new answer with every shift in technology and the markets.

Do we use the 240-year-old Wealth of Nations by Adam Smith as our handbook? Smith’s ‘division of labour’ argument makes sense for the manufacture of pins, but what relevance does it have to the two creative industries that I’m interested in: publishing and software creation? Sure, there are certain technical elements to writing software—and some expert niches in publishing—that lend themselves to specialisation. But they’re fewer than you’d think. To force people to confine themselves entirely to one functional silo is to waste the creative potential of a good human brain, and the cross-fertilization opportunities of human experience.

There is a neat parallel between the best way to design a systems landscape, and the best way to design a network of people. When we implement Consonance for publishers, the difficult bit is never the training or the data import. The difficult bit is the integration with legacy systems. It’s one of the reasons why we’ve built Consonance to have such a wide breadth of functionality, so we have to integrate with as few systems as possible, and ideally with those of our choosing (the ones with decent APIs).

And it’s the same with people. The fun bit of any job is actually doing the job—and the worst bit is trying to get other people to help you, support you, to do the bit of the process that you need them to do before you can do your bit.

Systems implementation pain is in the interface with other systems; job pain is in the interface with other people.

So why not design teams so there’s a limit on the extent of that interfacing requirement?

Why not have the same breadth of functionality in your job as ERP vendors like us build into their software, for the same reason: so that you have as much control, elegance and simplicity as possible? And, as a nice side effect, you design far richer and more varied jobs.

‘Far richer and more varied jobs’ People cost companies a fortune in payroll, and so you want to get the most out of them. Putting them into functional silos does two things:

It radically increases the amount of time your people spend inwardly-focussed in the company, persuading each other to do things, and It radically decreases the creative output of people, because their sphere of thought and influence is limited to one specific area. Think of the digital ghettos that have formed of late in publishers, where management have cleaved off the “digital team” into their own corner, split apart from editorial and marketing, tasked with following their own separate agenda and priorities.

How much more interesting their output would be if they were integrated within the engine room of the company, present at the inception and during the development of books, rather than operating as a bolted-on afterthought, producing bolted-on afterthoughts.

‘Try to limit the number of times a task has to be handed off’ At my publishing company, we take this to extremes. One person does everything to do with a book, from acquisition to AI. Publishing isn’t engineering or medicine: every task in publishing can be learned by an enthusiastic person with a training budget, an eye for a nicely-turned phrase and a certain facility with Photoshop. But most companies won’t be quite as radical. Even so, you should try to limit the number of times a task has to be handed off to another person or department: that’s where the cost and complication lies.

The modern company needs to consider what success looks like for the whole mission, not just for each individual, and department, and then measure the whole joined-up team on that group achievement. So the trick becomes defining what that mission is. For us, success means “make things better”, not “produce software”, and that simple goal allows us to do away with more granular schemes of control, and enables a flatter hierarchy. Command and control isn’t necessary when everyone knows the grand plan and has the liberty and trust to do away with careful monitoring.

Specificity can be helpful here, though. Rather than your generic “become number one in the market”, make your goals more human-scale. Make them span all the roles in a process, and directly relate them to the work that people do. Success can mean “produce a high quality book, market it to the right audience and sell as many as possible” — which everyone involved in the book can understand, can relate to their role, can buy-in to and can feel proud of their contribution to: from the person who typesets, to the person who commissions, to the person who does the quarterly sales presentations.

Having control over a vast amount of the creative and business process may be daunting, but it’s a recipe for simplicity.

When you are all focussed on the same fundamental goal, you might have programmers participating in marketing, PR having input to editorial, editors helping with sales, production interested in customer service.

You’ve got a joined up process and goals that make sense to individuals and the company alike — a necessary state of being for a fluid, nimble, modern company.

Originally written for and published by The Futurebook, January 2016

Don’t outsource your publishing business away

2018-01-01T00:00:00+00:00

In the debate over whether to rely on outsourcing or develop skills in-house, I come down firmly on the side of learning skills yourself.

I wrote this article about keeping skills in house for DBW in July 2015. Read the full article at Digital Book World.

In the debate over whether to rely on outsourcing or develop skills in-house, I come down firmly on the side of learning skills yourself.

A major reason for this is personal satisfaction: competence and capability make you feel good about yourself. And by extension, a happy, motivated workforce makes for better publishing.

Another motivation is corporate worth. When the time comes to value your company—at divestment or when you’re looking to raise capital—skilled staff are a corporate asset and therefore increase the value of your company. Without the necessary skills, you’re nothing more than a trading hub: a shell company in which your staff are expert in briefing third parties, in networking and in the publishing process, but not in much else.

An even more important reason to add skills, though, is so you can know when you’re having the wool pulled over your eyes.

Have you ever had to brief an agency on something you don’t know much about? A website, perhaps? An app to accompany a print book, or a digital marketing project, heavy on the technical side? You know what you want the end result to look like, and you know what the user experience should be, but how you get there—well, that’s why you need an agency, because you don’t have the skills to do it yourself.

And so you have very little way of knowing if the response you receive from your tender is a decent, cost-effective solution. If not, it could be because the suppliers are borderline malicious—quoting a lot of money for not much work, because they know you’ve got no way of knowing. Or they could simply be incompetent, able to throw a website together but far from a well-written one. It’ll be one that might be difficult (read: costly) for other programmers to maintain. Either way, you can’t know if you’re getting a good deal or not.

Moreover, even if you get lucky and find an honest, reliable supplier, when you have to instruct other people you inevitably introduce distance from the original idea. The creative nugget at the heart of the project has to be explained, diluted and compromised. If you were building things yourself, on the other hand, you’d do justice to your creative idea, and it would be a hundred times less stressful (I promise you) than it is trying to get someone else to do what you want.

Even worse, if you brief outside suppliers and work with them, you’re giving them premium access to your precious domain knowledge and your hard-earned understanding of the publishing problem you’re trying to solve. You’re also allowing them to make money off you and internalize the knowledge that they didn’t work for.

If your vendor supplies generic services—an ecommerce web developer for all kinds of products, say, rather than a publishing-specific ecommerce web developer—they price in the additional risk of not knowing about your sector. That’s an extra cost.

And if you outsource, you can say goodbye to the process being in any way agile. Up-front design of major projects is exceedingly difficult—especially when it’s your first time designing, say, a transactional website. But if you want to get a cost for a project up front, you have to spec it out up front, almost guaranteeing that the project will go over budget and miss its deadline.

However, if you create your products and solutions yourself, you’re in complete control and there’s no disconnect between your idea and the execution.

Here’s how we write features for Consonance, the publishing management app that I and other publishers use to run our companies: first, we encounter a real life problem. Then we simply write code to fix it. For instance, I once sold French rights to a book that I hadn’t actually licensed the French rights for. This problem took a good week of frantic and hugely embarrassing phone calls to untangle. So we wrote a feature into Consonance to stop that from ever happening again.

These features are driven by real world problems, and I have the programming skills to fix them. Nowadays, you don’t even have to be a “proper” programmer. There’s an embarrassment of toolsets on the market that allow you to develop technical products and solutions in-house with only a smidgeon of technical know-how. Shopify for ecommerce, InDesign CC for ebooks, Trello for project management: none of these solutions require programming knowledge, and they allow you to remain in control.

The alternative to in-house skills? Outsourcing. Being dependent on others. Not having complete control.

For those who say publishing is about people, not coding or technical competence or project management skills, I can assure you that people are the first to suffer when things go off the rails. It’s a miserable existence to wake up every morning thinking, “There must be a better way,” or to feel slighted and foolish when people make money off you. I’d rather read a hundred technical manuals than feel out of my element, lectured to and exploited by outsiders, outdated, stung for a fortune or taken for a ride. How about you?

Emma and the Consonance team are running the second Try Programming course in Oxford, UK on Monday, September 14th on behalf of the Oxford Publishing Group. Book here.

ISBN is to book as what is to person?

2018-01-01T00:00:00+00:00

David Aldridge went to the BIC Building a Better Business seminar at the London Book Fair last week. Here’s what he found out.

ISNIs

There seems to be a push at the moment on one of those international standard identifiers that ought to be making everyone’s metadata more accurate (and in theory should make our lives easier), but which inevitably requires a certain breadth of adoption in order to get the required momentum.

What are they?

International Standard Name Identifiers are just what they sound like, with a few subtleties. Broadly speaking, they identify the public personae for a person or organisation involved in the production of creative works.

Typically, we’re talking about authors, illustrators, musicians, etc, but ISNIs extend to include organisations such as publishers, or imprints, or even fictional characters.

They look like this: 0000 0001 2103 2683

What are they good for?

Their primary purpose is to unambiguously identify a person or organisation. There are two key issues for publishers that they help with.

Distinguishing between people who have the same name. There are 38 different John Johnsons listed on the ISNI website
Identifying people known by different names in different cultures. There are 295 different spellings for William Shakespeare on the ISNI website: ウィリアム・シェイクスピア, for example.

If you’ve had the experience of one of your authors being confused with a different person on Amazon, then you’ve suffered from the problems that ISNIs are intended to solve.

Who assigns them?

The ISNI International Authority.

How should I be using them?

Authors who have published before are fairly likely to have an ISNI already assigned to them. You can look them up from the ISNI website, and enter them into Consonance. They will then be included in ONIX feeds, and we’ll add a link to the contact’s page to take you to the ISNI entry.

Six things to do the moment you get back from vacation (disclaimer – you might have to resign)

2018-01-01T00:00:00+00:00

So I’m just back from a glorious holiday up in Scotland with the boys. We piled onto the Caledonian Sleeper and spent sunny days on deserted beaches and up mountains, with blue skies and long lunches. It was glorious and for a few days, away from long days at a laptop, my spine straightened, I got some vitamin D and my brain got a bit of a rest.

And my word, things looked different when I got back. Clearer-headed and brighter, I saw immediately how to solve a code problem that had been baffling me for a few weeks. I saw what that tricky jacket design needed. I bashed out a UI refresh of Consonance — a few CSS changes which meant the difference between a slightly stodgy, busy interface and a calming, clean, uncluttered one. I bounced into client meetings full of renewed excitement about our projects.

It’s the classic thing about needing a break to rejuvenate the mind. So, just in time for your return from your summer holidays, here’s my hit-list of things to think about and do whilst you’ve got nice, fresh eyes.

1. Consider your goals

With your fresh-from-holiday brains, reflect on the bigger picture. The look of fascinated horror on the faces of the kids when they ask which year I was born in will only get worse as time goes by. It’s now acutely important to consider how many years I have left and what I want to do with them. Am I who I want to be? Do I like my job? Do I like the people I spend time with? What do I want to achieve before I die? Because if I don’t make sure I like the answers to these questions now, then I’m going to start running out of time. I’ll be dead by 2070, tops. Most likely I’ve got 35-ish years left. I’d better crack on.

2. Consider your job

When I was a buyer at B&Q I went to the doctor with the classic signs of stress. Shortness of breath, constant headaches, exhaustion. The GP didn’t prescribe me a magic pill. She said “Well, just get a different job.” At the time I was furious. Leaving that job was impossible — it was my dream job, everything I’d worked towards! Looking back, I agree entirely with her. The best solution to a problem is to solve the root cause. And it was an awful job, anyway, which I only realised once I’d resigned. You need a bit of space to see a bad job for what it is.

3. Assess your company’s goals

The same big questions can be asked of your business. It makes me roll my eyes when I see Twitter bios which say “all views are my own and not those of [my employer]”. Businesses are people. Of course your views are those of the place you work — and if they’re not, you’re in a job where you have to wear a mask all day and, mate, that’s tiring.

So ask yourself: are we happy producing the books that we do? In the way that we do? Are we happy with the sorts of authors we work with? Our customers? Do we wish things were easier? Faster? Or slower? There are no right answers: the main trick is to decide what “happiness” means to your company. Meeting budget? Being on time? Making other people — authors, customers — happy? Giving back to the community? Beating the competition? Being proud of your contribution to the sum total of human knowledge?

This sort of analysis can be hard to do from a middle-ranking position in the company. If you don’t like the answers, it’s difficult to bring about change. There are a couple of solutions to this. Learn how to influence the people you work with to move the company’s operations to match your desires, or find somewhere else to work. That may seem impossible — you’ve got your dream job, right? Please see point 2, above.

4. Assess your company’s workflow

With a bit of distance, coming back to a clearly dysfunctional workflow makes you even more impatient for change. If you can see that there’s redundancy, overlap, and a misalignment of responsibility, authority and capability, now’s the time to plan out how to change things.

We run a very productive one-day workflow workshop for our clients. In the morning we map out the existing processes of the company. We detail all the meetings, all the spreadsheets, all the places where the same data is maintained (or not), all the tasks that everyone does to get a book to market. By lunchtime, it’s immediately apparent where the overlaps and redundancies are. And so in the afternoons, full of optimism and thrills that we might actually be able to improve things, we map out how we want to work: who should do what, and when, and what the canonical source of data should be for each step of the process. Getting your workflow right is far more important than getting the right computer system. And you can fix it yourselves without expensive external consultants, for the price of a day away from the desk, some Post-Its and a marker pen.

5. Do long-form writing

Sometimes, when I’m working on Snowbooks things, I curse Consonance, because it only leaves the difficult work. I occasionally crave a quiet day doing mindless data entry — because writing and thinking is jolly hard. Use your holiday-fresh brain to do the difficult writing tasks that require the most clarity of thought. Prize entries, grant applications, strategic proposals, marketing plans, press releases, business plans — give me an 18-hour day writing code over these tasks, any day. I find writing excruciatingly difficult (quiet there, at the back), and I need a fresh brain to do it.

6. Learn to code

Because if you can’t resolve to learn how to use the tools of your trade when you’re refreshed and feeling rejuvenated, when is it ever going to happen? Seven years and counting, chaps. That’s when the kids who’ve learnt to code at school will start to graduate. So you’ll be coming to our next Try Programming for Publishers course, right?

Don’t waste the feeling of rejuvenation and freshness that the summer break provides on catching up with your emails. Make the next four months until the Christmas break count. Use them to make sure that, this time next year, things have improved. Because it’s urgent now: you’ve only got a few decades left.

Originally written for and published by The Futurebook, August 2015

To go direct, publishers must mean business

2018-01-01T00:00:00+00:00

Originally published on Digital Book World in 2015.

The arithmetic of publishing is fairly straightforward: Sell plenty of books at as high a margin as you can manage, and don’t spend all that margin on overheads.

To make that sum work, there are a number of levers a business can pull in order to improve its fortunes. You can increase the retail price to the point at which demand drops off. You can pay less for your stock by negotiating with suppliers. You can pay your authors less. You can provide a lower discount to your customers.

But back in the real world, Amazon isn’t going to bat an eyelid if you attempt to negotiate their discount down. Readers aren’t going to pay $30 for a debut novel in paperback. Printers aren’t going to charge less than their paper costs. Authors are going to revolt if you cut their royalties. While in theory you can tinker with the parameters of your business, more often than not, you’ll find yourself constrained by the habits of the industry.

So what can publishers do to make a difference to their works’ performance? If the norms of the contemporary publishing model constrain you, then don’t work within the constraints. Approach things from a different angle.

One area where publishers underperform is in their websites. Biztegra’s Murray Izenwasser has written recently about how crucial it is for publishers to develop a web presence for fostering strong relationships with readers. He’s absolutely right. But while that customer connection is indeed essential, it’s still a means to the ultimate goal of direct-to-consumer retail — which is retail.

It seems that as an industry we’ve given up on trying to make money through our own websites. Everyone just goes to Amazon, right?“ Well, Amazon doesn’t only sell books. They sell watches, clothes, garden tools, luggage, movies and bikes. Other industries have had to face down Amazon, not only book publishers — and they’re succeeding, building online stores that do a decent job of both cultivating a brand identity and making money. Check out the map-makers, toy sellers, wristwatch sellers and fake tattoo sellers — all commercially successful, all selling high volumes of product without giving 55% of the price away.

The point is that publishers must think boldly and move beyond half-measures if they are to remain agile and profitable in the digital marketplace.

You are being defeatist if you think your website is just about building your brand — even though it’s certainly about that, too. It’s also your most effective, most controllable, least costly means of selling books at a dramatically higher margin than you can ever hope to achieve through online resellers and bricks-and-mortar retailers.

You are being inefficient if you commission a custom-built site for thousands of dollars, with exactly the same functionality as every other publisher who also felt they needed a hand-crafted solution.

You are wasting money if you hand over 20% of every sale to a third-party plugin because you think delivering digital content is just too difficult.

You are deluding yourself if you blame the merciless merchant class and their exorbitant discounts and returns for stopping you from making any money.

What you can do instead is find some new performance-enhancing levers to pull on. Consider these three facts of the e-commerce landscape:

There are infrastructure tools that exist today allowing you to configure a profitable, automated, online offering for a fraction of the cost of what you had to pay just three or four years ago.

People shop all the time on the internet, and you can channel them toward your own site. Shopify, for example, found that “while organic and paid search still dominates, orders coming from social media grew 202% over 2014. Social media has become an effective way to bring in sales.” There are also platforms — Valobox is one — dedicated to monetizing social media interactions.

Plenty of people shop on Amazon, but they shop in many other places, too. Shopify reports that sales through its own stores alone were $3.7 billion, up from $1.6 billion last year, in 150 countries.

When you’re planning the sort of online offering focused foremost on making money, rather than on the important yet softer objective of building a brand, you don’t start with the design. That’s like buying a nice, shiny set of hub caps, then looking around for a car to go with them. Instead, you start with the flow of data. How is your metadata going to get from your publishing management system into your website?

The other practical issues come next. How are orders going to be taken and fulfilled? How will your website know whether the product is in stock? How will you execute your pricing strategy across all the different places you plan to sell books? How will you manage customer accounts and provide support? How will you upsell your interested customers or recover their abandoned baskets? How will you make your own website the richest, most up-to-date, interesting way for readers to enjoy your product data on the web?

Asking these sorts of questions leads you to appreciate the growing array of services that can provide affordable, effective answers to them. Publishers that assume Amazon has won their customers for good will be proved absolutely right.

The search for publishing's holy grails

2018-01-01T00:00:00+00:00

‘Ask me the questions, bridgekeeper. I am not afraid’

There are certain enigmas in publishing, certain problems that seem impossible to ever crack. Searching for their solutions is like a search for the Holy Grail. I’m talking about things like being able to forecast sales accurately, or knowing how profitable our ebooks are compared to other editions. Or finding happiness. “It can’t be beyond the wit of man”, you think, but, even so, year after year goes by without cracking the problems.

So, coconut halves at the ready, let’s go on a quest for some of these holy grails.

Accurate sales forecasting

Successful publishing is a numbers game—money out vs. money in. If we knew in advance what our sales will be—if we could get our forecasts right—then everything else would be a doddle.

Obviously, that’s not going to happen, but we can at least try not to make fools of ourselves.

When you sum up all of the sales you made on the products you sold last year, how did that relate to the sum of all of the forecasts? Was it 20 percent higher? 50 percent? 50 percent lower? And how did that vary by imprint, subject, and format? Maybe you forecast 50 percent over on hardbacks and 50 percent under on paperbacks.

If someone presented you with this information, would it change your future behaviour? It should. If your hardback sales are on average half of your forecasts, then your future forecasts must be halved. “It’s just a flesh wound!”

Reconciling statutory and management accounts

The next quest is to do with actuals, rather than forecasts. Statutory accounts are the performance numbers you have to submit to Companies House and the Revenue in one form or another. They chart the movement of all the money in, and all the money out, of the business in a financial year, and they allow for the changing valuation of assets: things such as copies of books in the warehouse, your computers and the buildings you own. They usually give a helicopter view: one number is the total of all home-territory print book sales revenue, for example, and another all the rights sales.

With management accounts, on the other hand, the clue’s in the name. These chart the movement of money for the purposes of managers being able to see what the dickens happened last year. The more detailed the management accounts, the more insight managers can get: title-level P&Ls are more useful than imprint-level P&Ls.

A title-level P&L will record sales and costs for one particular title. Sales revenue, less returns, for the hardback, paperback and ebook. Rights revenue, less the author’s cut. Print costs, editorial origination costs (typesetting, proofreading and the like), trade spend and so on.

Why should you be able to reconcile this low level of detail with the overview? So you can have confidence that all your numbers—which you’re using to make decisions about future business activity—are accurate. Why is it so hard? Because of overheads and aggregations.

Overheads are costs that are not directly attributable to a single title. How much of your office electricity bill should you apportion to your title? How much of your in-house designer’s payroll cost—they did the cover, after all? And your retained PR agency—they just send in a monthly bill. How much should be allocated to each title? What about the cost of warehousing, sales commission? The cost of running the stand at Frankfurt? And so on.

Aggregation is what distributors do when they helpfully send you a sales report that only gives you a fraction of the picture: “all ebook sales”, for example, or “all January sales”, or “all Waterstones sales”. What you really want is the lowest level of detail possible, so you can do what you want with it. But that’s not always forthcoming from OPS*.

It’s the different levels of resolution and categorisation in the available sales and costs data that make any reconciliation so difficult. And so, like Sir Galahad, you have to come up with an enforceable, meaningful philosophy.

You could decide that you’re going to apportion costs based on the performance of a title. Bestselling title A produced 80 percent of this year’s revenue, and so it should shoulder 80 percent of the shared costs, right? Well, that’s penalising your bestseller for being so productive. The alternative is equally dividing your costs by the number of titles on your list. That seems the greater of two evils, so perhaps we should accept that the penalty of being a bestseller is that you have to pay for everything else. If you consciously recognise that reality, it should inform your decisions. You might decide not to be too generous with your volume escalator, for instance: it’ll negatively affect your other authors because that’s the pot of money needed to pay for less successful books. Harsh realities.

For certain costs, it’s possible to apply a unit cost, or a percentage of sales cost, to the number of units sold. Sales commission, for instance, may be contractually agreed at 10 percent of net receipts. This is an easy line to include in the variable costs section of a title P&L. The trick here is having a system that lets you see what 10 percent of net receipts is at both a title and a company level, and then comparing that to the total of the supplier’s invoices for the same period. It’s possible, yet insanely boring and fiddly, to do it manually. It’s a good example of where programs can step in to help (and I’m not talking about Excel spreadsheets. Rant to follow at a later date).

Knowing how profitable our ebooks are

Once you’ve solved the title-level P&L problem, you have to think about the product-level P&L. Which format should shoulder the burden of costs that affect them all, such as typesetting, or translation? The hardback, because it’s the first published?

Does the ebook P&L even contain any editorial origination costs, or do we treat these as sunk funds, spent already to bring the print products to market? Again, you need to come up with a philosophy, then adopt the systems to put it into practice. And you have to live or die by that decision. If you decide to spread the costs of editorial origination evenly over all the formats of a title, and that shows that the ebook is woefully unprofitable, you should rightfully stop publishing ebooks.

Does that sound right?

Think through the ramifications of your philosophy before you settle on it.

Plenty of other publishing holy grails

“Make the data on Editorial and Production’s publishing planning spreadsheet match.” “Know what rights we can sell.” “Know what permissions we’ve cleared for which images.” Fit people’s skills to the tasks at hand. Run our royalties without making a giant fuss. Before you think on second thoughts, let’s not go to Camelot. It’s a silly place, the way to solve all these problems is the same: an ability to manage data, coupled with a clear philosophy and the drive to enforce compliance throughout the company.

*Other People’s Systems.

No computer system can fix a broken publisher

2018-01-01T00:00:00+00:00

With stability taking hold of the hybrid print-digital market after years of rapid ebook growth, many publishers are turning to evaluate how workflow automation and other IT solutions can streamline their businesses and make them more efficient.

That’s undeniably a good thing, but as I’ve written before, the allure of a new digital system or solution can sometimes introduce new problems in an earnest bid to solve old ones.

I talk to a wide range of publishers interested in implementing our Consonance publishing management software. But before we ever get to talking about databases, metadata management, interfaces or legacy data migration, we close the laptops, get out a Sharpie and some Post-It notes and talk about business process.

The point at which a publishing business starts to think about putting in place a new management system is a great time for a spring-cleaning of its processes. In fact, whether a publisher realizes it or not, the reason they think they need a system is usually because of problems with process, not data.

Yet that bigger picture rarely gets the level of scrutiny it deserves amid the daily hurly-burly of trying to keep a thousand tasks, deliverables and projects on track.

When publishers take the time to reflect on how they work and how well it’s working, though, they tend to arrive at more intentional and efficient ideas about their workflows and processes. That’s why we encourage all our clients to let us facilitate a day’s workshop for them. At those workshops, in the morning, we document how things work in the business, right now, using Post-It notes and a big wall.

We talk about how a publication gets from soup to nuts. We talk about how commissioning and acquisition works, about how the business considers and approves a manuscript put forward for consideration. We document how long the business allows for a book to go through its various stages of development. We write down all the discussions that have to occur and layers of approval that have to be passed—who’s involved and what each step is for. We write down all the names of the various documents that hold data. We articulate exactly how things normally happen to get a book to market in all its formats.

Do you know who, for instance, is in charge of writing back-cover copy in your organization? And who then signs off on it? Do you pass it by the author for approval? Or to senior editors to make sure that an imprint-level view is taken? What about series editors—do they have a say?

What about cost sign-offs—is there a stack of invoices waiting to be approved by senior managers? Can they see the context in which they’re signing them—whether they signify an overspend or are within budget—or is it just a pile of invoices needing signatures?

How do you handle a project’s transmittal from editorial to production? How long do you allow for proofreading? Is your in-house design team actually capable of meeting the deadlines for first and final cover drafts that editorial assumes to be reasonable?

What’s your canonical source of metadata? How many spreadsheets get maintained by different departments and individuals that contain roughly the same data?

And what we always discover—without exaggeration — is that there’s a lot of duplication, and a lot of assumptions about who does what, and when.

Lunch can be a sobering affair, during which the team may reflect, with some dismay, on their working practices. Don’t confuse that with snark; I would challenge any publisher to go through this exercise and feel that their workflow resembles a finely tuned machine.

Things pick up throughout the afternoon of our workshop, though, as it’s our chance to redesign the process for the future. The bottlenecks and duplication of data and effort that seem so obvious after our morning’s work get eliminated from the plan. We have some great, spirited discussions about who, precisely, should do what. I often see real relief from people who’ve been living with the effects of a poorly articulated process, who see simplification and clarity on the horizon for the first time in years.

It’s an exhausting day, as you can imagine, and sometimes it’s the first of many. But in time I email the team the first draft of their own “Publishing Manual.” It’s a document that, after many edits, refinements and discussions, will eventually be given to every new hire—“this is how we do things here,” with every part of the publishing process clearly written down. Responsibilities articulated, authority made clear. The roles of departments and individuals defined in writing. Timescales (both normal and crash schedules) laid out.

The document names meetings, and their frequency, attendees and expected outcomes. It states how the team will manage the canonical version of every sort of data, from contacts and schedules to metadata and printer estimates.

And almost as an afterthought, the Publishing Manual contains information about how the IT system will help—where the data will be entered and maintained, where meeting minutes will be captured and actioned, how sign-offs get stored and so on.

Because configuring a system to support a particular process is the easy part. Figuring out what the process should look like, on the other hand, is the larger problem. It’s emotionally charged, challenging, difficult and often frustrating. But it’s necessary and, ultimately, hugely beneficial for the business.

And it’s a prerequisite for the success of any significant systems implementation.

The real price of a strategy shift

2018-01-01T00:00:00+00:00

Whatever your strategy, you need to pay a “strategy tax.”

[I wrote this article about the cost of strategic shifts for DBW in March 2015. Alas, they’ve shuttered and taken down their blog content.]

That’s the name I give to the cost you’ll end up paying to support your business strategy.

Take Amazon. It has a hands-off strategy. Amazon doesn’t want to pay staff to answer phones; it wants publishers to be self-service. We don’t phone them or meet with them to discuss new titles or promotional proposals. Instead, we log on to Vendor Central or upload our ONIX feeds and ebooks via FTP.

We don’t negotiate with Amazon, either; we either click to accept terms or we don’t deal with them at all. And in return for publishers going along with this approach, Amazon has created tools for us to interact with them programmatically, remotely, automatically, efficiently.

Amazon’s “strategy tax”? Building and maintaining a decent, automated technical infrastructure that gives publishers the IT tools to distribute their titles to Amazon customers.

Like all forms of overhead, every company aims to keep its strategy tax as low as possible, and sometimes it shows. Most publishers have spent frustrated hours trying to get hold of a real person to ask why an EPUB file is stuck at “In Progress” on PublishToKindle with no error message. It recently took me four weeks to get a Vendor Central support call answered, and the issue still isn’t resolved. And the problems aren’t confined to suppliers; from a customer’s point of view, some of Amazon’s product recommendations are frankly bizarre.

A strategy tax left unpaid the first time around gets collected soon enough. The cost of not building a decent set of tools means more support tickets, more complaints, more perplexed customers—more knock-on costs throughout the business.

None of this is just to take a gratuitous jab at Amazon. It points up a real challenge for publishers and retailers of all sizes seeking to operate at scale in the digital marketplace. Keeping the requisite systems and programs functioning at the levels needed to do so is often an expensive, unending, organizationally challenging job.

But more than just the cost of doing business, paying enough strategy tax serves as a sort of social contract between companies: We’ll agree to do business your way, Amazon, if you provide us with the infrastructure to make it work.

At the other end of the spectrum, imagine a little independent bookshop. It prides itself on personal service. When you go in, a knowledgeable person is there to make thoughtful recommendations, and they answer emails and online queries with the same personal touch. The store gift-wraps books ordered from its website and encloses a handwritten note of thanks. The strategy tax for this business is to pay for a sufficient, high-caliber staff, make good on its promises to customers and take the margin hit on higher-quality packaging and first-class shipping.

Since strategy tax, in other words, is the toll a business must pay in order to set the terms of commerce, it also lays the foundation for a company’s brand identity—plus its brand integrity. Once your brand starts to make promises, you’ve committed to an unspoken contract with the people you interact with, whether they’re suppliers or customers. Sure, you can renege on this agreement. But it won’t do your brand any good.

If you’re thinking of changing your strategic direction, consider the strategy tax of your new approach. If you’re a retailer and your current method is to pile it high and sell it cheap—the discount model—but you have aspirations to turn your brand into more of a high-value proposition, then you’ll have to figure out how to fund the necessary changes.

It’s not just about paying to develop new branding. It’s not even about affording a new storefront, whether virtual or physical. The real costs are in lost sales and lost customers as you move from selling the low-cost, high-margin stock that you’re known for to the high-cost, low-margin range that you’ll have to introduce from scratch to a whole new customer base. And you’ll have to cover the additional staffing, training, service provisions and all the associated costs of making good on your new strategic promises.

If you change your strategic direction, you have to change the entire underpinnings of your business. Think of your business as an iceberg. The bit that pokes out the top, which everyone sees, is tiny compared to the vast infrastructure beneath. You can’t move the peak without a very good plan for shifting the underwater bulk it rests upon.

As publishers look more closely at selling books direct from their websites, all these strategy-tax–related decisions pile up, and they can be daunting.

You will already be considering the costs of building the website in the first place, the costs of transaction charges from credit card companies and the costs of shipping and delivery. But there’s also customer service. Will you need to provide a tracking service? Will you store customers’ account information and if so, what about the costs of properly maintaining personal data in line with legislation? Will you have to invest in writing copy to cement your position as the leader in your genre? Will your authors support you in that, and can you pay them for their work? And so on.

Amazon is powerful enough to be more or less inured to the effects of any problems its partners or customers experience as a result of its strategy tax deficit. Few companies are equally resilient, but few companies have so great a share of the weight of their industries on their own shoulders.

That means publishers planning strategic shifts can do so with the effects scrutinized under a less public glare. It’s nevertheless essential for publishers to calibrate the cost of strategic changes and resources to understand—before it’s too late—whether those shifts will leave the brand unscathed and the P&L in the black.

A day in the life of a programmer

2018-01-01T00:00:00+00:00

First published here.

Emma Barnes taught herself to code after founding her own independent publisher, Snowbooks. She went on to build Consonance, the next-generation publishing system. Now she’s on a mission to promote tech skills within the publishing industry and beyond. Emma is also on the newly-formed BookMachine Editorial Board.

6.50am

Wake up, wonder what day it is and remember – great! It’s the one day this week that I can dedicate to programming. I’m the MD of the indie publisher Snowbooks, and I’m CEO of Consonance, responsible for sales, finance, and customer success, so each day is very different. But I reserve at least one day a week for luxuriating in single-minded programming. It so happens that it’s a Saturday, but that’s when the emails stop… context switching is my biggest foe.

8am First coffee, and a read through the opening chapters of the new Sandi Metz book about object-oriented programming in Ruby. It’s great when you find a book that directly addresses the real-world problems you’re facing. I click through to a podcast that she’s on to hear more.

11am: Tests.

Yesterday I discussed a piece of code that needs some attention with my colleague, Andy. The code is a method which returns a collection of external URLs that gets displayed in Consonance. The URLs take you to a book’s Amazon.co.uk page, or Amazon.com page, or Wordery page, or British Library page, and so on — a handy and quick way to check what data is out there in the wild. The method doesn’t have automatic test coverage yet, so I’m going to start by documenting current behaviour. I do this using an integration test which mirrors what a user would do. We use Cucumber which gives us a common language between non-technical team members and programmers. I start by creating a new branch of the code based on our main branch, and create a Cucumber feature which literally reads “When I visit the ‘Autodrome’ page in Consonance, and I click on the Amazon.com link, then I should be taken to the ‘Autodrome’ page on Amazon.com”. I then write some code to translate that into automatic test steps.

1pm: The grand refactor.

The Sandi Metz book has given me a couple more clues as to how this method could be improved, and I’m trying to hold all the concepts in my head so I can look at the problem squarely. Sandi Metz talks about finding the right level of abstraction, so I’m trying to think about which objects this problem is actually concerned with. Is it the validity of the ISBN that is key? Or the destinations themselves? Or the structure of the URLs? Some are built using the ISBN-10, others with the ISBN-13. Will there be a future case where the URL is built using an ISSN, or a DOI, or an ASIN, or an ISTC, or an ISNI, or an ORCiD iD? If a book belongs to a series, can we say that the book has an ISSN? If its authors have ORCiD IDs, can we use those to create external links for the book? What about linking to the client’s own website?

Or is this a case of YAGNI (‘you ain’t gonna need it’)? All this matters because I want to put the code in the right place, named properly, so that we can find, and change it easily, later. Maintainability, in a large, active system such as Consonance, is probably the most important thing. I start by working with David to sketch out the problem (see the picture), then create a new Ruby class by adding a text file to my local code repository called external_links.rb.

Sketching out the problem

Like the common language provided by Cucumber, the challenge so far has been approached not with code, but with language, reading, grammar, discussion, and story. I reflect — not for the first time — on how relevant publishers’ skills are for programming.

2pm: Lunch

And back to the other Sandi Metz book I’m reading: Practical Object-Oriented Design in Ruby. There’s a good bit on page 93 where she talks about duck typing, which I wonder might be relevant. The idea about duck typing is that “if it looks like a duck and quacks like a duck, it’s a duck”. So my ExternalLinks class doesn’t need to actually be handed an actual book object in order to build the URL. It only expects to be able to get an answer when it asks “what’s your ISBN?” (even if it’s “nope, I don’t have one”). I could similarly give ExternalLinks a display spinner, or a CD, or a cassette audiobook: just so long as it can say what its ISBN-13 is. I’m going to use this idea to write ExternalLinks so that it’s not tightly coupled to the Book class itself – though I’m a bit worried that this is another case of YAGNI. I commit this code to my local branch, glad that I’ve named it “spike/externalurlrefactor” so that I can discuss this approach with my colleagues before considering it for a merge into our production system.

3pm: Iteration.

I run the test that was passing earlier and it fails. Huh. I abandon the integration test and start unit testing at a deeper level of the code. I realise that there’s a requirement I hadn’t understood: some of the destinations are dependent on format, as well as ISBN type. Writing the tests illuminate some of the nuances of the domain and I jump between revising the tests and revising the code (avoiding doing both at the same time which is a recipe for misery).

4pm

Leave to pick up my son, as I do every day of the week. Programming allows for flexible hours. It’s the sort of job that benefits from a bit of percolation, and fitting it around family makes me happy that I can experience life and motherhood as it happens, rather than only working hard for some imaginary future.

8pm

Share today’s programming. Bedtime is done, and I look at the code again, but I think I’ve got as far as my brain will take me today, so I push the code to a branch on Github, our remote code repository, and raise a pull request with my colleagues. I’ll look forward to discussing this approach with them on Monday and seeing if they notice any glaring or subtle errors, and suggest better ways to structure the code. [Postscript from the future: on Monday, we found no errors as such, but we improved the test suite and I got a lot of clarity about separation of concerns from my code review with Andy.]

10pm

Bit more of that Sandi Metz book. It really is very moreish. Practical Object Oriented Design in Ruby by Sandi Metz 978-0-321-72133-4

Discoverability? That's not nearly enough.

2018-01-01T00:00:00+00:00

Discoverability isn’t nearly enough. Discoverability relies on someone actively trying to discover something, which comes only at the end stage of the buying process. You need to catch people much earlier—long before they even know they want what you’re selling.

Enter “inbound marketing.”

Discoverability, SEO, keywords, rich metadata—get these things correct and success is yours, right?

Wrong, I’m sorry to say. Discoverability isn’t nearly enough. Discoverability relies on someone actively trying to discover something, which comes only at the end stage of the buying process. You need to catch people much earlier—long before they even know they want what you’re selling.

Enter “inbound marketing.” Google it and you’ll be amazed that you’ve never heard of it in publishing circles (though if you have, drop a note in the comments section and tell me where!). It’s been a growing force in the world of marketing ever since marketing software company Hubspot coined the phrase in 2006, when they realized that cold-calling, spam and other “interruptive” marketing tactics just don’t work all that well.

Inbound marketing is a wonderful idea, and, if you’re like me, it’s a concept that’s painless to adopt, because it’s the opposite of the hard sell. It’s about genuinely setting out to help people. It’s about sharing knowledge and ideas—and, ultimately, it gets your product found by people who really want to have what you’re selling.

This is how it works. First, you articulate the goals, challenges, pain points and demographic of your ideal customer. (As more than one writer has pointed out on Digital Book World in recent months, that’s no small task for publishers, but it’s absolutely essential.) Your description of your ideal customer—your “buyer persona”—then forms the center of your business plan.

Next, you write content that’s perfectly matched to that buyer persona. If you’re a cookbook publisher, you might have your top authors blog about food or have them create videos cooking with their kids. You might post excerpts from upcoming cookbook titles or share recipe ingredient sourcing tips on Twitter—whatever your ideal customer most wants. If you do it right, you’ll put your content in the places where your buyer naturally hangs out. It’s like the early stages of dating—a shared glance across the bookshop cafe where you go on the weekend.

When your ideal customer has seen your work, you try to find a way to continue the conversation: to carry on flirting. So you invite her to leave a way to get in touch. Having a newsletter sign-up box or an invitation to read more in exchange for an email address is a good way to do that. In sales-speak, at this point, she becomes a “lead.” She’s hopped into the hopper at the top of your sales pipeline. But don’t act all overbearing at this stage: not cool.

Next comes the leap of faith—the bit where you actually ask her out. Be brave! Don’t be weird! If you’ve got the perfect offer for her, use your customer relationship management (CRM) tools to get in touch. Let her know what you’ve got in the pipeline, and email her any information she needs. Then leave her alone. And hope for that first magical point of contact—the moment she buys something.

Finally, just because you’ve got her doesn’t mean you should lose interest. You have to delight your customer. Use surveys, more tailored content and social media to give her reasons to stay in love with you—and to tell all her friends how great you are.

I’m sorry to say, dear reader, that you’re being inbound-marketed to right now. Except for this sentence, nothing in this post mentions my own software product, Consonance, or my publishing company, Snowbooks. But I’m writing this article so that you’ve heard from me—so that you know the sorts of things that I think.

I’m writing it so that when, in the far-distant future, you decide you need a book about steampunk Martians or an enterprise publishing management system (or both! It could happen!) and you come across my books or software by searching for “title management software” or “steampunk Martians,” I won’t be a completely unknown quantity to you. I’ll be that nice lady who wrote that blog post about that thing that you read that time. There’ll be a familiarity, a nascent trust—the foundations of a relationship.

In fact, if you do it right, decent inbound marketing can actually nullify your competitors’ discoverability efforts. When your customer is ready to buy, she’ll know who to come to—direct, skipping the search stage entirely.

More likely, she’ll still search—but which of the search results is she more favorably inclined toward right from the get-go? The nice author or publisher whose blog she reads, or the faceless company that comes up on Google? I know, I know, your products are unique. But in a tossup between buying your book about bees and OtherCo’s book about bees, you’ve put yourself in a great position if she’s been enjoying your bee-keeping tips for the last six months.

Inbound marketing is so much better than the two alternatives: shouty “outbound” marketing and no marketing at all. This is something many publishers and authors grasp, but in the race to get the word about all your great content, lapses are easy to make.

So think of the inbound approach as a narrowing of focus in order to produce more reliable results. Want to attract the right visitors to that online shop you’ve gone to the bother of creating? Inbound marketing is the best way to spark up a meaningful, fruitful relationship with customers who love what you’re doing.

[I wrote this article about inbound marketing for DBW in February 2015. Alas, they’ve shuttered and taken down their blog content.]

Three ways to do more with ONIX

2018-01-01T00:00:00+00:00

A quick primer: ONIX is a list of tags that we in the book trade have agreed to use to describe our books to each other. Arbitrary though they may be, the consistency prevents confusion.

Take an author’s name, for example. The people who decided on ONIX tag names could have chosen “Author Name” or “Author First Name” or “Author Last Name.” But they settled on tags like “Contributor” and “KeyNames.” So now everyone who sends or receives an ONIX message knows exactly what the data mean.

Having a lingua franca such as this is hugely helpful. Over a decade after ONIX was first introduced, it’s no wonder that, nowadays, being able to describe your books using ONIX is now an absolute necessity for any publisher, large or small.

Once you’re ONIX-compliant, your data get sent to the data aggregators, and that’s great. But if you find yourself still having to manually type data anywhere—for your catalog, for your tipsheets, in emails, into spreadsheets for customers who are not yet receiving ONIX—then ONIX can help you, too.

Not all ONIX is created equal (ironically enough, for an XML standard). For example, Amazon’s PublishToKindle requires the tag in addition to the and tags, and fails silently if you omit it: ONIX will still validate without the inclusion of <TitleText>. So it helps if you know your way around the standard—and actually using ONIX to create documents is a great way to get familiar with it.

Let’s have a look at how three other programs you already have on your computer can deal with ONIX.

Spreadsheets

Open up Excel or another open-source spreadsheet program like LibreOffice or OpenOffice. In LibreOffice, for example, go to Data › XML source and find your ONIX file on your computer or network. You’ll see the structure of ONIX appear. With a bit of clicking, you can map the ONIX fields to spreadsheet columns. Pick out “TitleText,” “Contributor,” “RecordReference” and “PublicationDate” to get your bearings. Click OK and see your data appear in a flash.

Word Documents

The same goes for Microsoft Word. In Word 2007, for instance, create a new macro from the developer tab. (To show the developer tab, go to the Office button and click “Word Options” at the bottom of the dialog box. Click “Show Developer Tab” in Ribbon.) Paste the following into it:

ActiveDocument.CustomXMLParts.Add ActiveDocument.CustomXMLParts

and load your ONIX file.

Next, create tags in the Word document where you want the XML data to go. On the Developer/Controls tab, insert four of what Word calls “plain text content controls,” which is a placeholder tag for your data, just to get started. Now, map the tags to the XML data. Create a new macro, and paste in the data here.

Run the macros in the Word doc (you’ll probably have to save it first). And voila! the fields update with the ONIX data.

Adobe InDesign

Finally, let’s look at Adobe InDesign, the application many publishers use to their seasonal catalogs (among other things). InDesign handles XML pretty well.

Read the article here. Download the zip file, which contains an InDesign document, a sample ONIX message, some XLST to transform your ONIX into something more useable by InDesign and some images. Follow the instructions within to make a perfectly laid-out InDesign catalog magically appear. Switch out the images and ONIX with your own images and ONIX, and you’re on your way to saving a huge amount of time and effort, every season.

There are more things you can do with ONIX, to be sure. At a very low level, try opening an ONIX file in a proper text editor such as TextWrangler or TextMate. The syntax highlighting helps you see which bits are data and which bits are tags, and a decent text editor will indent XML nicely so you have half a hope of being able to read it.

In the InDesign example above, we used XSLT to transform our ONIX into another sort of XML, using InDesign as a processor. You don’t need to use InDesign, though; you can convert ONIX into another sort of XML—including XHTML (yes, web pages!)—using XLST and SAXON on the command line or even a web-based processor (google for transform XML web).

Because XML is, by its nature, structured, you can manipulate it with very simple programming to remove, modify and copy elements. For instance, you can use the Ruby Nokogiri gem to manipulate ONIX to your heart’s content—to add agency pricing, for instance, or to set the UK GBP price from the USD price by applying business rules.

All this manipulation can be a bind, of course, and if your bibliographic data management system is any good, you’ll be able to export data directly from it into whatever format you need, whether that’s a 1,000-page PDF catalog, a cut-down XML feed for InDesign to handle with less fuss, the Samsung ebook spreadsheet or CoreSource-flavored ONIX. But it’s still very useful to be familiar with ONIX terms, and playing around with importing it into a variety of programs can be both enlightening and productive.

But be warned: it’s very moreish. Once you get a glimpse into the sort of world where you can create a thousand catalog entries or a back-list order form with a single click, there’s no going back…

A publisher’s guide to APIs

2018-01-01T00:00:00+00:00

API is one of those acronyms you hear bandied about. “APIs”, people say, “are vital. Vital!” But if, as you fervently nod in agreement, you’re thinking of another acronym — “WTF?” — then this article is for you.

“API” stands for “Application Program Interface”, which means “a way to interact with a program”. Actually, the sorts of APIs that people get most excited about nowadays are RESTful APIs. In English, that means “a way to send and receive data between programs on different computers, over the internet”.

If you can get computers to send data to each other, that can be very useful indeed. (It’s why the notion of the internet was so moreish.)

For example, you can get data from Amazon’s computers onto the computer that runs your website, which can display it. Even better, you can get your own computer to look at the data that Amazon’s computer sends you and check if it’s correct — so you don’t have to visit 100 Amazon pages to check with your human eyes. You can get the data of your Twitter feed from Twitter’s computers and display that on your own website — or, even better, you can ask Twitter’s computers to send you every tweet that contains a mention of the next 90 books you’re launching and display them on your website, without you having to look each of them up.

You can write your own API so other computers can access your data, too. You could turn the chapters and paragraphs of your forthcoming book about Edinburgh Castle into data that other people’s computers could get, and they can display it on their own websites, or in an app, alongside their own design, pictures and content.

You probably knew all that. But you might not know how it actually works. First off: what does an API look like?

Here’s the result of a query, or ‘call’, to the Google Books API. Here’s the call that was made:

https://www.googleapis.com/books/v1/volumes?q=isbn:9781909679368

Ooh, that’s familiar! It’s a website location! When a computer queries an API, it’s going to a normal old website location, handing over any username and password that’s required, and fetching whatever’s there, or posting new data to the program.

Click on that link so it opens in Chrome or Firefox and you’ll see that the result of an API call is… data. Structured data, though, arranged in a format that’s more convenient for computers than humans to understand (in this case, JSON). It’s still got English words in it, though, so we’re in with a fighting chance of understanding it. You can pick out “authors”, “title”, “ISBN_13” and so on in all that.

And if you know a bit of programming, you can display that data nicely on a webpage. Have a look at this JSFiddle (which is a handy free tool for fiddling around with javascript and html, as the name suggests):

The Result tab shows the data presented nicely, pulled live from Google Books. The Javascript tab shows how it’s done. Neat, huh?

Now – this is the cool bit. You’re going to run your own API query.

Click here to edit the JSFiddle. Don’t worry – you can’t break anything. You’ll see four panes. The first has the HTML – that’s the language that webpages are written in. The one beneath that has some javascript – that’s a language that can perform actions without having to refresh the browser. At the top of the next column is the CSS, used for styling a webpage (and this pane is blank – we’re including a style library called Twitter Bootstrap, automatically). And beneath that we have the result – exactly how the code looks on a web browser page.

Find the line in the Javascript pane that reads:

$.getJSON("https://www.googleapis.com/books/v1/volumes?q=isbn:9781909679368", displayBooks);

and change the text isbn:9781909679368 to something of your choice. So: say you want to search for books about quilting. Change it to this:

$.getJSON("https://www.googleapis.com/books/v1/volumes?q=quilting", displayBooks);

Now click on Run, top left. And see what happens in the results pane! You have made a little scrolling AI all about quilting. Try something else: churches, or snow, or programming. Tinker with anything else on this fiddle and see if you can use other bits of data from the API.

So well done: you’ve had a tinker with the Google Books API. There are loads of APIs out there – from Flickr, LibraryThing, Goodreads, Open Library, and Consonance, of course. Here’s a list of 53 of them. The possibilities are endless and it doesn’t take long to learn enough code to be in control of the world’s data.

Exciting, isn’t it?

Originally published on BookMachine, January 2015

And now we are five

2018-01-01T00:00:00+00:00

I’m beyond delighted to share some wonderful news. Andy Pearson will be joining the Consonance team on Monday, bringing our numbers to five: he’ll join Rob, Dave, Emily and I in our ongoing mission to liberate publishers from drudgery to do the work that matters.

On a personal note, this feels like a coming of age. I wrote the first line of Consonance’s code at the kitchen table in spring 2011, Ruby on Rails textbook on loan from Rob in one hand, typing with the other. Since then I have learned more than I thought my brain could absorb about programming. Later, I met Dave, Consonance’s data architect, who brought his decades of Oracle expertise to the code. Recently, we hired Emily, whose first few months have been a whirlwind of bringing more insight than I thought possible about our app, our customers and our future. And now we have Andy, a seasoned, super-bright programmer fresh from digital services agency Friday. He’s been working on beautifully-tested, honed-and-buffed apps for clients such as Nuffield Health and HSBC, and now (he says) he’s looking forward to joining the world of publishing.

Exciting times. Exciting times indeed. We hope that they’ll result in an even better experience for our customers, now and into the future – because that’s what this is all about.

Why publishers must use direct sales

2018-01-01T00:00:00+00:00

If you were writing a business plan to set up a new consumer goods business, which of the following two strategies would make most sense?

Strategy 1: Identify a market which, while mature, has publicly suffered of late, with a series of high-profile failures, and whose future is uncertain. Agree with these high-risk target customers that they can return your goods for full credit up to 18 months after invoice. Agree to a pricing structure with them for your products that will be only a shade more than they’ll cost you to manufacture. Agree to weak terms of payment 90 days after end-of-month of invoice. Get your products designed, specified and pretty much ready for sale 12-18 months ahead of when they’ll actually go on sale. Go to extraordinary lengths to woo customers, begging and scraping for your product to be one of the lucky ones picked for listing, and fail more often than not. Manufacture more than you’ll likely sell, six months beforehand, and pay for storage of the excess stock until you write it off.

Strategy 2: Have your product time to market capped at 12 weeks. Manufacture little and often, maintaining a low stockholding policy, using just-in-time manufacturing principles to keep stock fresh and fast moving and stock storage costs low. Maintain virtual inventory wherever possible. Identify customers who demonstrate their demand for your products early and vocally, allowing you to forecast sales based on real customer demand data. Ensure that you can access those customers directly, through email contact, or at events that you know they’ll attend, so that you can check that they’re happy, hear what their feedback is and talk to them about your next products. Sell to them at a price well above cost and ensure logistical expenses are covered.

Strategy 1 is, you guessed it, trade publishing. Strategy 2 is direct selling of POD or short-run physical books and ebooks. If I were pitching Strategy 1 to an investor, I’d never get it approved.

I write this on what the UK media refer to as Panic Saturday, the last weekend before Christmas, as retailers slash prices to clear their overstocks. UK Black Friday was a washout because the market has shifted online, and brick and mortar retailers no longer enjoy a semi-monopolistic position. Customers have options for where they spend their money—not just bricks and mortar, but online, and direct, too—and they’re exercising them.

Sure, I love bookstores. I love museums and forests, too. But I have a small business to run, authors and staff to pay, kids to feed. I have to take a pragmatic approach to risk management. As a customer group, to me, bookstores are low margin and high effort. Their business model is under threat. The supply chain they favor features high returns and long lead times. It’s not my job to speculate as to whether bricks and mortar retailing has a future (as someone who enjoys shopping in them, I hope they do). But as a business owner, all I see is what’s in front of me this year, now, which is that retailers are no longer as attractive to a customer group as they once were.

Over the last few weeks, my little publishing company has enjoyed a runaway success with a bestselling paperback that happens to be rather novel. It took off because of a Facebook post, which got 500 shares in the first day, then 1,000, then 6,000. The orders have all come through our own website. Why’s that? Because for the first six weeks, it was the only channel to market for this book. This method allows me to know who ordered it, and from which device. I know their email addresses and whether they’re willing to hear more news from us about similar books. I know what they think about the book because I can see their posts about it on Facebook. They paid enough to cover postage and packing, and, since each bought only one or a couple copies, there was no discount on the retail price.

And as well as those who kindly bought the book, I know a lot about those who didn’t. I know who put the book in their basket and what time they abandoned it. I have their email addresses, so I can provide them with incentives or a simple reminder to complete their purchase. For future visitors to our site, I can offer them bundled deals, and I can let people know when the next book by the author and illustrator is out. I can keep them posted on wider news through our newsletter and I can say thank you for being a customer by emailing them discount codes.

Direct sales provide higher margins, and they allow a direct relationship with the reader, which affords amazing insights into what customers actually want. It’s a business model I’d be far happier to bet the farm on than the alternative.

Learning how to code, the long way around

2018-01-01T00:00:00+00:00

I’d always meant to learn to code, but there never seemed to be a good time.

I graduated in 1996 with a degree in archaeology and got a well-paid job as a management trainee. I zoomed up the corporate ladder, doing what I thought successful people did: getting promoted and joining a prestigious management consultancy — until I realized that writing PowerPoint slides for sixteen hours a day and saving giant corporations millions on their stationery budgets was all a load of nonsense.

Instead, I wanted to do something meaningful and skilled and — gasp — fun. So in 2003, I co-founded a book publishing company called Snowbooks with my best friend. What could be more important, more deserving of effort, than books?

You Are The Hero: a history of Fighting Fantasy, by Jonathan Green. Published by Snowbooks 2014. More than 50 5-star reviews on Amazon!

It wasn’t a particularly brave move. I reasoned that if Snowbooks failed outright, the worst case scenario would be that I’d just get another of the same sort of awful job I was already stuck in.

Thankfully, it’s been a superb ride — and I’ve learned lots of things along the way.

Innovation is easier when you don’t know how things are meant to work

Building Snowbooks gave me a chance to dabble with technology as well as explore the creative aspect of the business.

From the start, we used XML to automate the creation of our marketing materials in InDesign. We used off-the-shelf packages such as Microsoft Access and Filemaker to write little database programs to keep our data in order, to calculate our royalties and to keep track of our sales.

I didn’t know anything about publishing before starting the company — which made innovating a lot easier. Whilst my programming capabilities stopped abruptly at the ‘hobbyist’ level, our business focus and innovations won us awards and a pretty high profile in the industry.

Disasters often have silver linings

And then, disaster struck. 2010 was the year from hell, which brought a series of personal and business crises. By the end of it, I had little money, and my trust in human nature was completely shattered.

At last, the time had come to learn to code. It was the perfect antidote to my personal crisis.

Looking back, coding was just the sort of logical, immersive, rewarding activity I needed to focus my mind, regain my self-belief and give me something to work towards.

Ruby on Rails rocks

I needed to build some sort of new system to allow me to store all my Snowbooks data — by this time, there was a lot of it, and it wasn’t very well organized.

I remember my best friend recommending Michael Hartl’s The Rails Tutorial as a gentle but thorough introduction to the web development framework Ruby on Rails. Later that day, I sat on the sofa, laptop at the ready, tutorial book in hand — and all my cares slipped away. This magical, open-source way to create significant, functional websites out of thin air, just by typing into a text editor, blew my mind. I was hooked from the start.

Learning to code takes time, but holy smokes, it’s worth it

Days passed, and I got to grips with the basics of Ruby, databases and HTTP. Weeks passed, and I finished The Rails Tutorial. By following its instructions, I’d recreated my own version of Twitter, with my own hands!

Months passed, and I started to apply what I’d learned to build a book data management application. First, I tackled title metadata, and then contacts. Contracts, rights and royalties came next, then production management, sales and workflow. I called my application Consonance — my pride and joy; my phoenix from the ashes.

Years passed, and I racked up thousands and thousands of hours of coding. Consonance went through hundreds of iterations, several times being razed to the ground and rebuilt, as my skills developed and I realized there were more elegant ways to write the code. My friend and I teamed up with another developer, whose Oracle and SQL expertise brought new depths to the application.

The buzz of coding intensified as I got better. I’ve been lucky enough in life to discover several pastimes which seem to make time stand still — playing the piano, boxing, reading — but none of them match coding for its achievement highs, its need for pureness of concentration, its excruciating, frustrating, infuriating, brilliant challenge.

Code is learnable. Knowing your industry is the hard bit.

I’d written Consonance so I could run Snowbooks properly, but in 2012 other publishers started signing up to use it, too. It was almost accidental: in conversation with my publishing friends, I realized that the exact reasons I had needed a comprehensive, cheap, elegant system were shared by other publishers just like me.

By writing software that solved my real-life problems, I’d created something that had value to other publishers — something that I could turn into another business.

Setting up at the London Book Fair, April 2015

I have found that understanding the problem is far more important than knowing the code. Code can be learned. A real understanding of the problems of an industry only comes about when you’ve lived it.

Don’t write features: solve problems

If you’ve lived, worked and breathed the publishing industry for a while, you’ll recognize some of its problems.

For instance, you’ll know what I mean when I talk about the “spreadsheet from hell,” printed out on A3 paper in an impossibly small font, covered in pencil annotations. Every publisher without a decent system has one. Editors clutch it to their hearts as if their life depends on it. It describes their list — the books they’ll publish in the next 18 months, the dates that can’t be missed, the vital information about specs and printings. These spreadsheets are difficult to maintain, don’t interact with other systems, and everyone has a slightly different version — all of which causes chaos.

And if you’re a publisher, you’ll understand me when I talk about the strain on editorial assistants who went into publishing for the love of books, but who spend their days copying and pasting metadata into retailer spreadsheets, webforms and advance information InDesign templates, wondering where their dream went so wrong.

And if you’re a publisher, you’ll understand that being able to produce decent royalty statements isn’t a bookkeeping exercise: it’s an expression of a publisher’s regard for its authors. Lateness, inaccuracy and a lack of clarity in these statements is rightly taken as a personal slight. Authors hand over their precious words to us as a mother hands over her firstborn to a nursery. We must protect them and treat them with the utmost respect.

Systems aren’t a place to store your data. They are a means of making good on your promises and a way to nurture your relationships.

You’ll also understand how delighted I was to discover Shopify last year, because until then we hadn’t solved the problem of how to provide a low cost, lightning fast, efficient, gorgeous way to carve out a home for our publishers’ books on the web.

We’ve written an API between Consonance and Shopify: not only can Consonance now send data to retailers, wholesalers, and data aggregators in the right format, but it can feed a publisher’s own home on the web with no more effort than the click of a button to trigger the API call.

Have a look at Snowbooks.com, which is based on a tweaked version of the free Shopify Supply theme, and which takes a data feed from Consonance. It uses metafields and custom collections to add publishing-relevant data such as series, publication dates, age banding, author information, and more. It also only took me a few days to configure.

Eat your own dog food

I’ve grown a publishing company from scratch, I’ve spent more than a decade immersed in the industry, and I’ve built software based on the needs of the publishing process. That’s why Consonance is so popular: it’s been built to solve real problems. My Snowbooks team and I use it every day to run our own business, which keeps it relevant and sharply focused on solutions, not features.

Snowbooks.com

It takes a long time to be an overnight success

And so, twelve years after I left the corporate world, Consonance has just launched out of beta with customers from throughout the publishing world — academic, trade, children’s, illustrated, and digital books. Our clients at launch range from start-ups with a handful of publications, to established presses with thousands of books on their backlist. Most of them will be using Shopify to showcase their wares to the world.

To the outside world, we look like a new company who’s hit the ground running and has achieved overnight success. But it would be a mistake to overlook the long journey, and our deep roots in our industry — which has been the key to our success.

I knew my industry, and the code took care of itself. The occasional disaster along the way just added fuel to the fire.

Originally written for and posted on the Shopify partners blog in June 2015

Responsibility, Authority, Capability

2018-01-01T00:00:00+00:00

Publishing is full of tensions. Indies versus conglomerates. Trade versus academic. Start-ups versus established companies. Outsiders versus insiders, geeks versus luddites, progressives versus reactionaries, self-publishing versus publisher-publishing. We can all learn from each other and it’s in the conflict that the interesting conversations happen. But there are also some universal truths which bind us all.

First off, we’re all trying to stay in business. That’s a fairly universal imperative. No one’s actively trying to run out of money. And, secondly, we’re all trying to live decent, fulfilling lives. The balance might sometimes be a bit skew-whiff: in a large company, the workers might be obliged to try to make the shareholders’ lives a bit more decent and fulfilling than their own. But there’s no one working in publishing who deliberately set out to have a horrible time of it.

So if we’ve all actively set out to thrive, why do publishers so often have stress, anxiety, miscommunication and conflict between people and departments?

It’s true. You see editorial at loggerheads with production; sales irritated with editorial; frustrated digital teams; exasperated contracts managers; put-upon editorial assistants. These are the same sorts of interdepartmental, interpersonal tensions that I used to see all the time in retailers, utilities companies and FMCG suppliers when I was a management consultant at a large City firm in a previous life. It looks like it’s another universal truth: in every company, in every industry sector, people are not getting on well with each other.

And why is that? It’s because people are awful.

“It’s as if she doesn’t want us to succeed!” you hiss to one of your less awful co-workers at the imaginary or actual water-cooler. She just doesn’t do her job properly. She stops me doing mine! She doesn’t care about my problems and, oh, when she goes on holiday, she’s even more annoying because she leaves everything undone so I can’t do my job. You stop for breath, but you’re on a roll: I can definitely do my job quicker without her being involved. She needs to be convinced of everything! She’s so obstructive – I’m sure she costs the company more money than she makes. You know what: I can do her job better than she can. Sometimes I wish I could just do it all myself.

OK. People aren’t really awful, of course. So what can the real problem be?

It’s a question of responsibility, authority and capability.

She doesn’t do her job properly. She stops me doing mine. She doesn’t care about my problems. She leaves everything undone so I can’t do my job. These feelings arise because there’s no clarity around who is responsible for what. You think that your co-worker isn’t doing her job properly: has anyone explicitly told her what the responsibilities of her job are? Is she measured against them, at a regular appraisal, with performance objectives? Has anyone ensured that her responsibilities don’t clash with yours? Has any senior manager ensured that everyone’s responsibilities align so that the company’s workflow is joined up?

I can do my job quicker without her being involved. She needs to be convinced of everything. She’s so obstructive! These feelings arise because you haven’t been given the authority to do your job properly. If you have to convince people to help you to do your job, it’s because they have neither been told what your responsibilities are, nor that they have to support you.

She costs the company more money than she makes. I can do her job better than she can. I wish I could just do it all myself. These feelings arise because people don’t have the right capabilities – sometimes skills, sometimes knowledge, sometimes inherent competence – to meet their responsibilities.

Here’s an example. The Big Boss went to a conference where he heard a rousing, inspirational speech by a publisher-turned-coder whose immense powers of rhetoric persuaded him to go back to his team and insist that they prioritise metadata management. After a day or two, the gloss wore off and he decided to make Ellie, the most recently-appointed, recently-graduated editorial assistant, responsible for metadata. (Don’t be that guy. Don’t entrust the most important means of communicating your brand to an inexperienced office junior.) But he didn’t alter anyone else’s performance objectives to require them to support the office junior in this mission-critical task.

So the next morning, Ellie asked Catherine, the rather forbidding editorial director, for the five missing blurbs, three missing publication dates and four missing covers for the Summer list. And Catherine asked Ellie, in a rather snippy voice, to come back in a week, with a tone that implied that Ellie might be in a tiny bit of trouble for interrupting her.

Ellie had been given the responsibility, but not the authority, to manage the company’s metadata. There’s no way she could succeed without the correct authority – and so the company’s success suffers directly. Further, Ellie doesn’t have the right capabilities – the power of persuasion or being able to manage upwards – to make the best of it.

As I say to my six-year-old, you have to eat your main course before you can have your pudding. In publishing, it’s tempting to focus on the puddings: the exciting new digital opportunities, the digital marketing initiatives, the disruptive technologies and the new ways to support authors and sell books. But you need to have the basics in place before you can build new worlds. Formally aligning people’s objectives across departments is absolutely fundamental, but publishers aren’t very good at it.

So: does everyone in your company know who is responsible for what? Do people’s responsibilities conflict with each other? Has someone sat down to make sure that everyone in the company is working toward the same goals – or are, at least, not working in direct conflict with each other? Are responsibilities formally written down and are people measured against them? And, most crucially, are people measured against supporting other people’s objectives? If this last point is true, it means that people have been given the authority to get their jobs done.

You can run down a checklist of key publishing tasks and think about whether your company is clear on who’s responsible, whether they have the authority and whether they have the capability to be successful. Creating the catalogue, managing metadata, deciding pricing strategies, running digital projects, ensuring contracts are signed before publication, buying paper, doing key customer presentations, managing the company website. All these tasks, and more, require a unified effort to happen efficiently.

On the face of it, you’d think that my job implementing Consonance in publishing companies is all about systems. But the most important part of any implementation is not configuring code or migrating data. It’s making sure that the company’s workflow is supported by a recruitment, performance management and training approach which means people have clearly defined responsibilities, the right level of authority and the right capabilities. Without these three elements in place, too much energy gets wasted on internal machinations, to the detriment of the books, the authors, and your happiness at work.

Don’t set broken processes and policies in stone with a systems project.

Fix your responsibilities, authorities and capabilities first.

Originally written for and published by The Futurebook in February 2015.

Publishers hack their own bibliographic data

2018-01-01T00:00:00+00:00

Well, that’s an intriguing headline.

Perhaps an even more stunning headline is Publishers Hack Their Own Bibliographic Software and the Software Provider Rejoices.

There was jubilation in the Consonance office yesterday when Nick Barreto at Canelo sent an email about his shiny new tool that helps his team search Consonance data from inside Slack.

It’s a fairy tale of well-built software supporting a forward-thinking publisher to streamline their workflow, so they can focus on the publishing.

In fact, it is the story of Consonance itself – publishers knowing what tools they need, having or gaining the coding skill to make those tools, and making them happen. No need to spend vast sums of money training developers that don’t understand the domain. Just spend a bit of time and get it done.

How can your team save time? Get the information to where they already are. Nick’s solution should save his team much clicking. We are so proud to have software that can support extension and improvement and innovation.

On top of that, Nick has made the code for the Slack integration open source, so that any other Consonance customer can use it. This is exactly the kind of community we want our customers to be a part of, exactly the kind of community we want publishing to be. Let’s spend less time on drudge so we can spend more time selling books.

So, join us in celebrating Nick and all #publisherswhocode. We look forward to sharing and creating more innovation and automation with you in the future.

How to avoid making a rod for your own back with data

2018-01-01T00:00:00+00:00

In programming, there’s a concept called “technical debt,” and it’s one that has much to offer as a way of thinking about your publishing business.

Technical debt is what you accrue when you write bad code or take some expedient shortcut or just think, “Nah, that’ll never be needed.” At some point, you might have to pay that debt off, or, in other words, fix the code. And technical debt accrues interest, as it gets more difficult to fix as time goes by.

Technical debt is inescapable, partly because it is accidentally introduced, but also because it is often accrued deliberately. If software were refined to be absolutely future-proof and guaranteed to work a hundred years into the future for every conceivable situation, then nothing would ever get finished.

So you have to accept that you’re going to accrue technical debt, because, in a way, it is part of being efficient; you’re fixing the problem in front of you right here, right now, and there may never be later repercussions.

Publishers accrue their own unique forms of technical debt.

Take, for example, a publisher that uses non-standard, imprecise or time-dependent terminology. They might refer to “Europe” or “the Commonwealth” or “Latin America” in the schedule of territorial rights licensed in their author contracts.

Fast-forward five years to an almighty spat with an author who assumed “Latin America” excluded French Guiana, being a non-Spanish-speaking nation, where she would like to sell the rights herself but where you’ve already licensed an edition.

EU membership changes over time (sob). Does Europe include Russia? Greenland? Does your marketing team have the same understanding of “Europe” as your rights team does? Being aware of the existence of nuances and ambiguity in your data will encourage you to work at a suitable level of specificity. The forms in which debt accrues are practically innumerable.

Having one ISBN-13 for all ebook formats comes back to bite you when your shiny new metadata management system requires ISBNs to be unique, or when your new B2C website platform can’t distinguish between PDFs and EPUBs. It was expedient to keep all your contract data as paper copies (you didn’t even send a photocopied version to offsite storage, you say?), but now that you’ve grown enough to need a royalties and rights system, it’s payback time.

Not recording permissions at the time they’re cleared makes for a giant legal bill when the time comes to sell off an imprint, or at least a penalty for the risk that the buyer is adopting.

Agreeing to an unusual royalties structure is awful at the next royalties run, and continues to be awful until the damned thing finally goes out of print.

Being unable to assign a unique ID to an author is a huge problem when you sign up a second “Joan Smith,” or when an author gets divorced and changes her surname.

That Excel spreadsheet was great for storing sales when only one person had to access it at a time, but now there are four people, and two of them work from home!

Look around you, at the desk and screen where all those important paper notes hold vital information for the next few months. You can’t enter them on your MacBook, because who’s going to back that data up? Nobody — that’s who.

So, as developers, we are alert to and aware of the technical debt we accrue as we code, and we compare the benefit of making our code as bombproof as possible with the additional cost and time that it will take. And as publishers, we are aware of the decisions we’re making that lead to our own form of debt.

And that’s the first step on the path to managing this debt properly: awareness and acceptance.

But what are the solutions? They are often clearer once you’ve realized the problems at hand. Use a free OCR service such as Evernote to scan and store contracts so you can actually search them in the future, wherever you are. Consider migrating your current desktop software to a cloud-based service, such as Google Docs, which allows collaborative editing of a single document (it’s magical when you first try it) and virtually unlimited storage space. If an agent is pressing for an exotic deal, it might be better to offer them preferential contractual terms that at least adhere to your usual, conventional royalty calculation process, than to agree to convoluted terms that will have to be handled manually at royalty time for the next 10 years. Find a non-ambiguous way to express what you mean by “Europe,” and search out solutions, such as ISO standard country, language and script codes, that work internationally so that the foreign publisher or agent with whom you are negotiating can clearly understand you. And so can the people in your marketing team.

The key to identifying and then minimizing technical debt is to ask yourself, “What if?” What if the office gets flooded? My computer gets stolen? Are we creating a problem for our future selves if we store data or communicate in this particular way, or agree to that other way of doing things? And we need to be aware of the sorts of processes and data that will need to scale, at some point. Some things don’t need to scale: human interactions, bespoke analyses, careful design. Other things, though, will inevitably have to as the company grows. Being aware of that will go a long way to helping you to future-proof your business.

Trust the experts or learn the tech? How to make decisions in publishing

2018-01-01T00:00:00+00:00

Making decisions in an information vacuum is a publishing speciality.

Every time you acquire a book, you have to weigh up any number of factors: some predictable, some entirely made up. Often it comes down to what I’ll euphemistically call “passion”: they who shout loudest, wins, because editorial decisions, no matter how analytical the approach, always come down to something of a leap of faith. (If they weren’t, every book would be a bestseller.)

But our familiarity with making such leaps for subjective decisions means we don’t get much practice at making other decisions more rigorously.

Choosing a new platform for your B2C Web site, for example. You know what it should do, and how it should look, but you don’t know which platform to choose. It’s a decision that will have far-reaching, long-lasting effects on your company. So it’s worth trying to adopt the most rigorous, least risky approach to decision-making.

The first thing to do is to ditch the hubris. No-one knows everything about everything. Accept that you are not an expert at specifying a website. Your plan should involve asking for help and accepting that your gut feeling on subjects you know little about is probably wrong. Your brief should include an information-gathering aspect, tapping in-house expertise, and also that of external contacts who can share their insight. Ask people who’ve done this all before a hundred times to help you — and then trust them, unlike the managers in this short, fly-on-the-wall comedy sketch. (I’ve been in meetings like that a horrible number of times).

Above video: The Expert, written & Directed by Lauris Beinerts, based on a short story, The Meeting, by Alexey Berezin.

One approach to information-gathering is to learn a bit about the field, yourself.

It’s like if you’re planning to go on holiday to France. You want to know enough French to get from the airport to your hotel, and to enquire about the regional cheeses. Enough to have good manners, and to show some interest in what people are saying. Same with technology. A month’s interested evening reading will get you to the able to ask sensible questions stage. If your interest is piqued, and you want to know more, there is no shortage of crash courses on programming — in fact, we run one periodically, tailored just for publishers — and the Internet is awash with information.

If you’re the person who signs the cheques, the happy side-effect is that you’ll know enough to sensibly, knowingly challenge your team to build new, interesting things that will add to your bottom line. You’ll adjust your recruitment strategy to attract technologically-competent people to your team. Your strategic planning will improve when you know what’s possible, what’s easy and what’s not. It’ll be easier for you to sign-off — or not — on your IT project implementation planning. If you don’t know anything about code, you don’t know what you don’t know, and that’s dangerous.

If you are a technical expert and need to convince the hierarchy to sign the cheque for the platform of your choice, there’s one rule: don’t use jargon. If you’re lucky enough to have a boss who will listen to and act upon your opinion, it’s incumbent on you to find a way to translate your technical understanding into what it means for the business. You’re the French fromagier in my increasingly tortured French holiday analogy. Use simple, familiar words with the plucky tourist who’s trying his best in pidgin French, and maybe you’ll be able to sell him some of your unpasteurised Camembert. (Ideally, he’ll just hold out cupped palms full of coins and notes that he doesn’t understand, and you’ll pick out the ones you want.)

If you know that WordPress is a mess under the hood, explain about the cost, time and business-risk implications of maintaining and extending horrible code, rather than trying to get your boss to care about how awful it is to have SQL embedded at the view layer, or that code should be ordered according to the MVC principle. You might be better at communicating in writing rather than face-to-face. A good boss, keen on reaching the right decision for the good of the company, will understand that and read your recommendations, rather than insist that you pitch your opinion in front of everyone.

Whether you take the blue “learning the technology” pill, or the red “trusting your experts” pill, you should always use a decision-making framework: a tool to help you take the emotion and confusion out of complex decisions.

Something like the Kepner-Trego matrix (see below) helps you to figure out what business objectives you’re trying to achieve, and which option is going to help you the most. You write down the things you must have, and the things you want. You might want to be able to integrate with your publishing management system, meet your functional spec, and to avoid buying a physical server.

Then you score your desires, giving them a weighting out of 100. Integration with your publishing management system would be very nice, so it gets a 20. Getting up and running quickly would be handy but it’s not the end of the world: it gets a 10. Costing no more than £3k is a must. Then you score your options against your desires, rejecting any which don’t achieve your musts. Multiply the scores by the weighting and you get a score for each of your options. It’s amazing how this approach helps to cut through the confusion of a complex decision to achieve clarity of thought.

Here’s an example.

To help create your Kepner-Trego matrix, you should keep asking the question, “What problem does this solve?“ For a B2C Web site decision, is your problem Amazon’s market share of your online sales? Or that there’s nowhere on the Internet for people to see all the photos from your books? Is it that your authors aren’t proud of you and won’t refer their contacts to your Web site? Or do you have no way for readers to join your mailing list? You need to articulate your problems if you’ve got a hope of finding a solution.

How much should you spend? When it comes to knowing how much money is reasonable for any technology project, you should consider the uniqueness of your requirements, and the complexity of the required functionality. The problem of selling books on a Web site is fairly complex, but it has been solved tens of thousands of times over: you shouldn’t pay someone to reinvent the wheel. Build on the shoulders of giants.

Conversely, Foyles’ recently-commissioned app, which allowed shoppers to search inside the real-life store, is a fairly simple piece of programming, but it’s unique and new. And it should cost more. Doing something for the first time costs money, not necessarily in hammering out lines of code, but in paying for the spark of invention.

When any decision needs to be made, keep asking, “What’s the problem?” until you get to the nub of things.

Make decisions knowingly. Then you’ll be sure that you’re getting a solution, not another problem.

Prizes galore

2018-01-01T00:00:00+00:00

We were completely delighted this week to be awarded the GBS Services to Independent Publishers award at the IPG 2017 awards.

Snowbooks won Trade Publisher at these awards in 2008, and now, nearly ten years later, the company which sprang from Snowbooks’ real-world challenges was recognised. It’s a particularly meaningful award, because our nomination and success depended on our customers nominating us. The IPG said:

Consonance receives this Award for the fast growing popularity of its publishing system and the help it has given many IPG members in their data management and other tasks. By streamlining and automating processes it has freed up many independents to focus on their publishing. One said: “Consonance is a game-changer for us as a small publisher—it’s transformed how we manage our titles and our metadata. It’s so easy to use and does whatever we want it to do.”

This award followed hot on the heels of me coming Highly Commended as Digital Leader at Futurebook in November.

You can hear me talking from Futurebook on the EdTech Podcast #54 (my bit starts at 48:15).

In these strange times we have felt ever-more invigorated to do our part to help change the world for the better, and so to be recognised for our achievements so far – and by our clients themselves – is really touching. We’ve got some exciting announcements about new clients and new team members coming soon, so watch this space!

Picking the right software tools for publishing

2018-01-01T00:00:00+00:00

“What you have to understand about us,” says every publisher ever, “is that we are a little bit different. We’re not like everyone else.”

I talk to a wide range of publishers about their workflow and processes, and it’s true that each publisher’s route to market is crafted to suit their particular style, culture, genre and habit. But there are, however, some overriding themes that emerge across publishing programs. And there are discrete types of tools that can be usefully applied at different points along that workflow.

The earliest part of the publishing process is also the vaguest. The sketchiest editorial ideas exist in commissioning editors’ heads and notebooks; ideas for new projects emerge in scattered conversations at conferences, in pubs, on emails. In this primordial-soup-like stage, you want to capture the idea so it’s not lost, but you don’t want to have to enter masses of data into a system about something that may be as vague as “series of books about poultry in art history.”

Systems that allow you to capture the essence without much detail are useful here—but which ideally can be added to as the idea grows and takes on a more solid form. Trello, a card-based system, is good for this, as is Pipedrive. These tools are based on the Kanban system developed by Toyota in the 1970s to help manage manufacturing processes, and are time-tested to be pragmatic and good at moving items along a process. In our commissioning process, brevity of data entry, coupled with data integrity, is a great asset.

As an idea takes shape, more data needs to be added so that the commissioning team can take the idea to the editorial decision-making stage. At this stage, we consider both the editorial and the financial arguments: the words and the numbers. In the absence of an actual publishing management system, Google Docs and Google Sheets are remarkably helpful tools here. Think of them as Microsoft Office tools that a team of twenty can edit simultaneously. Literally, simultaneously! You see your team members’ edits appearing on the page in front of you. The de-duplication of effort is a great step forward compared to emailing different versions of spreadsheets around, and it’s a great initial exercise to encourage often autonomous team-members to learn to collaborate. Your mantra here should be “one version of the truth.”

After sign-off, you’ll prepare a draft contract to begin negotiations with the author or agent. Again, an integrated publishing management system is the gold standard here, but in its absence there are some document collaboration systems which are truly superb. It’s worth checking out PandaDocs, which allows you to create documents, such as proposals and contracts, from templates, and then mail them to recipients. The best bit is that you can see not only when the recipient viewed the document, but also the percentage of time he or she spent on each page. You can digitally sign the contracts and manage the back-and-forth negotiation with elegant comments, notes and discussion threads.

Now on to manuscript development and the start of the selling-in process. At this stage, there are a lot of moving parts, but there are particular pieces of data that can dramatically affect a wide range of people. Let’s take the manuscript delivery date, or the pub date: if either of them changes, the team members affected range from goods-in and sales to third-party distribution services, your print buyer and the PR team. A beneficial tool here is Slack, a team-messaging app that integrates with any number of services. It’s trivial for any software to integrate with it, too, so there’s no reason why you can’t use it with your existing infrastructure. You can get growl-type notifications that pop up, if you like, or, if you prefer not to be interrupted throughout the day, you can review notifications in batches. So the whole team can be alerted to a slipped date without having to be emailed, or having to log on to a scheduling system.

When we get to the production stage, the process tends to become a bit more predictable. At this stage, we tend to do the same sorts of things, again and again: briefing typesetters, designers and proofreaders. First proofs, second proofs, corrections. Confirming the print quantities. Our processes tend to form a series of dependent, repetitive, ordered tasks, and Gantt chart schedules are great for managing these. I also like seeing dates in a human-friendly format, such as on a calendar. If you use systems that express dates in the iCal standard, you can see dates in Google, Outlook or other preferred calendar programs. CapsuleCRM does this quite nicely and is great for managing multiple complex projects.

Tying the whole publishing process together requires some underpinning software: systems that span the entire process of publishing. Accounting software is a good example. I use FreeAgent, and Xero is another excellent choice for 2015. Both systems have beautiful, flexible APIs, which means they integrate with tools like Float for cashflow analysis, Shopify for e-commerce, CapsuleCRM for customer relationship management—in fact, I counted over 100 integrations on a Google search. Compare that to a client-server tool where your only options are .csv files bouncing around the place: more expensive, less flexible, less beautiful, less functionally rich.

The trick to using software productively is to ensure that you use as little of it as possible to limit the complexity of your infrastructure, and that the software you do use plays nicely with its companions. The tools we’ve looked at here all benefit from beautifully-crafted APIs that allow them to be integrated with other tools. That means that you enter data in one bit of software and it magically appears in another, saving time and avoiding duplication.

Whatever tools you decide to use, make sure you pick ones whose developers have paid as much attention to how their product works alongside other software as their core offering.

Embrace the code

2018-01-01T00:00:00+00:00

When I graduated with an archaeology degree in 1996, and got a job as a management trainee for a global retail group, I had no idea that 8 years later I’d co-found an independent publishing company. And when I co-founded that independent publishing company, I had no idea that, 13 years further on, I’d find myself a professional Ruby on Rails developer.

Life is weird. And you can’t plan it out. All you can do is try to be happy, and learn as much as you can on the off-chance that it’ll come in handy. I’ve got lucky: not only do I run Snowbooks — a lovely little publisher of amazing books — but nowadays I’m CEO-programmer at Consonance, our publishing management software which we’re formally launching out of beta at the London Book Fair this year.

A decade of steadily automating away the administrative drudge of publishing has left me a proficient programmer: first in XML and XSLT and now in the tools of the web development trade: Ruby on Rails, jQuery, SQL, HTML5 and CSS3 and database management on PostgreSQL. Using these tools, with my team, I’ve built Consonance to be an enterprise management application which takes care of almost every aspect of our business. Snowbooks has relied on Consonance throughout the app’s development: at the end of 2012 we started to license its use to other publishers and organisations.

Starting to code was not a frightening step into the dark, because I took baby steps. In 2003, I opened up an ONIX file. ONIX is XML, written more or less with English words. Figuring I could use it to populate AI templates, I tinkered with manipulating the XML until that was second nature. Coding is very moreish — start down the road, take small, incremental steps. Let the years pass and before you know it, you’ve got your 10,000 hours under your belt.

You shouldn’t think that you could never learn to code. My mental arithmetic skills are worse than my 6 year old’s. I would have been laughed out of a computer science degree interview. But I love patterns, and stories, and brevity and elegance: all the things that publishers are good at. You don’t know whether you can do it unless you try.

I learned to program because I needed something like Consonance to exist so I could run Snowbooks properly. No-one else was going to write it, so I tooled up and did it myself. I had to go from a standing start, skills-wise, so it did end up taking quite a few years to progressively learn the right skills. But now I’m at the other end of the journey, it’s interesting to be able to compare life without coding skills, and life with.

And life without coding skills is awful! It’s chock-a-block full of admin. No-one goes into publishing to spend their days filling in repetitive, endless spreadsheets, surely? But unless you can manipulate data throughout your working day with little programs, you’re tied to the manual way of doing things. If you can’t code, you don’t know what you don’t know. You don’t know what’s possible. You can’t be a digital creator because you’ve got no tools at your disposal, and no understanding for collaborating with others on such projects.

Only a select few publishers employ programmers at the moment. This will change, and the change will be overnight — but it takes time to learn how to code, so start now, or the new jobs will go to outsiders. Nowadays there are some amazing, cheap ways to learn programming — because people who can code are passionate about sharing their skills with everyone else. Look at Codeschool. Come to our own course, Try Programming for Publishers. Read The Rails Tutorial by Michael Hartl — by the end of it, you’ll have written your very own version of Twitter. Imagine!

In seven years, the kids who are currently learning to code in school, as part of the national curriculum, will be graduating. People with all sorts of degrees will have coding literacy, a skill as basic to them as English and maths. You’ve got a seven-year head start on them. Start to learn code now and you won’t be skilled out of the market before you’re 40.

Originally published as a guest post on the Atwood Tate blog in April 2015

Why ‘easy’ publishing solutions hardly ever are

2018-01-01T00:00:00+00:00

Almost every week, a new technological innovation comes to market, promising to save publishers money, streamline workflow, reduce administrative burdens or reach more readers.

These innovations are diverse, but they share one thing in common: each promises to make our lives easier.

The unique selling propositions vary. Some offer easy enhancement of ebooks (CircularFlo, Beneath the Ink). Others let you conveniently mark up your manuscripts online (FutureProofs). Some offer to improve marketing (NetGalley).

Still others promise to reduce back-office administrative labor (my own Consonance). There are, additionally, tens and possibly hundreds of offerings promising to take the pain out of social media campaigns, mailing list management, editorial workflow, production and schedule management, online galley review, e-commerce, print-on-demand (POD), rights sales—you name it.

But here’s the rub: These solutions usually get developed in isolation, with little consideration for where they’ll each fit into their new customers’ existing technological ecosystems. And that’s hardly any surprise. With the myriad systems publishers use, how can a developer accommodate them all?

A prospective publishing client might have a distributor whose stock management system is an old AS400, alongside a Drupal customer-facing website, with Microsoft Navision for finance and Klopotek for metadata management.

Another publisher might have a distributor that uses an online data warehouse and a Magento website, with SAP for finance and spreadsheets for their metadata and scheduling processes.

How can a developer working on a new product or solution for either of those clients know precisely which integrations to plan for? And anyway, the developer is focused on building her new product to be amazing on its own merits. Legacy system integrations come later, right?

Wrong. Almost any new service is great, in isolation. But the real value—and the real pain—comes when it’s integrated into publishers’ own unique IT ecosystems.

Say the exciting new service that you want to incorporate into your business is for making enhanced ebooks. (There’s more than enough debate about the wisdom of that decision, but let’s take it just for the sake of argument.) It will require more content, more files, more workflow to create the new assets. And that opens up a slate of important questions: Which systems will be impacted by this new aspect of your business? Your metadata management system, your ONIX output, your editorial-production workflow, your scheduling software, your rights and permissions system and your finance system: Will they play nicely with your new toy?

What about something publishers might consider more sensible, like POD, a service that promises to radically simplify your stockholding requirements—how will that integrate with your distributor’s existing systems? How will you represent the applicable rights in your ONIX feed? What about sending the stock status to retailers? What about the additional printer scales?

If you’re not very careful, your supermarket sweep of shiny new services will turn into a major administrative overload as you try to stitch together a growing array of disparate systems. Doing so is almost always costly, and as I’ve written before, publishers must carefully weigh those investments against the returns that the new strategy they’re meant to support is likely to generate. Otherwise publishers end up becoming middle-men between two or more system providers and experiencing the worst of all worlds as a result—feeling the most pain and being the least equipped to ameliorate it.

So, in addition to listening critically to pitches for how any new service might make one isolated dimension of your publishing business easier, here’s what you need to ask of developers:

What is your track record for adapting to changes in the supply chain? Which systems do you integrate with? What was your process for determining the data formats accepted by the other systems yours is built to work with? Do you accommodate two-way data transfers? Could I see your API documentation please? In previous projects, who changed their code to accommodate the integration—you or them?

Developers and their fancy boxes of tricks often promise to make publishers’ lives easier, and of course their solutions can indeed turn out to do just that. But before things get easy, publishers have to confront the hard part first, and determine how well any new addition will integrate with all their other labor-saving systems.

http://www.digitalbookworld.com/2015/why-easy-publishing-solutions-hardly-ever-are/#sthash.Jy12py5U.dpuf

Is your strategy setting you up for disappointment?

2018-01-01T00:00:00+00:00

Skills development, well-thought-through workflows, decent transactional websites, careful integrations of software using APIs, and thoughtful planning are all valuable strategies. And if you adopt a considered, strategic approach to building a publisher, you increase the likelihood that your company will still be around, relevant and thriving next year, in five years and in 10 years time. But even if you have the most efficient implementation of the right technology—even if you have the best, most elegant, most thought-through strategic plans—it still doesn’t mean that everything’s going to be OK.

There are two looming dangers you have to deal with. First, your strategic, infrastructural brilliance won’t matter one bit if your staff’s, suppliers’ and customers’ actions don’t support your plans, and second, the money spent on infrastructural changes may not be recouped for years, if at all—making your projects seem like failures, and potentially stifling any future plans to innovate and improve.

Let’s take the support you need first. Your own staff, your suppliers (authors, printers, salespeople) and even your customers may be well-intentioned, but they can sometimes hinder rather than help.

For starters, staff can be unproductive for any number of reasons—perhaps they enter the wrong data into your shiny new metadata system, or keep doing things the old way after a process review because it’s easier in the short term. No computer system can rescue you from a broken company.

Suppliers can also let you down. Printers and distributors, experimenting themselves with POD and new ways of managing the supply chain, can trip up, affecting your ability to meet your own goals. And authors can often expect the impossible, or simply be misaligned with your approach.

Finally, customers can just plain old not buy your books. This is, to be honest, more of a point about product-market fit than managing your customers, but it’s true to say that you can’t rely on readers doing what they said (or at least, what you thought they said) they’d do. And you certainly can’t rely on retailers buying your books just because they’re excellent and beautiful—because most books are excellent and beautiful to one degree or another, and bookstore shelves aren’t infinite.

The best approach I’ve come up with to mitigate these effects on your business is to try to manage people’s expectations up front.

Take staffing, for example: if I’m hiring for a role where attention to detail is paramount, I’ll test candidates on these skills before I hire them. And I’ll set up KPIs so that staff are measured on goals designed to support the company’s wider plans. Everyone’s happier when people fit their job naturally and know what’s expected of them.

What about customers? To help manage customers’ expectations, we have to help them understand our books before they buy them. I’ve been guilty of designing covers that were intended primarily to sell the book to the retailer, rather than communicate the story to the reader. It’s kept me in business to date, admittedly, but it conflicts with a desire to help readers choose their next book. Because of this, subscriptions and crowdfunding are exciting new areas to dabble in. They make us explain a lot more up front about our books before they’re produced, and customers can put their money where their mouth is, giving publishers a lot more evidence about demand in good time.

How to make authors happy, though? Authors come in two flavors: those who need to make money from their writing, and those who have a different job that pays the rent. The requirements of each group are wildly different, and it pays for them to explicitly articulate what their expectations are—financial or otherwise—so you can provide a forecast. Before we sign a contract, I explain how we work and give prospective authors a realistic royalty forecast up front. To that end, if you think the nature of the market means they’re only going to make $100 in the first five years, tell them. It may lose you the deal—they may go elsewhere—but I think it’s preferable to be realistic and under-promise than suffer the ire of authors who think you’ve let them down.

Managing people’s expectations can certainly protect against problems that your infrastructure might come up against, but we’re far from done yet.

What’s this about not making money on your infrastructure investments? If you thought that spending $10,000 on a brand new website would quadruple your online sales, you may be in for disappointment. Same goes if you think that spending time and money on a new royalties, production or metadata system is going to immediately increase your profit. Sure, these things are necessary as baseline requirements for a competent operation, but they’re not going to positively transform your fortunes overnight. So enter into these projects with your eyes open on their likely return. Spend thriftily on them and plan for the fact that infrastructural projects, certainly in the short term, are about eliminating costs rather than increasing revenues. Manage your own expectations.

Decent planning, decent tools and decent workflow can remove the overwhelming drudge of publishing operations. But make sure the people you work with support your plans. Managing expectations—your own, and those of others—is the crucial cherry on the cake of a successful strategic plan.

Futurebook manifesto for skills

2018-01-01T00:00:00+00:00

This appeared in Futurebook and was also delivered at the Futurebook conference

Whatever the other Manifestos for the Future of the Book Business are — whatever exciting areas people propose for change in the industry, whether it’s in digital, or business workflows or product development — our people do not have the skills to make it happen.

I was amazed at the response to the Futurebook piece Menial publishing jobs are destroying our future, which questioned:

Why, as an industry, we still get humans to do the work of computers
Why we keep entry-level positions secretarial, and
Why we don’t provide the right sort of training to equip our people for the future.

I thought it’d be accused of hyperbole. Instead, the response was quite the opposite.

People sent sackfuls of public and private messages of fervent agreement and thanks for writing about the problem.

It seems that there’s a groundswell of discontent throughout the junior ranks, horrified at what is evident to any impartial observer: we don’t train our people and we don’t expect them to be formally skilled.

So here’s what we should do about it.

Educate senior management about what code can do

If senior management were technical—if they knew what computers can do—they wouldn’t stand for the gross waste of time and creativity in their companies.

So let’s launch a series of non-technical yet software-specific, capability-focussed seminars for senior managers. A simple example: show senior managers 20 people editing one Google spreadsheet at the same time. It’s free, accessible, requires no extra training, no servers, and it removes the costs, errors and embarrassment that stems from having more than one version of the truth. Trello, Pandadocs, Capsule, Google Drive, Dropbox, Pipedrive, Slack, FogBugz— many cloud-based apps are cheap and solve some entrenched publishing problems.

Recognise that technical skills take time to develop

Publishing is not a sector used to taking the long view. If you’re designing a new jet engine, you know it’s going to take a decade before your investment of time and effort pays off. Publishers should recognise that an investment in providing staff with technical skills training will not pay off this quarter, or the next.

In five years time, you’ll have the right workforce for the market, and they’ll be motivated, grateful and hyper-productive.

Develop an industry Management Training Scheme

Make it competitive, difficult and ambitious.

Have it run over three years. Provide a formal qualification at the end. Have its syllabus include financial management, project management, management skills such as influencing, negotiation, and decision making, and code. Get employers to subsidise attendance and allow delegates to attend week-long sessions, four times a year.

Radically raise our expectations of our suppliers

Suppliers to publishing are divided cleanly into two groups: those who know what an API is, and those who don’t.

We must insist that our suppliers move beyond the 1980s, as a matter of urgency—because if they haven’t, it’s costing us time and money. We simply cannot accept the fact that major businesses still build data workflows centred around the .csv format and exchange of spreadsheets, or that professional typesetters can’t automate catalogue production from ONIX in InDesign. We cannot tolerate the inflated costs of external experts who are fleecing us because we don’t know how to build things ourselves.

Most of all, we can’t tolerate that our industry does not have the competence to recognise this.

Update our Occupational Standards

Revise the otherwise excellent Book and Journal Publishing National Occupational Standards to include technical skills. They don’t go far enough in ensuring a technically skilled workforce.

Harness the evident discontent amongst junior publishers

People are angry about having to prove themselves in menial roles.

Let’s harness the power of this sentiment and give people a platform on which to discuss change, without fear of retribution by their management. A StackExchange site for publishing? Meet-ups, like we do in tech?

There’s a groundswell of opinion on this and we should find ways to raise our voices coherently.

Make us competent, make us proud, make us flourish

I want to work in a flourishing industry known for its competence, kindness, innovation and creativity. As time goes on, our current expectations of what junior roles should be is going to look and feel more and more Stone Age—with radical implications for our future viability.

Originally written for and published by The Futurebook, October 2015

Why incremental ONIX changes are best, and hard

2018-01-01T00:00:00+00:00

When first discussing an ONIX feed with a potential recipient, amid all of the minutiae of their preferences is one key question: Incremental?

Even in an email there’s a certain tone about it – the tone of an organisation that thought it would be fine to get complete catalogue feeds from small publishers ten years ago, and is now up to their midriffs in files and data, and please can you let us know only when something has actually changed? Thanks!

The Problem

It’s a pretty serious situation to be in, when you are receiving 8,000 product records from a trading partner. ONIX is an XML standard, and XML processing is not entirely low cost. With modern processor power and efficient software libraries you wouldn’t really notice the processing of a single ONIX record, but combine the reading of the data from hundreds of files with a comparison against the data you have stored for those products to see if they need updating and you can be into some serious processing time. And the thing about time is that there is only so much of it in a day. Having once worked for a company whose main product took around twenty-four hours to process a daily file, I can tell you that that situation is absolutely paralysing.

Fun fact: this company had no ability to restore their database from backups, because switching it to a mode that would allow consistent backups to be taken potentially threatened the processing window. I say potentially because they had no way of testing whether it would or wouldn’t without trying it, and they couldn’t afford the time to do so. They still actually took backups, even though they could never be used, presumably because cognitive dissonance wouldn’t let them stop, even though the act of taking a backup that could never be used added time on to their daily processing. It’s OK – I’m happier now.

But change detection is hard. Consonance is written in Ruby On Rails, and therefore by default we have create and update timestamps on every product record, every price record, every work, marketing text, cover image, imprint, contributor, sales agent, supplier, etc., along with audit trails that tell us exactly what was changed and when by whom. In some parallel universe there definitely exists a civilisation that can use that data to tell you whether an ONIX record has changed since a particular historical point in time, possibly using seven-dimensional quantum blockchains.

But this is what many people’s first plan is when approaching such a problem. Got a timestamp? is the give-away question, but let’s consider why that approach fails for any but the most trivial situation.

What was the change?

Firstly, it is not enough to know that a row of data was last changed two days ago, in order to know whether the data has changed since you last sent it a week ago, because this clearly doesn’t tell you whether it also changed fifteen seconds prior to that last change, and therefore whether the latest change was to correct a mistake previously made. A price changed from $10.00 to $101.00 and then back to $10.00 is no change at all, but your timestamps don’t know.

That in itself means that you can’t use timestamps alone, but if you have access to data change logs then maybe you can detect whether the data actually changed. We use an open source Ruby library that allows us to say what was the data like for this record as-of one week ago?. Not only can we tell if there were any actual data changes, we can tell exactly which items of data changed.

That still doesn’t quite get us to a solution, for two further reasons.

Do we care about that change?

As I wrote in a previous article, every ONIX recipient has an à la carte requirement, and a change in the main Thema code for a work may not affect the ONIX to be sent to a particular recipient. While it’s arguable that ignoring those some of these differences doesn’t do much harm to recipients in general – they’re only receiving a bit of extra data, after all – my feeling is that it would tend to do harm to particular recipients disproportionately. And those would be the recipients who should be the least trouble, who don’t actually need much detailed metadata (rights management agencies, for example).

So as a point of principle, I feel that we should care about these changes.

Sara O'Connor to join the team!

2018-01-01T00:00:00+00:00

Huge news from us today on day 2 of the London Book Fair 2017. Here’s the full press release! Thanks to The Bookseller for covering it.

Consonance, the publishing system started by Emma Barnes in 2011, has hired publisher-turned-programmer Sara O'Connor. O’Connor will join the tech startup in early April.

O'Connor was previously Editorial and Digital Director at Hot Key Books but, partly inspired by self-taught programmer Barnes, retrained at the coding boot camp Makers Academy. She was soon hired into a developer role at trade promotion management software company Exceedra. Eighteen months on, she returns to publishing to join the impressive Consonance team, including fellow Bookseller Rising Star Emily Labram.

Consonance is a growing tech company. It recently won the IPG GBS Award for Services to Independent Publishers and its CEO Emma Barnes was highly commended as the latest Futurebook Digital Leader. Its growing roster of over 30 clients includes the Institute of Physics, Pharmaceutical Press, Canelo, Unbound, Zed Books and Liverpool University Press.

Sara O'Connor says:

I’ve always been obsessed with - and keen to improve - the software and processes that the publishing industry uses to make a book a success. Joining the talented team at Consonance as a developer is a dream come true. Now, I can spend my days helping to make the technology of publishing better, to get more books more easily into the hands of readers.

Emma Barnes says:

We couldn’t be more delighted to have lured a talent of Sara’s standing to Consonance. I am particularly proud that her arrival means we will have more women than men on the team, which stands in stark opposition to most tech companies. Sara shares our mission of liberating publishers to do the work that matters — a mission which is needed more than ever in these times of political strife. And as Sara knows both publishing and programming, the whole team is very excited to see what new heights her expertise helps us to reach.

O'Connor will also be helping Consonance in their mission to skill up the publishing industry. She will train publishers to code in April at the next of Consonance’s oversubscribed programming workshops for publishers, in partnership with Bookmachine, for which all profits will go to charity.

Barnes said:

It’s clear from the length of the waiting lists and the speed with which they sell out [the latest course sold out within 24 hours] for our courses that there’s a burning desire among publishers - especially women: marketers, editors, salespeople - to learn these vital skills. And there’s increasing recognition from the top down of the need for publishers to innovate in ways that really meet the needs of their customers and authors - and that it’s possible to empower their own staff to take on these skills. Programming, design, product management and user experience skills can powerfully enhance an editorial or marketing skillset, and reduce the risk and cost of hiring expensive agencies. We are excited and hopeful to see plenty more people who might not have considered themselves to be ‘technical’ follow Sara’s lead.

How to create a catalogue automatically using ONIX and InDesign

2018-01-01T00:00:00+00:00

Did you go into publishing so that you could spend your days copying and pasting ever-changing metadata from spreadsheets, emails and databases into InDesign? You did? No need to read on.

If you didn’t, perhaps this article will interest you. In it I’m going to show you how to create a catalogue in a single click.

This isn’t a sales pitch. You don’t need to scan ahead for the paragraph where it says “and all you need to do is buy our MagicSoftware™ for twenty grand a year”. All the tools you’ll need are very likely to be there on your work computer. I’m assuming, you being a publisher, that you have a copy of InDesign, and that you can get an ONIX file of your data. (If you don’t have an ONIX file then, actually, this is a sales pitch. Producing an ONIX file of your book data is a basic publishing necessity: call me.)

Here’s what we’re going to cover in this article. First, I’ll prepare an InDesign template. Then I’ll get the data arranged into a suitable format for the InDesign template to understand. Finally, I’ll import the data into the template and revel in the catalogue I’ve created in a single click.

The most exciting bit about this is that you only have to do things once. You set up the InDesign template once, with one sample book entry. You write the XML transformation code once. Then, when you import the data, the single-book template replicates itself to create as many catalogue entries as there are book records in your data — potentially thousands and thousands of catalogue entries with a single click. And of course you can reuse your template and code for the next season’s catalogue, and the next.

Before we start it’s probably a good idea to read this article about XML and ONIX.

ONIX is a wonderful way of sending rich book data to the companies who need it – Nielsen, Bowker and the like. But ONIX’s comprehensive nature means that it can be quite verbose. In a catalogue, we don’t need every last bit of information about a book. So I’m going to convert the ONIX XML message into another XML file that’s a bit less wordy, using a language called XSLT. Then I’ll be able to import it into InDesign. (In fact, InDesign can handle the conversion process itself, when I import the XML.)

Download the files here. You’ll see I’ve prepared an InDesign template. Here’s the structure pane of the InDesign template, showing how each entry will be structured: I’m going to need to whittle my ONIX down until I’ve got an XML file that matches this structure.

So I’ll prepare my data for it, using an XSL transformation. Open the transform.xsl file in a text editor such as Atom: this is what the transform.xsl file contains.

Keep calm! Whilst this is code, and it might look a bit overwhelming at first glance, it’s not all zeroes and ones. It’s readable, because it uses English words.

So, one line at a time, I’ll read this code. (This, by the way, is the very first code I ever wrote, in 2006.)

Line 1 tells the computer that this is an XML file.

Line 2 adds the first tag, called

1
  <BK>

and gives a bit more information about this part of the file – which is that this code is XSL.

Line 3 is where it starts to get interesting.

1
  <xsl:for-each select="ONIXMessage/Product">

means “find each mention of ONIXMessage/Product in the ONIX file.”

The next bit adds a new XML tag, called

1
  <Book>

If you peek ahead to line 24, you’ll see its sister, the closing tag

1
  </Book>

(We know it’s a closing tag because of the backslash.)

Lines 5 to 7 set up some variables. A variable is like having a shortcut. For example, I can define a variable called “address”:

1
  address = “Chiltern House, Thame Road, Haddenham, Aylesbury, Buckinghamshire HP17 8BY, UK”

Now, next time I want to give my office location, I don’t have to spell out the whole thing. The variable “address” is a shorthand way of saying the whole thing.

Back to my code. I’m going to define three variables on the next lines: one called form, one called date and the other called isbn, so I can use them later. I’m getting the values of the variables from the ONIX file. I select the data tagged up with ProductFormDetail and assign it to the variable called form.

Similarly, I find the value in the ONIX tagged up as PublicationDate, and save that as the variable date.

Lastly I find the bit in the ONIX tagged up as ProductIdentifier[ProductIDType='03']/IDValue and set that as the variable called isbn. That last one is a bit complicated but if I show you the ONIX, it’ll make more sense.

1
2
3
4
5
6
7
8
    <ProductIdentifier>
      <ProductIDType>03</ProductIDType>
      <IDValue>9780954575984</IDValue>
    </ProductIdentifier>
    <ProductIdentifier>
      <ProductIDType>02</ProductIDType>
      <IDValue>0954575984</IDValue>
    </ProductIdentifier>

There’s two ProductIdentifier tags here. Which IDValue do I want to select? The one where the ProductIDType is 03. (A lot of learning programming is about getting familiar with the syntax – the particular way that the programming language is laid out. Here, I’m using square brackets to nest ProductIDType after ProductIdentifier. Don’t fret about learning syntax. Understanding the actual logic is the thing to really get a handle on. It’s why kids’ learn-to-code tools such as Scratch are so great – they teach the principles and the logic, not one language’s particular way of writing them.)

Line 8 defines another XML tag, called <image>. Because it’s an image tag, it takes an href attribute. And can you see how I say where the computer should look for the right file? That’s right – I use my freshly-minted “isbn” variable. So this URL:

1
  <image href="file:///{$isbn}.jpg" />

will become:

1
  <image href="file:///9780954575984.jpg" />

The next line is quite fruity, but I’ve included it so I can show how malleable data can be in the hands of a computer. The line defines a new XML tag, <year>. I’m using a new XLS command:

1
  <xsl:value-of>

Line 9 says “Get the value of the ‘date’ variable”. It also fiddles around with the date quite a lot. If the line read

1
  <xsl:value-of select="$date"/>

then the new <year> XML tag would read <year>20120228</year>. But who wants to use ISO-format dates in a catalogue? Instead I want it to read <year>28/02/2012</year>. So whilst concat(substring($dt,7,2), ‘/’,substring($dt,5,2), ‘/’,substring($dt,1,4)) looks fairly unholy at a glance, what it’s doing is saying

“Concatenate the following:
Get the value of the date variable which is 20120228.
Count to the 7th digit, which is 2.
Then get the 2 following digits, which would be 28.
Then put a backslash in.
Next, use that same date variable and get the fifth number, which is 2, and then the next two digits, which gives you 02.
Put another backslash in.
Finally, get that same date variable, and get the first number, which is 2, and then the next four digits, which gives you 2012.
All of that gives me 28/02/2012.”

See, it looks awful to start with, but you have to sit and read the code until it makes sense.

The next line, line 10, is also an <xsl:value-of>, and I reuse my handy isbn variable again (which is one of the points of using a variable). This line produces another XML tag called <productid>.

All these tags will be used in the InDesign document I’ll show you in a bit.

I’m going to use one more XSL command, which is

1
  <xsl:choose>

On line 11, I add another XML tag, called <format>. But what to put in this tag? The xsl:choose syntax means “Choose from the following: when the ONIX form variable is B104, put in A Format Paperback. When the ONIX form variable is B105, put “B Format Paperback” in the new <format> tag.” And so on.

The next bit is best shown on video. Watch how I’m going to use XSLT code to transform ONIX into a more concise XML file and automatically flow it into an InDesign template. (You’d best watch it on HD so you can see the detail.)

Use the files you’ve downloaded to practice, and then use your own company’s ONIX file and have a go. Then, tweak the InDesign template so that the colours and fonts are to your taste, and produce your own catalogue.

This demo is a deliberately pared-down example. You’ll likely want to include more information such as the title, the blurb and the price. I can recommend A Designer’s Guide to InDesign and XML even though it’s out of print which contains even more templates and excellent descriptions of how to start using InDesign properly and productively.

You know, I could have automated this catalogue’s production in a number of ways. If you use Consonance, you can export pared-down XML without having to convert ONIX, or you can export data directly to PDF. If you still store your metadata in Excel (shudder) you can nevertheless get it to export an XML file. The point is that if you explore the tools you have available to you right now on your machine, you’ll find that your computer could be working a lot harder for you. Automation is the key to a happy, cost-effective modern working life – and when your happiness and financial stability is at stake, that’s worth a bit of an investment of time in learning about automation processes like this, wouldn’t you say.

Originally published on Bookmachine, February 2015. This version includes additional edits and changing from the second to first person, which reads a bit letter.

You don't need special software to store data properly

2018-01-01T00:00:00+00:00

The way I drive, sometimes, you wouldn’t think I believe in mechanical sympathy. But I can assure you I do. Mechanical sympathy is the ability to have an awareness of and empathy for how a machine works, as well as the capacity to adjust your engagement with that machine to help it perform optimally.

If you have some mechanical sympathy for data and spreadsheets, you’ll likely get a lot more mileage out of them than if you expect to be able to squirt any old nonsense into them.

Take rights data, for instance. The Frankfurt Book Fair, and the other book fairs throughout the calendar, are occasions when the technical debt of rights teams around the world comes back to bite them. Gathering together current and accurate information about which rights you hold, which have been exercised, which expire when, which frontlist titles’ rights are contracted and so on, can be a mammoth task and can weeks of preparation.

Would it upset you to know that I produce my rights guide the night before Frankfurt, by clicking a single button? There are a number of steps to get to this happy state of having unambiguous rights information in one place, synchronized with editorial’s and legal’s data, and you don’t need one particular system to do it. But you do need mechanical empathy and a rigorous business workflow in place to enforce it.

The key is to store data in a way that computers can understand. If you do this, it means that you can query your data programmatically, and that computers will be able to ingest it properly. That gives you a lot of flexibility around which system you use to manage your data, now and in the future. And if computers can understand it, it’s actually more likely that humans can understand it, too. Computers hate ambiguity.

Take these two examples of how to store data. Which do you think can easily be imported into a database, an InDesign template or a new publishing system?

The first spreadsheet has no end of technical debt being stored up:

No validation of the title. There’s nothing to stop someone typing in numerous variations of the same data: “Brave New World,” “Brave new world,” “ Brave New World” with a leading space. Use filtered dropdowns to ensure there’s only one valid version of each title. Relational database management systems do this through associations between tables; you can do it in a spreadsheet by setting up list validations.
More than one sort of data in a cell. By putting “France” and “Spain” in the same cell, it’s hard to associate other data properly—which is why the next column has to go on two rows.
Imprecise categorisations. When we say “Rights sold,” do we mean the language, the script, the territory or what? France is a territory, German is a language, Simplified Chinese is a combination of a language and a script.
Conflicting types of data in the same column. The Advance column mixes up currency amounts, descriptions of payment terms and payment statuses. How could a computer figure out what the advance amount was, the currency, or the payment date, from the string “Paid?”
Inconsistent ways of formatting data. The last column presents date information three different ways.
Multiple possible values for one piece of data. If you’re going to have one line per rights sale of a title, you might be tempted to have a column showing which rights you own. But that would mean putting, say, “World” on multiple lines. If one of those lines says “Commonwealth” and the rest say “World,” which one are you going to use as the right answer?

Using colour-coding, indentations and font sizes in spreadsheets to communicate categorisations of data are more ways that make it very difficult for a computer to figure out what’s true. The reality, however, is that, while you might feel that this is “your” spreadsheet, it’s really not. The data belongs to your company, and you are obliged to store it in such a way that other people and other systems can understand it.

Store your data properly, and you’ll be able to get the most out of whatever systems you want to use. Then you can spend your time preparing for the substance of meetings at the book fairs instead of burning the midnight oil hand-writing a rights guide that’ll be out of date before you’ve even finished.

Publishers can learn a few things from programmers

2018-01-01T00:00:00+00:00

As both a publisher and a programmer, I’m a member of a very select club. I’ve been struck by many similarities between the worlds of code and publishing. And I believe that being able to identify and act upon them has made me a better publisher.

I wrote this article about programming for DBW in February 2015. Read the full article at Digital Book World.

As both a publisher and a programmer, I’m a member of a very select club.

It consists of both those who started out as coders and went into publishing and those who did the reverse. I’m in the latter group, having co-founded a little indie press called Snowbooks in 2003. When I needed a system to run the company and found the software on the market both hugely expensive and horrible to use, I buckled down and learned to code. The result was my own back-office publishing management software, called Consonance (which, delightfully, lots of publishers now use).

Admittedly, it took about a decade. But along the way, though, I’ve been struck by many similarities between the worlds of code and publishing. And I believe that being able to identify and act upon them has made me a better publisher.

Coding has a fairly long learning curve. With about 10,000 hours under my belt, I’d put now myself at the ‘adequately competent’ stage on a spectrum of capability that starts at ‘complete novice.’ The other main developer of Consonance—a chap with more than twenty-five years’ experience at Oracle—is right up at the ‘super-productive expert’ level at the top. From where I am at the moment, though, I’m good enough to see the beauty in code, just as I can see the beauty in any writing.

You may never have written code, but you’ve read books. I bet you’ve appreciated the clarity that comes from brevity, or the careful crafting of a narrative flow, or the finely-edited end-result of a piece of prose, honed and whittled and buffed to perfection. So it is with code.

Writing—whether code or prose—is a craft, an art. Code, perhaps even more so than prose, is an expression of the author’s personality and philosophy. Some publishers turn their hands to novel writing. I don’t have a novel in me, but I did have a two-hundred-thousand-line Ruby on Rails application, it turns out.

Some code, to me at least, even reads quite literally like poetry. Here’s a Ruby method:

def self.highpriceband

where price > 10

end

=> Book.highpriceband

Read it out loud and it’s almost a haiku:

def self, dot high price band,

where price is greater than ten

end; call Book dot high price band.

If there are similarities in writing—whether it’s code, prose, scholarship or even poetry—there are also comparisons to be drawn in how we get it ready for publication or deployment.

Some code can be dashed out, fit to prove a point or get to the Minimum Viable Product stage. I look with some cynicism upon weekend-long hackathons, knowing from experience how much reflection, effort, testing, iteration and planning is needed to produce a really strong, dependable piece of code. In the same way, we have bursts of hurried activity in publishing: We’ll wallop out a series to fit with something newsworthy, or with a new course, or some other time-based tie-in.

But the best publishing comes from a strategy—from well-thought-out, well-planned, purposeful publishing. From bringing forth books because we know there’s a market for them. From publishing into a space we understand, and by using our in-depth knowledge of genres and insights from audience research to reach our readers on their own terms.

In fact, that’s one area where some programmers could learn from publishers. More apps and start-ups would succeed if they came from a real understanding of the market, rather than because the programmer thought the code would be interesting and fun to work on. That said, many programmers seem to be great at understanding why they’re doing something and continuously asking whether it’s a good way of doing things.

I like what coding has done to my brain. After thousands of hours of forcing it to do new things, I can more skillfully break down a problem into its parts, work through each part one by one and build or rebuild a solution. Mental agility is something you have to work hard at, and that’s true as well for organizations struggling to innovate and iterate quickly without falling to pieces. Coding is great for this.

Programmers, I would say, are more naturally inclined toward long-term productivity than publishers. We’re lazy and tend to get bored easily. We would rather spend a week writing some code to automate a ten-minute task than repeat it every week for a year. And so programmers have some conventions: DRY—don’t repeat yourself—is a good one; YAGNI—you ain’t gonna need it—helps you to figure out which code should be written and which is optional.

Convention over configuration—a way of getting the basics organized and routine so you can focus on the interesting, creative, new aspects of things. If publishers had zero tolerance for repetition and boring administrative tasks, what would the industry look like? And how would publishers’ organizations reflect that internally?

Having admired convention, there’s nothing to stop individual coders going right against convention and doing something totally different. The Linux operating system, the programming language Ruby, the web development framework Rails all came about because one person decided there was a better way to do something.

There’s an all-pervading attitude of continual improvement in programming. Take a look at Github, the code repository used by most programmers to save every iteration of their work. Repositories have thousands of incremental changes and edits. Programmers naturally hone and whittle and constantly improve. They automate the dull stuff so they can think about the bigger picture.

Yet within both sectors, there’s an attitude that prizes craftsmanship and best practices, proving these impulses—to innovate boldly and to hold small, familiar things precious—can be powerfully complementary, not mutually exclusive.

Since code is also the thing that generates what users know as software, we can think of code as a metaphor for the way we go about producing our books. The way it typically works today, programmers write the code, which then runs to produce a user interface, like a website, generated from HTML behind the scenes. In one, you can have horrible, clunky code producing a fairly decent-looking user interface, to an extent—but push it too much and it’ll slow down and generate errors, and it won’t scale well.

On the other hand, lovely, elegant, thoughtful code produces solid, dependable, beautiful software. With publishing, I think that you can get out what customers experience as a serviceable book (print or digital), where the content is great and the production value high, yet if the process of getting that book out was horrible and confused—if it was all swan on the surface but frantic paddling going on underneath—then that’s not scalable or sustainable, and there are bigger problems that need addressing. You should take as much pride in the way you produce books as the books themselves.

All the value and characteristics I’ve discussed—clear thinking, automation, productivity, continual improvement and craftsmanship—are baked into programming’s core. But these aren’t just skills we can extract and apply to our own world. The best way to develop these attributes—if they sound like things you indeed want to value—is to practice code. Become a developer. Face the intricacies, the struggles, the delicious, aggravating complexities that code, like nothing else, provides.

When you know what you can do with code—when you know what’s possible, when it’s obvious that you should automate something or integrate with another system or write a new protocol for describing an interesting way to reach readers—even (and especially!) if you need to ask more practiced programmers for help—you’ll have the strengths of programming on your side.

How APIs can make publishing more efficient

2018-01-01T00:00:00+00:00

As a rule, application programming interfaces, or APIs, aren’t easy to talk about.

For instance, you can’t have a debate about whether or not APIs are a good idea. That would be like arguing over whether the Internet is a good idea.

Instead, it’s easier to talk about what a modern API actually is. We in the publishing world need to get in the habit of having that conversation more regularly, since APIs are already helping plenty of publishers improve data integrity and become more efficient, and they could mean a great deal more for the future of the book trade.

To that end, a quick primer: Not so long ago, getting web services (websites, in common parlance) to talk to one another was a fairly tricky ordeal. The main protocol, called SOAP, established a way of passing XML over HTTP, but it was complex and difficult to implement and was liable to break if anything on either side of the data exchange changed. Nowadays, any web service worth its salt exposes some of its data using a RESTful API. (REST is the architectural style upon which the web itself is built.)

Modern, RESTful APIs tend to send data in what’s known as the JSON format, which is a lovely thing. JSON data is laid out in a structured way that both humans and computers can read. This is how I’d display my own and my colleague’s names:

1
2
3
4
5
6
7
8
  our_names = '[{"firstname": "Emma",
                "lastname" : "Barnes"},
               {"firstname": "David",
                "lastname" :"Aldridge"},
               {"firstname": "Rob",
                "lastname" :"Jones"
               }]'

Curly braces and square brackets keep the data in a structured order. If I want to get at the data, I can do something like this:

Use the Ruby JSON gem to parse data in the JSON format

1
  json = JSON.parse(our_names)

Get the first person’s firstname. Ruby counts from 0, not 1!

1
2
  json[0]["firstname"]
  => "Emma"

Get the second person’s firstname

1
2
  json[1][firstname]
=> David

Get each bit of the JSON data…

1
  json.each do |person|

… and print the firstname and last name, with a space in the middle.

1
2
  puts person['firstname'] + ' ' + person['lastname']
=> Emma Barnes, David Aldridge, Rob Jones

Modern web services make data available in that JSON format, at a perfectly ordinary web URL. And if you know some rudimentary programming, it’s straightforward to go to that URL, authenticate with your username and password and read the data. If the application’s API allows it, you can also send data. In practical terms, that means that even novice programmers can get computers to share information.

This has terrific, and by now well-known, implications for digital publishers. Take our metadata web app, Consonance, which sends its data to the e-commerce platform Shopify via an API. In the same vein, publishers can write their own web apps and get them to ask Consonance for up-to-date metadata to populate them.

There are quite a few well-known APIs already in existence and freely available for use by the book trade. Consonance grabs book reviews and ratings from Goodreads’s API. It collects and stores tweets that include authors’ names and book titles from Twitter. It harvests book information and review ratings from Google Books’s API. It also grabs the current data from Amazon’s API for all of a publisher’s titles and compares them to the data held in Consonance, flagging any mismatches.

Can you imagine the time-saving potential of that automatic checking service, the improved quality of data provision—and the knock-on effect of being able to sell more books as a result? These are just a few of the immediate benefits APIs can bring to a digital publishing business.

And as we look ahead to an industry increasingly driven by web services, it’s easy to see that the overarching issue becomes figuring out how these services integrate with each other.

Using a web service to store your metadata is one thing; getting it to populate your e-commerce website and rights platform, grab sales data and send orders directly to printers, partners and other platforms is quite another.

As I wandered around the London Book Fair’s tech area this week, I saw no end of interesting web applications, all of which could provide value to publishers. But the really useful ones will be those that play nicely with the other services you use. The content management system Librios, the content solution IDM, the semantic publishing platform Ontotext, the social DRM service BooXtream, the Edelweiss platform and of course Consonance all have APIs—which means they can be configured to work as part of an ecosystem, with data being transferred programmatically between them to allow publishers to get the most out of their investments without adding administrative overhead.

From a publishers’ point of view, any efficiency gains from new web services are lost by repetitive web processes. If you have to type book data manually into your ebook platform, and then into your metadata system, and then into a rights marketplace, and then into retailer web forms and so on, it’s no better than the bad old days. APIs let us enter data in just once and get the computers to do the boring bit of sharing it around. And then things start look a lot more productive.

So when you’re considering your options from the plethora of web services coming to market, ask web service developers to show you their well-documented APIs as well as the functionality of their products. You’ll be headed toward a more strategically sound, better integrated investment.

(I originally wrote this article about APIs for DBW in February 2015.)

What publishers need to know about Ruby on Rails

2018-01-01T00:00:00+00:00

Since so much of the publishing ecosystem is becoming more and more web-based every day, it helps even those who aren’t strictly on the tech side to understand the fundamentals about how Rails works.

Ruby on Rails—or just “Rails” for short—is my web development framework of choice.

If your job has anything to do with the Internet—which if you’re reading this it does—then you’ve likely used a Rails application already today. Groupon, Airbnb, Shopify, Bloomberg, Indiegogo and hundreds of thousands of other websites are all written in Rails.

As a mature framework, Rails has a thriving open-source ecosystem of developers, so if someone’s pitching a new web product to you, for instance, there’s a good chance they’ll be pitching a Rails app.

Simple websites whose data rarely change don’t need sophisticated frameworks like Rails. You can just write plain old HTML in a text file and upload it to your web server. If, however, you’ve got an interactive website where the data change a lot, or there’s a lot of data to start with—and these days there is—then a static HTML page won’t work. You’ll need a database to store the data in, a way of accepting inputs from users and the ability to display different data depending on what the user types and clicks.

Enter Rails: a set of conventions, written in the Ruby programming language, that makes writing complicated websites less complicated.

A Rails app is a set of files in folders, just like you’d see in Finder on Macs or Explorer on PCs. Rails apps are all organized the same way—into folders called models, controllers and views. What follows is a quick, guided tour through each one, plus a zoomed-out look at what publishers should understand about the broader system as they continue to develop their web presences.

Models

Model files are the engine rooms of a Rails app. They are where the objects of the application are defined and where business logic is stored.

Methods

Say you’ve got an online bookshop, and you want to display all your ebooks, rather than print books, on a single page. You’d write some logic in the model that would let the bookshop determine what an ebook is. In pseudocode:

The definition of “Ebooks” is: Books where the product_form is Digital

As a matter of fact, the real code is simpler. Want to see it?

1
2
3
  def self.ebooks
     where(:product_form => "Digital")
  end

(This code is in a file called “models/book.rb”)

Associations

Models are also where we establish the relationships among the objects that appear in the app. If you had a Book model, it can be related to a Price model like this:

1
  has_many :prices

(This code is in a file called “models/book.rb”)

1
  belongs_to :book

(This code is in a file called “models/price.rb”)

So a book can have many prices, and a price belongs to a book.

Models talk to the database. When the data are all nicely stored in the right place, all of it becomes easily manageable, checkable and accessible—which tends to mean more sales and lower costs for you.

Controllers

Controllers are the busy command centers of a Rails app, taking instructions from the user, passing them on to other parts of the Rails app for processing, then delivering back the results.

So a user might enter their username and password to sign into their account on a website. The browser (Chrome, Firefox or similar) will send the username and password to the user’s controller file. The user’s controller, in turn, will hand over the data to the model and database, to check that it’s the right password, and wait for feedback.

Next, the model lets the controller know that all’s well. The controller can then hand the message back to the user’s browser, refreshing the page to say “you’re all signed in!”

Controllers, in other words, check to ensure that your app’s code is organized and optimized and that requests from the browser are dealt with accurately and quickly. Everyone loves a fast website, right?

Views

Last but not least, views are files that often contain a lot of HTML. They’re the bit of the Rails app that describes what the webpage will look like.

Have you ever done a mail merge in Microsoft Word? You have the bulk of the letter typed out, but when you want to put in a bit of dynamic data, such as a name or an address, you pop a placeholder tag in. When you run the mail merge, lots of versions of the letter get produced, with the right data magically appearing in the placeholder tags.

That’s what Rails views are like—some static HTML with bits of dynamic, changing data being swapped in and out according to what the model and controller tell it.

Which means you don’t have to write hundreds of pages of HTML for your hundreds of books. You write one template, and Rails fills in the data dynamically. Sounds like a time saver to me!

Design Patterns

Rails sensibly uses some tried and tested programming patterns. Patterns are ways of doing something that people have thought through and found to be a good idea. Here are two:

Convention over configuration: By sticking to a series of rules that govern the basic setup of a web application, Rails developers can avoid writing repetitive code and get to the good bit faster—the actual design and logic of a particular application brief.
DRY (“Don’t Repeat Yourself!”): We only write code once and reuse it. This makes code more maintainable. For clients, that means cheaper and, ideally, more scalable applications.

What It All Means

With such a regimented approach to code organization, Rails apps are great for teams because they provide a lingua franca. Everyone knows where to find the sort of code they’re looking for. So your project can be worked on by more than one developer or picked up by a new developer, and there’s no awful learning curve to figuring out one coder’s particular take on things.

Rails’s popularity and longevity (its first release was in 2004, an eternity ago) means there’s a phenomenal infrastructure built around it, in terms of the number of active developers; the number of code libraries it plays nicely with, such as jQuery (Javascript code that runs in web browsers, making the user experience smoother); and services such as Heroku, a “platform as a service” that makes deploying applications to web servers fast, cheap, robust and reliable.

Rails means developers can create complex websites, fast and cheaply. From publishers’ points of view, that means more bang per buck. And even for publishing professionals who don’t work in Rails or develop websites, simply understanding how Rails functions can be a great practical asset as the industry finds its footing in the online marketplace.

It's us in the industry who need to be able to code

2018-01-01T00:00:00+00:00

I have a dreadful confession: I still use my fingers to do mental arithmetic. After a couple of decades in the commercial world I can do sales-minus-cost-of-sales-all-over-sales-equals-margin in my sleep, but ask me 14-plus-27 and I’ll tap out the four, just to be sure.

So given this pitiful natural capability, coupled with an arts degree (archaeology, and not the statistical, analytical sort, but the vague hand-wavy these-sticks-signify-an-ancient-rite-of-passage kind), you wouldn’t think I’d find myself a professional Ruby on Rails programmer at the age of 40.

Yep, I’ve done my ten thousand hours. Since 2011 I’ve spent an average of eight hours a day practicing and writing SQL, Ruby, Rails, Javascript, CSS and HTML.

I might be useless at arithmetic, but, you see, I love patterns. I’m a pianist and an artist. I like words, symmetry and brevity. Writing code trips many of the pleasure centres in my brain. And I love feeling that I’m doing something meaningful, creating something out of nothing. Plus the inherent difficulty of writing good code is a source of huge pride.

I’m also someone who is fairly bloody-minded and determined, who can’t stand doing a boring task more than once – and I’m an independent publisher, which is not a subset of the population known for its great wealth. Given a choice between finding £150k to get someone to turn my ideas into code, or just reading the big thick technical books and putting the hours in, the decision is not hard.

The main reason for spending so much time learning to code, though, has been the desire to solve an urgent problem. Ever since I co-founded Snowbooks in 2003, I’ve wanted a system to help me manage the business in the way I think necessary – with all my data in one place, with an absence of duplication, with as little data-entry effort as possible – to rescue me from organisational chaos. I have always wanted computers to do the drudge for me so I can get on with publishing, with cover design, with imagining new ways to sell books. In other words, I want to be a creator, not an administrator.

Who goes into publishing so they can spend their days typing metadata into spreadsheets, and PubWeb, and InDesign AI templates?

Integrated systems that cover metadata, ONIX, production, royalties, contracts, rights, permissions, schedules – everything, really – do exist, but you’ll have to remortgage to afford them. So I’ve been steadily writing my own system which is all this and more, and after four years of active development, with a growing team of programmers, it’s rather wonderful. Have a look at Consonance.com to see the fruits of our labours.

Ten thousand hours later, I have magic fingers! I can think of an idea for an app, or a website, or a little program to help me automate a boring task, or receive a feature request for Consonance, and presto – I type the code. No briefing people. No meetings to agree the agency budget. No fighting for sign off. No trying to explain my idea to a developer with mounting frustration on both sides because we’re speaking different languages. I just get on and write the code. And enjoy the results.

I now occupy this zone where I know plenty about both trade publishing, and plenty about code.

You know that weird feeling when your parents turned up at your University? The sensation that your life at University is completely separate and other to your family life, and it’s just plain weird when the two worlds collide? I get that when I’m talking to most publishers about code, and most coders about publishing. There is barely any intersection between the two sets at anything other than a buzzword level. And when there is, those people are remarkable. To name a few, Nick Barreto, James Bridle, Xander Cansell: publishers who code can do amazing things.

To the coders, I’d say this.

You should learn more about publishing. Too many apps exist because their creators thought the code would be cool. The code probably is cool, but you walk the aisles at the book fairs and see that no-one’s clamouring around the stand of yet another ebook delivery platform. The SaaS build-it-and-they-will-come model only works, rather obviously, if you build something that people want in the first place. So:

Start a little micro press.
Try to sell a book in to a high street retailer.
Pick apart a printer’s scale.
Write a royalty statement that doesn’t confuse your authors.
Try to update the Ingram metadata spreadsheet programmatically.

You’ll end your first week as a publisher with a hundred ideas for solutions that will answer an actual problem. Completely Novel and Valobox are a good example of this. The team know all the real-world details of working with authors, printers and so on from running their Completely Novel self-publishing platform. It means their pay-as-you-go venture Valobox was developed out of an on-the-ground understanding of the industry – and it shows.

To the publishers, I’d say this.

There is no shortage of ideas for ways that a little – or large – program can make publishing better. Our industry is built of data:

Descriptive metadata
Sales data from a huge range of sources
Reader data
Online campaign data
The words we publish and the way they’re structured into larger sets of content

It’s all there waiting to be corralled and explored and arranged in patterns which help us to be better publishers. And if we don’t learn to use all the technical tools that exist, then outsiders will build things themselves. We’re seeing that now, and we’re seeing that the things they’re building, whilst interesting, are just a shade off the mark, because they don’t know publishing like we do.

Given the data-y nature of the book trade, the fact that learning to code is so astonishingly moreish, and the fact that I’m living proof that you most certainly do not need a computer science degree to write a Futurebook Innovation Award-winning web application, I’m hopeful that I’ll be able to persuade publishers that becoming adept at code-writing is good for business, good for your teams, and good for the long-term health of our industry.

You don’t have to go as far as me.

Learning the fundamentals would be enough for you to have a decent conversation with a developer. The benefits are clear: you’ll know what’s technically possible, more or less, so you’ll both save time and energy. You’ll be able to tell if the developer is responding sensibly to your specs, and you’ll know enough to be able to look at his or her proposal and cost estimate and see if it’s reasonable.

But I bet the bug will bite you (heh, amusing code-related joke). I started out being interested in code when I took an ONIX message and used it to create a catalogue automatically in InDesign. Technically, it’s not difficult: you set up a template tagged with placeholders, and import the XML into those placeholders. But psychologically, it’s revelatory. I created hundreds of pages of catalogue copy in a single click. How long does your catalogue creation cycle take? Three months? Four? Wouldn’t you rather spend that time learning enough to automate the awful job the once, so you never have to do it again? I don’t know how anyone can stand to do some of the repetitive tasks that I see them do, when I know that you could spend a month, a week – even a few days – learning plenty to save you from death-by-admin. Once you’ve glimpsed what code can do, it’s really hard to go back.

Something which afflicts all industries is the problem of getting systems to talk to each other. But the problem is solved! Just not by the book trade. As an industry we are really backward in this, you know. There are all these spreadsheets and CSV files and FTP folders that even the largest companies still use to transfer data slowly, brittlely, between distributor, ecommerce, metadata, royalties, rights, CRM and other publishing applications. Modern APIs are clear, well-documented conventions for getting applications to talk to each other. It takes a morning to write a simple, brief JSON API, and a month to test and iterate. But there are only a handful of well-maintained book APIs around – for example, Amazon’s Product Advertising API, Goodreads’, Google’s, one or two from the larger publishing companies (and Consonance’s, of course). You look at something like accounting software Freeagent’s API, and it’s enough to make a grown man weep – you can do so much with it and it’s beautifully documented. If the accountancy industry can do it, so can the book trade.

This is an opportunity to draw a line against the relentless outsourcing of skills.

As an industry, we’re really running the risk of limiting our scope to being middle-men.

We often don’t write the books, or proofread them, or typeset them, or take the photos, or draw the illustrations, or create the ebooks, or code the apps, or print the things, or store or ship the books ourselves.

Our industry has been outsourcing everything we possibly can for years.

With code, we have a chance to take back control.

You don’t need the sort of money you’d need to set up a printing factory to bring print back in-house. You especially don’t need to hire in Rails developers on a £80k annual salary. That wouldn’t fix the problem. The problem is that it’s us in the industry who need to be able to code. You don’t know how many more books you can sell, how many more readers you can engage, how much more justice you can do to your authors’ writing, until you have the technical knowledge to create the new tools and new applications that no-one’s thought of yet.

Where do you start? You can do the free Rails course at Codeacademy.com. Follow that, and by the end you’ll have written your own version of Etsy. Or you can buy a book for $49 – The Rails Tutorial by Michael Hartl – and spend a day a week on it for six months. By the end of six months, you’ll have written Twitter. Yep: you’ll have actually written your own version of Twitter. With your own human hands.

If you don’t want to read a book (and I needn’t point out the irony of that) then come along to the course my Consonance colleagues and I run called Try Programming. The Consonance team also volunteers at London RailsGirls, which is a brilliant way for women to get experience of coding. Your kids are learning how to code. So should you.

And HR can start changing their recruitment requirements. Can you imagine asking your editorial assistant applicants, at interview, what marketing initiative they would propose given a 120,000 word manuscript, 25 illustrations, a command line, a text editor and a Github account? That probably sounds outlandish. It shouldn’t.

One of the many lovely things about coding is that it’s a proper, cerebral activity that doesn’t necessarily suit a 9-to-5 office location. It requires intense, prolonged sessions of quiet thought. It’s ideal, in other words, for working parents who can work between school runs from 10 a.m. to 3 p.m and then from 8 p.m. to 11p.m. If you’ve any desire to improve your company’s flexible working capabilities at the same time as generating new revenue streams and increasing your creative output, get your staff to learn to code.

From where I stand, it terrifies me that there is so much opportunity for the book trade, and such a dearth of skills to take advantage of it, with apparently little appetite for change.

Make this year the year that you learn to code – for the sake of our industry.

Originally written for and published by The Futurebook

Menial publishing jobs are destroying our future

2015-07-01T00:00:00+00:00

It is easy to look at a creative, or an entrepreneurial person, and assume that they do what they do because they were always 100% confident they had what it takes to make it.

I haven’t applied for a job for years, gods be thanked, but I recently stumbled upon a job advert for an entry-level trade publishing job. And it made my blood boil. So I Googled other entry-level trade publishing job specs to see if it was a one-off. It wasn’t.

To my eye, these job ads read like something from the 1950s. They require the lucky applicant to engage in “order processing”, to “maintain grids” (read: spreadsheets), to take minutes of meetings. They call for “strong IT skills”, but suffix that with “including Word and Excel”.

“Word” and “Excel” are not “IT skills”. They are typing. We recruit young, pretty women (go on, deny it), and we give them secretarial jobs.

Eventually they will get promoted, usually without an ounce of formal management training, into project management roles, supplier management roles, people management roles, data management roles. They will likely struggle, because they have to intuit an entire suite of management skills from first principles, from trial and error. They aren’t given the long-term development support necessary to be competent in senior management roles.

We are guilty of keeping junior publishing roles menial and manual. Further up the ladder, we are guilty of failing to help the women we’ve hired to be successful in management roles.

Why are junior publishing roles menial? Why are we still getting humans to do the work of computers? On every level, it’s ridiculous. Humans cost companies a fortune. They require management by other, more expensive humans. They get bored easily, because of their big brains. Administrative, repetitive, rote, data-entry work isn’t their forte. So they make mistakes — typos, copy-and-paste errors, calculation errors. The humans in question have likely spent a fortune on an education and could be using their brains for thinking, and creative tasks. They joined publishing because they wanted to create wonderful books — and they’re left wondering why copying and pasting between Excel, Word and InDesign feature so heavily in this ostensibly creative process.

Junior roles stay menial because the people writing the job ads don’t know what computers can do. They don’t know what normalisation is: they are happy to build a company that survives on multiple “grid” spreadsheets containing proliferating variations on the same sort of data. They are happy to pay people £20,000 a year to copy and paste data from one bit of software to another because they don’t know that you can, for instance, get a computer to populate sales presentations, tailored for each recipient, from a single data source, or integrate order processing systems with APIs.They pay people thousands and thousands of pounds to do mundane tasks such as this manually — again, and again, and again.

Better-specced junior roles could underpin a technically-expert publishing industry. Our home-grown talent would know how to harness the power of computers — not by briefing a third party agency, but by using their own hands — to make amazing products that compete properly with other media, that find wider audiences. As an industry, we’ve never been the leading authority on our own product.

When print books were all the rage, it wasn’t publishers who were the experts in bindings, paper technology, FSC supply chains, ink technology: it was the printers.

In the digital format age, few publishers know how to write an iOS app, or hack an ebook, or write a transactional website to accompany a series.

We are the middle men whose role is to manage external experts. Middle men get disintermediated.

How are we stopping women from being successful in later management roles? Our junior roles, from which future managers develop, don’t provide testing and difficult opportunities to think critically. I’m not just leading up to a big pom-pom wave about how everyone should learn to code: I’m talking about rehearsing any sort of difficult, logically-minded activity. We still celebrate gut feel in our company cultures. We rarely train our juniors in influencing skills or project management techniques, or provide them with the practice to develop the mental apparatus to logically unpick a problem.

We have managing editors – professional project managers, in other words – who don’t know what a critical path is (and no, it’s not a list of dependent tasks). Gantt charts confuse them. They’ve not heard of Kanban methodologies. I cringe when I hear a publisher talking about adopting agile methodologies: they’ve heard the buzzword but they haven’t put in the hours of research to know what it really means. We’re not providing the foundations from which competent managers can emerge.

As an aside, if publishing suddenly did skill-up and have project managers with formal project management skills, then chances are the big personalities wouldn’t let them do their jobs, anyway. Some publishing companies are ruled by editorial magnates, production supremos or board-level benign dictators — no amount of project management theory would override their ‘gut feel’ rulings. If the publishing director wants to change the price and print run three weeks before publication — well, everyone had better just jump, and to hell with the consequences on metadata accuracy and paper buying.

Learning to program a computer is one skill which would put juniors in a strong position to be thoughtful, powerful and competent managers of the future. But in the six months since I’ve been writing regularly for The Futurebook, I’ve met no more than half-a-dozen people who have made steps towards learning a little code. Out of exasperation at the state of affairs, the Consonance team are running our subsidised Try Programming course again in September, as part of the Oxford Publishing Group training initiative, and you should come. But it’s just one course in a vortex of functional, modern training provision. There should be advanced publishing-flavoured courses on Swift, or Liquid templating for designers, or Rails, or Go, or iOS frameworks. We should not be providing the only publishing-specific coding course.

Growing fit-for-the-future talent is a multifaceted problem. It’s to do with hard and soft skills training, and it’s to do with a combination of in-house training, personal development and hiring strategies. I would love to see job application processes for junior publishing roles which ask the applicants for their Github profile, for their open source contributions, and for a proposal on how they’d create and, crucially, implement – without recourse to expensive, disengaged external agencies – an integrated marketing campaign for a title. I would love to see training programmes that help to progress people, particularly women, in a meaningful career.

Hm. Perhaps I’ll write all this up in response to The Bookseller’s call for Manifestos for the Future of the Book Business … because without appropriately-skilled people, we won’t have one.

Originally written for and published by The Futurebook, July 2015

Consonance

PAAG charter signatory

What are your accessibility highlights of the past 12 months?

What are you working towards in terms of accessibility in the coming year?

Livestreams

2025 Spring release

TL;DR

What?

Enhanced navigation

Enhanced data insights

Enhanced accessibility

Finding pages and moving around the system

Getting data in and out

Reading pages

Accessing pages

Understanding pages

Retirements

Why?

How?

A note on mobile

Searching in Consonance

Find the paperbacks that do not have an accompanying hardback.

Find the works that are audio only

Find the products with a USD RRP consumer price but no USD RRP library price

Find the contributors who are both editors and authors

Project management in Consonance – keep the data near the dates

Roles

Discussions

Throughout Consonance

Use Consonance: publishing’s alternative to Monday.com, JIRA and spreadsheets

Taylor & Francis ONIX, by Consonance

Consonance.app now manages all of Taylor & Francis ONIX for Books.

Architectural background

Development

Results

Key statistics

2024 in review

Liverpool University Press

Book Dash

The Challenge

The Solution from Consonance

Enhanced Decision-Making with Dashboards

Tracking impact with Creatives Dashboards

Results

How to use RSS

Find an RSS reader that you like

Get our blog’s RSS feed URL

Paste the URL into Feeder

Enjoy reading!

Bedford Square Publishers

Leuven University Press

Thoughtful little innovations, at the London Book Fair '23

GraphQL at Christmas

A non-technical, beginners' guide to ONIX for Books

ONIX is a type of XML (whatever that is)

The guts of XML (made palatable for non-techies)

The ONIX Standard

In what ways might I mess up an ONIX message?

It’s well-formed but is it valid?

Don’t (necessarily) blame ONIX

Standard? Which standard?

How to create an ONIX message

Unshackle your data and free your time with GraphQL

Beautifully bespoke marketing materials

Curatable reporting tools

Forms that do the legwork for you

Powerful integration potential

Pandemic update

Update, Janury 2021

April 2020

Health and happiness

Supporting our customers

Business continuity

Thanks to our suppliers

What we’re working on

Side projects

Deanna joins the team!

Brighton Ruby, why's (Poignant) Guide, and justsimply.dev

Discussions in Consonance

Introduction to publishing management software