LJNDawson.com, Consulting to the Book Publishing Industry
Blog Directory
Back to home.

Survey Says!

Recently I got into a discussion about how midsized publishers were managing their digital assets, and all parties in that discussion (who shall remain nameless) realized that we had NO IDEA how midsized publishers were handling increased digitization and proliferation of book formats.

So I decided to find out! And share! Because that is what we do here.

I devised a questionnaire that takes a reading on several departments within a publishing house: IT, Editorial/Production, and Marketing. These are the most likely departments to interact with a DAM system, to be experiencing pain points with insufficient digital asset management, and to appreciate good asset management in an agile content delivery framework.

I queried and submitted the survey to 50 publishers. Of those 50, 8 publishers flatly declined to participate (you know who you are). An additional 20 did not respond by the requested deadline. Or the grace period. Or the grace period after that. Eventually I had to close the door just for the sake of getting on with things. (Not that they noticed. I don’t think.)

So my results focus on the 22 publishers who did respond. Who have also asked for anonymity, but I want to extend my gratitude for quick turnaround and great information!

Some general trends in IT:

Most publishers surveyed use a mix of Macs and PCs. And most of these publishers either use Adobe InDesign or a mix of Adobe and Quark. No publishers surveyed use Linux or Sun. Most of the respondents have a mix of database platforms: Microsoft SQL, MySQL and Oracle.

As far as managing digital assets is concerned, the answers seem fairly evenly divided. Eight publishers feel they have this under control; five feel it’s not an overwhelming concern; six know that this is a problem they have to solve; and two are experiencing pain on this issue.

Most of the publishers surveyed store their digital assets on a central server, using filename conventions to keep them organized. Three also use physical media to store assets. Six publishers use an external service (such as their printer’s) to store digital assets. And one publisher stores digital assets on a central server, on physical media, externally, and in a DAM (which would seem to indicate that their DAM is not sufficient for their needs).

The bulk of publishers in this survey either adapt well to change, or note that a new implementation and rollout can be disruptive, but ultimately worth it. Two publishers state that they do not handle disruption well.

Most publishers have internal IT departments, or outsource specific IT functions while keeping a “base camp” of IT staff in-house. Only two publishers completely outsource their IT.

Some trends in Editorial/Production:

Overwhelmingly, most publishers plan for more than one edition of a book. Only one publisher claimed they do not – which was proven incorrect by a glance at their website, where there are simultaneous publications of hardcover and paperback. About half of publishers report that producing more than one edition of a title is part of their regular workflow and not much work.

Publishers seem to need to re-use digital files “frequently” or “about half the time”, in most cases. These publishers are fairly evenly divided in terms of how easy it is to retrieve files. About half say that it’s easy, and about half say that it’s a project to get them. No publishers reported severe pain in file retrieval. (Which is good!)

Publishers are, as we know, wedded to workflow and this survey bears that out. Most publishers surveyed claim their manual workflow works, although some changes could conceivably make it better. Six publishers say that their workflow exists for certain purposes and changing it would be a challenge. Two publishers are in active pain around workflow.

The publishers surveyed are moving towards making more ebooks available. About a third release an ebook for every print version; slightly more are making some of their titles available digitally. Two publishers are not planning on creating any ebooks at all.

Some trends in Marketing:

Overwhelmingly publishers report using digital assets from books for web or print promotions “all the time”. Only three report doing this “sometimes.”

Artwork requests from the media are, by and large, handled manually (presumably someone emailing a cover image to a book reviewer). Five publishers have an automated process to handle this; two publishers report having to scramble. And three publishers report significant pain in print to web processes. Half of the publishers report a “fairly smooth” process with a few glitches, while six publishers report that they have automated their print to web process.

Conclusions:

According to our survey results, about 50% of publishers are repurposing digital assets frequently, and about 30% are doing this half the time.

The primary workflow concerns among these publishers are integrating freelancer or outside author content using internal tools; building an XML workflow; and increasing the number of digital titles available.

45% of publishers surveyed are just beginning to implement an XML workflow. Only 18% of publishers have fully committed to an XML workflow; 36% are either just starting to consider it, or have not given it much thought.

In terms of tolerance for change, 55% of the publishers surveyed say disruptions could possibly be worth it, although those disruptions would not necessarily be welcome. About 35% say they are flexible and open to change. And about 10% say that change is difficult.

If any other midsize publishers want to contribute to this pool of data, I’d certainly welcome it! for a questionnaire (and expect to get hectored and pestered for results). 

Bookmark this post: Add this post to del.icio.us Digg it! Add this post to Furl StumbleUpon it! Add this post to Technorati Add this post to Google Bookmarks Add this post to Windows Live Add this post to Netscape Add this post to BlinkList Add this post to Newsvine Add this post to ma.gnolia Add this post to Tailrank

Job Loss

It appears from the bounce rates (and I can’t swear to this, but it LOOKS like) about 12% of The Big Picture subscribers have, over the last six months or so, lost their jobs (or quit them – and for all their sakes, I hope it was voluntary, though I know that’s not statistically possible).

First of all, of course, if you were a subscriber at your job and you want to keep getting it, feel free to sign up with your new email address. But more importantly – next week I’ll be doing a special issue of The Big Picture about the non-employment epidemic in our business. Because I’m sure you’re not the only one saying a little prayer as you send out an email to someone you haven’t spoken with in a while, hoping there’s still someone on the other end to receive it. Or appending, "If he/she is still there," to all your sentences.

An extra treat – Brian O’Leary will be offering advice in next week’s issue as well!

 

Bookmark this post: Add this post to del.icio.us Digg it! Add this post to Furl StumbleUpon it! Add this post to Technorati Add this post to Google Bookmarks Add this post to Windows Live Add this post to Netscape Add this post to BlinkList Add this post to Newsvine Add this post to ma.gnolia Add this post to Tailrank

Subway readers

As I was headed to a meeting this morning on the 4 train, I looked around the subway car and did a quick count.

40 riders
15 reading something (on paper – a book, a newspaper, a document)

That’s 37.5% of the car, reading.

You extrapolate that to all the subway ridership – 120,000,000 riders a month – and that gives you 4.5 million instances of reading throughout New York City at any given moment. Just on the subway.

Bookmark this post: Add this post to del.icio.us Digg it! Add this post to Furl StumbleUpon it! Add this post to Technorati Add this post to Google Bookmarks Add this post to Windows Live Add this post to Netscape Add this post to BlinkList Add this post to Newsvine Add this post to ma.gnolia Add this post to Tailrank
Developed by Codehead