From Print To Screen
Part One - Overview
by Ben | 1st Nov 2017
This is the first part in a series of articles in which I intend to go through the process I use to "convert" a complete print magazine into an "Active" issue on the site.
This series will be a deep dive, so for most readers, this first overview part will be enough of an insight into the process to get an idea of the effort involved. Subsequent articles will go deep into the weeds for the people who are interested, or who maybe are considering tackling something similar and would find it useful to get an idea of what's involved, what problems they may encounter, what solutions I came up with, and what tools to use.
So, let's take a broad overview of the the main task groups, once we have a physical issue in our hands to process:
(Guide time: 1.5 hours for typical 80-page issue, could be 3 hours or more for 280 page SOS)
(Guide time: 5m)
(Guide time: 10-30m typically)
(Guide time: 10m)
(Guide time: 30m)
(Guide time: 30-60m typically)
(Guide time: 4-6 hours typically)
• Guide times are based on a typical 80-page issue in good condition. Older manually-typeset issues, damaged or poor quality issues, lots of image processing and large page-count issues like IM&RW and the later SOS will all increase the time taken on various tasks.
• Also, there are some additional features added since starting this blog, including Advert Tagging, and Gear Tags, so I'll cover them separately.
With any large, complex, multi-step task, the key to keeping it manageable is to make the process as simple, quick, and automated as possible. Every few minutes that can be shaved off a task with an improved tool or workflow, and every task you can get the computer to do for you instead of doing it manually pays off when the process needs to be repeated hundreds, or thousands of times. Workflow really is the key.
I try to keep flexible - I won't necessarily do all steps 1-7 (above) per issue in order. I might do 10 issues of scanning (step 1), or I might process the scans for a few issues in a row (step 3), or get the next three issues up to the proofing stage (step 7). The reason is that the different steps require different resources and mindsets - if I'm sitting in a cafe for an hour, I can't be scanning, or outputting from the scan library (which is on an external drive I don't have with me), but I can be OCRing, or proofing. If I've got a podcast to listen to, I can't be proof-reading articles, but I can be image processing scans or working on article images. Got some TV to watch? I can't really do visual things like image processing, but I can scan another issue, or do some text processing - and so on.
Sometimes items within a task can be done in a different order, or a little differently with the same result, and this also helps break up the monotony.
Keeping the tasks flexible is also key to staying motivated, as I can choose to do tasks that suit the current situation/time available/mood, rather than be forced into doing a particular step that's not convenient at that time, causing a workflow block. This helps keep the project moving forward.
Workflows should generally evolve and improve over time. The workflow I have now has evolved immensely since I started, with the result being that the time and effort it takes to get an issue done - while still significant - is significantly less than it used to be.
(As a rough idea, an issue of MT, a reasonably "easy" magazine to process, took around 20 hours to do when I started. With my current workflow, those issues take around 5-6 hours - with better results and quite a bit more meta data options.)
You can't build a workflow until you know what it is you need to do. And you won't know what you need to do until you have experience actually doing the work. So, it's advisable to start with an initial survey to get an idea of the basic workflow, and then put that into action. As you come across new problems, or ways of optimising the workflow, you solve those problems, implement and improve them, and evolve the workflow so it can handle those things better.
In the case of mu:zines, I started first by looking at one issue of Music Technology, and running through processing some example articles to get an idea of the process. As I came across new things, I would adapt the workflow accordingly. And then I'd get onto a new publication, and find this threw up some new things I wasn't expecting - forcing new solutions to be made. I'll go into these in the later parts of this series.
It's important as you work to constantly identify areas that could be done faster, better, improved or automated, and implement them as you go. The net effect is that the more content you do, the more efficient and evolved the workflow is, so it gets *easier* over time, rather than getting more and more bogged down as the process gets inevitably more complex.
So, flexibility, and efficient workflow is what we're going for.
Next time, for part two, we'll dive into the Scanning process...
Next part: From Print to Screen - Part 2: Scanning
Part 6 - OCR Part 1a - Contents & Metadata | Apr 2020
Blog entries from 2019...
Synth Patches - The Return | Dec 2019
Part 5 - Outputting the Scans to Use | Nov 2019
*Almost* the first DAW... | Oct 2019
...and Three New Things (Polyphony, Ads, & Stats) | Mar 2019
Part 4 - Processing the Scans | Jan 2019
Blog entries from 2018...
More Flexible Gear | Oct 2018
Part 3 - The Scan Library | Oct 2018
and music shops, and lunch money... | May 2018
Our 200th issue brings One Two Testing to mu:zines | Apr 2018
Birthday Time Again! | Mar 2018
Don't miss them! | Jan 2018
Part Two - Scanning | Jan 2018
Follow mu:zines on Twitter: @mu_zines
for updates and other bits and pieces