Roads? Where we're going, we don't need roads

Rich Holman is a user experience consultant, designer and web developer. Follow him on Twitter at @dogwonder.

Publishing is full of innovative people who love content. Mix that with a culture of collaboration and the future is bright, argues Rich Holman.

Hello, so first of all *disclaimer* I used to work in publishing (eight years in Macmillan as a web developer) and during that time worked with Jon. I currently work in a leading social business consultancy – Headshift. We help a range of organisations (BBC, British Airways, BP, NHS, Anthony Gormley’s One & Other) across all sectors and realise and build technologies in this ever-changing landscape. I have been there for two and a half years now, so feel I have a good historical understanding of the challenges facing publishers as well as a unique view of the differing cultures of both traditional publishing and a technology start-up.
I recently read a previous post, London Book Fair Digital Conference, with interest, and thought a lot of good points were made. I agree there is a lack of skills in the publishing industry to deal with new emergent paradigms. In fact, one of the reasons I left publishing was so I could emerse myself in an industry and culture that is purely concerned with thinking and building future applications online. I felt some of the post’s sentiments needed to go further, as it’s not just skills and structure that are lacking but culture and attitude. In a period of accelerating change we need vastly more efficient methods of developing new concepts: there is simply too much disruption to plan and build websites as we would plan and print books.

Our structures need to be more speedy. Speed used to kill now lack of speed kills. Lets have organisations that can iterate quickly and empower its folks to make decisions. Percolating decisions up and down an organisation makes little sense
VIVAKI’S RISHAD TOBACCOWALA

In this post I want to share some thoughts about some of the changes that would be required for publishers to become more agile, generalist and collaborative in an age where we are all becoming publishers, authors, creators and consumers and as such all have a voice and opinion as well as the ability to implement our own ideas. At the end of the post I will talk about a small project myself and a colleague ran to illustrate the speed and agility that such a cultural change could provide.

But first… an agile approach

Marty McFly: Doc, we better back up. We don’t have enough road to get up to 88.
Dr. Emmett Brown: Roads? Where we’re going, we don’t need roads.
BACK TO THE FUTURE

Maybe just a film quote, but it illustrates a major problem when trying to consider future directions: it’s based on current knowledge and as such potential solutions are limited by current understanding and restrictions. What is required is a cultural shift and with regards to development we should be thinking more like start-ups, small, non-hierarchical agile generalist teams of creative, talented individuals of which there are increasing amounts as people tinker with the emerging web (such as that developer in the basement).
I’ll use my experience at Headshift as a small case study on how we approach new projects. Firstly, a project team of anywhere between 2 and 10 people is formed from the skills required to deliver the project. These will generally include:

• A project manager whose role is to manage client/stakeholder communications and ensure the project hits budget and/or schedule as well as meets client expectations (i.e. is it good?)
• A consultant (one or more of technical/general or user experience) whose role is to speak directly to project stakeholders and end-users to really define the scope of the project and the nature of the problem the project is trying to solve (i.e. question what you are really trying to solve not just what you think you are trying to achieve). Technical and user experience consultants are involved to ensure the project requirements are grounded in sound thinking and can be achieved within the timeframe / budget and match client expectations.
• A designer/user experience consultant to make sure the product not only looks good, but works well. A designer’s role is to ensure the application or website is easy to use and the end-user not only likes the look of the website but enjoys the experience and successfully completes tasks. Good visual/interactive solutions to complex problems can be more than half the battle.
• A developer(s) to realise the combined output of consultants and designers. It is essential they are involved in project planning and foster a close relationship with the designer/consultants. They are essential in realising the eventual product, as such they need to be heavily involved with the whole project team, early and often.

You may find that people will take on one or more of these roles. I myself have performed consultancy, design and development on one project. Project management and consultancy may also be combined. The generalist can be very important here in creating nimble teams.
Generally for most of our projects we approach them iteratively (build often and early) while checking back with the stakeholders with early test versions and regular staged releases to ensure that expectations are being fulfilled and to avoid the awkward situation when perceived outcomes differ massively. Generally we build projects against the methodology known as “Agile”, not so much a process as a philosophy that:

