If you are a Bibliocloud client, you have always been able to click a button to download your metadata directly from Bibliocloud 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 Bibliocloud 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 AI 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.

Screen shot 2018 01 30 at 15.33.20

Screen shot 2018 01 30 at 18.00.57

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.

Screen shot 2018 01 30 at 15.40.05

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.

Screen shot 2018 01 30 at 15.43.13

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.

Screen shot 2018 01 30 at 15.46.06

Ais 1

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 Bibliocloud 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 master), 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.

Cc49826 tests

We then share that code with colleagues on a code storage service called Bitbucket, 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 master version of the Bibliocloud codebase.

When the code has been buffed to perfection, it’s approved by colleagues and merged into the master 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:

Screen shot 2018 01 30 at 18.33.31 2

Depending on the scale and nature of the change, we will either send that code to the Bibliocloud 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:

Screen shot 2018 01 30 at 16.00.30

or a bit like this:

Screen shot 2018 01 30 at 16.01.39

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:

Screen shot 2018 01 30 at 18.43.10

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!

Archives

    Most popular

  1. Ruby code and why you should care
  2. A quick look at data visualisation and analysis
  3. Learning how to code, the long way around
  4. It's us in the industry who need to be able to code
  5. Menial publishing jobs are destroying our future
  6. A manifesto for skills
  7. Company news

  8. New website
  9. 2018 Customer survey report
  10. 2017 in review
  11. Prizes galore
  12. And now we are five
  13. Sara O'Connor to join the team!
  14. Product news

  15. 'Continuing to solve real problems': Futurebook 40, London Book Fair 2018 and the Works page
  16. How many authors is too many?
  17. Better ONIX fragments
  18. Advanced advance information!
  19. Schedules page
  20. Publishers hack their own bibliographic data
  21. Case studies

  22. Burleigh Dodds Science Publishing
  23. Zed Books
  24. IOP Publishing
  25. Code

  26. What publishers need to know about Ruby on Rails
  27. A publisher’s guide to APIs
  28. A day in the life of a programmer
  29. How APIs can make publishing more efficient
  30. eCommerce

  31. To go direct, publishers must mean business
  32. Why publishers must use direct sales
  33. Inbound marketing
  34. Don’t outsource your publishing business away
  35. Who has the balance of power over data?
  36. The business case for going direct
  37. ONIX

  38. A hidden benefit
  39. Thema Subject Codes Update November 2017
  40. ONIX. Not very standard
  41. Three ways to do more with ONIX
  42. A non-technical, beginners’ guide to ONIX for Books
  43. How to create a catalogue automatically using ONIX and InDesign
  44. ONIX Changes
  45. BIC, Thema and artificial intelligence...
  46. Skills

  47. Publishers can learn a few things from programmers
  48. Mechanical sympathy
  49. A taste of code
  50. Embrace the code
  51. Strategy

  52. The right tool for the job
  53. The search for publishing's holy grails
  54. Decisions, decisions
  55. Rejuvenation
  56. No computer system can fix a broken publisher
  57. Responsibility, Authority, Capability
  58. Start with Why – How to refine your publishing mission
  59. Creative industries and the division of labour
  60. The real price of a strategy shift
  61. Technical debt
  62. Why ‘easy’ publishing solutions hardly ever are
  63. Five things I've learned since moving into enterprise product management
  64. Managing expectations
  65. A company of one's own.
  66. Sometimes, size matters