…values individuals and interactions over processes and tools, working software (aka outcome) over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. It’s not that there isn’t value in the latter, just that the former has more value.
NEIL PERKIN, Agile Planning

This approach requires that all people involved in the project work very closely together to ensure that end result is greater than the sum of the parts, by enabling project team members to have more control over the outcomes of a project indivual knowedge and creativety can add much more value to a project.

Projects are built around trusted, motivated individuals who are given the environment and support they need. Documentation is kept to a minimum, with face-to-face communication preferred, and a focus on simplicity – maximising the amount of work not done.
NEIL PERKIN, Agile Planning

This requires a major shift in the way projects are currently ran in most publishing houses, as many projects tend to be about writing a 400 page spec based on current business models and expected outcomes and then passing that to a software development house or to an in-house development team. In the more agile approach projects can be built around solving a problem iteratively and collaboratively, as well as questioning whether that problem even needs to solved (or indeed is this the correct problem). This is all achieved by actually working with, talking and listening to the people that will be affected by the eventual system, including end-users and stake holders, not just as a requirement of a business model.
Publishers in general have lots to offer in aggregation, quality control and understanding the needs of the end users. However in defining both the problems and the solutions they need a different approach, an approach that has been developing in Internet start-ups for over ten years and has a proven track record in delivering fast, smart, and useful applications not always based on a need but based on the simple fact that we can.

A delicious book – an example of building fast

So to illustrate what small, agile teams can do when not bound by process and business models a colleague (Felix Cohen) and I built an application to print our own books. The generation of the idea was no more than Felix’s desire to ‘scratch an itch’ that was caused by our often cited problem of never getting round to reading long format articles on websites (based around the same reasons that many people reference, bright screens, distractions etc.)
The resultant application takes a list of websites and converts them into a styled PDF ready to print via a service such as Lulu. The list of websites is created by using an online service called Delicious – effectively an online version of a browser’s bookmarks, with the added benefit of being accessible from anywhere (and from a development perspective accessible to an application such as this). The outcome is a printed book based on bookmarked websites. The application goes though each link and pulls out the main body of content – and it is clever enough to strip out banner ads, links, navigation leaving only the article’s actual content, formatted and separated from styling. We then apply our own custom styling optimised for a print layout. The entire project took 8 hours to develop, and we can now create a custom typeset printed book in seconds. The code and the printed book is not perfect but it illustrates what can be done very very quickly given the right conditions.

We have released the code for this project so anyone can build and share the concept. Firstly we wanted to engage with people over the benefits of utilising a more innovate way of building projects as well as the obvious copyright issues in trying to commercialise such an application.
As Felix ends his blog post over on the Headshift blog (Ruby on Rails is the coding language Bookler is built on):

What is significant, though, is that ease. Neither of us are part of the Ruby on Rails team here at Headshift, but were able to pick up enough Ruby to build it in Sinatra (a very simple, very great framework for this kind of app), and find enough tools to make it fast, easy and ‘good enough’. The generalist skills and assumption that this would not be a hard problem, however, do seem important.
FELIX COHEN, Technical Consultant

If you wish to check out how and why this was built, as well as get access to the code see here.
This illustrates the need for cultural shift as well as some potential solutions and approaches. It’s pretty exciting to be able to build something like this so quickly just with modern tools, technologies and a “because we can” attitude. Simply employing a few geeks is not going to change much, if publishing is going to be part of the solution to the current problems then fostering the culture where ideas can be realised quickly and easily is essential.
Also, believe me when I say many many of my peers still love print (check out the Newspaper Club). They also have the ability to publish their own material, curate others and build applications to produce solutions for their own needs and desires. My experience working in publishing is of a dedicated, innovative, interested bunch of people who love content and delivering readers and authors a great service. Mix that with the abilities of people who can realise those qualities in a collaborative way (this is essential), and the future is not necessarily the dark place some assume.