How to organise your print magazine using Apollo

Publishing is the king of deadlines. If you organise a publication, print or online, you definitely know that making a magazine is like juggling balls of different weight and size while reading Shakespeare. Apollo comes as a great helping hand for the publishing world. In this article, I will explain how to make Apollo work for your print magazine.

Two projects per issue

There are two aspects to creating a magazine: the contents side, and the production side. Normally, while Issue 10 of a magazine is being worked in terms of contents, Issue 11 and issue 12 are in production (with issue 12 being way more ahead than issue 11). So, the best way to organise things is to have two projects per issue: one for the contents, and one for the magazine's production.

For the contents side of things, it's interesting to see that the project's task list section can easily work as a table of contents, where each task list is a magazine's section, and each task is an article (where the responsible person is the author). This means that you will be able to see the issue's table of contents and authors very quickly: authors will also see it when you assign them articles, and see their deadline. Finally, you can easily discuss things with the authors using Apollo's comments.

For the production side of things, Apollo will be used as a "classic" project management software: there will be things to do, each one with a deadline and a person responsible to do it. Tasks like work on composition, generate blueprints, etc. will all be marked as ongoing and eventually done. One creative way of using Apollo is for advertisers: you can have a task list with the list of advertisers for that issue. Each ad is one task, which is marked as "done" when the creatives are 100% in. You can also use Apollo to communicate with the advertisers, keeping everybody informed about what's going on.

The users

At workspace level, you should have:

• One internal user for each author; give them access to the contents project; and
• One internal user for each person involved in production; give them access to the production project
• One external user per advertiser.

The beauty of having two different projects is that you can give authors access to the issues they are writing for. This has the practical consequence that when you pick an author for an article, you are only given the list of currently involved author for that issue (and it's obviously easy to add them via Project > Users if necessary).

Advertisers are then external users who need to complete the task associated with them (that is, hand in the ad in high res).

If you are worried about advertisers seeing too much, you can also make most task lists private; this will prevent them from seeing other aspects of production, although it's arguably good for them to see what is going on.

The milestones

In terms if milestones, remember that you have two projects here: Contents and Production.

For Contents, it makes sense to only have one milestone connected to every single task list in the project. That way, you can see how much of the magazine you have received. The milestone can be called "All contents in and edited".

For Production, you should have the following milestones:

• Contents all in
• Blueprint approved
• Printing done

Note that "contents" in this case, as far as production is concerned, includes the ads.

The task lists

Since you will end up having two projects, have a look at the task lists for either one of them.

Contents project

As I explained at the beginning of the article, a project's task list will effectively be its table of contents where each article (task) will belong to a section (a task list) and will have a deadline and a person responsible for it. You will also be able to discuss things with authors. You could also decide that when a task is in "progress", it means that you have received a first draft from the author, although you haven't yet approved it 100% (it could have missing images, etc.).

Production

For the production side of things, you will have the tasks according to your magazine's workflow. In the example here, I kept a fairly simple pipeline, which you will most likely expand to suit your needs.

You will be able to discuss each tasks with the relevant people in the team, as well as attach files and eventually mark things as "done".

Writeboards

Writevoards are, in the publishing project, a great way to get articles handed in and worked on. They have a lot of features that would be a publisher's dream: ability to see the differences amongst versions; ability to discuss; ability to keep and view different versions of a text. Ideally, you could have a writeboard for each article. You could also hint the Apollo team the importance of linking writeboards and tasks (something that has been talked about). you can clearly see a risk of duplication: do discussions happen in the writeboard, or on the task itself? You could established a rule where discussions about outline and contents would be in the task (that is, discussions before the article is handed in); and discussions about sentencing and editing would be in the writeboard (that is, discussions after the article is handed in).

As far as the production project, writeboards probably don't have such a fundamental role.

Contacts

Since advertisers are proper "users" (they can login and update the correct ad), the contacts section is probably not as crucial here. However, as far as the magazine is concerned, contacts can be used for:

• Subscribers
• Media contacts who do not have access to the project
• Author's full information

Remember that in Apollo you cannot link users and contacts. This is because contacts are workspace-wide, whereas users are global entities (the same user is able to login onto several Apollo workspaces).

The files area

The files area in a project in Apollo contains both attachments (files attached to comments, notes, etc.) and "free standing" uploaded files.

Luckily, you can enable a filter and only see the files that were attached directly to the files area. So, you could decide that all files attached directly are the final, print-ready versions of what they represent. You could see the direct upload in the Files area as the confirmation that "cover.jpg" is the cover that will be used for the issue, for example (all all the drafts attached to the cover task can be ignored).

Messages

Messages can be used to communicate with the team; remember that messages are project-related. So, a project message for the Contents project is ideal to communicate the focus of that particular month to your readers, or to let them know about important news that might influence what they will write about.

For the production side, my experience tells me that the messages section would be a lot less fun: it would focus on deadlines, warnings and general scary messages about the importance of not being late.

Templates

Apollo's templates are absolutely perfect in a magazine-like environment: you would likely set up two different templates, one for Contents and one for Production. The Contents template would have all the sections as task list, and all of the "common" articles already there. The Production project would have all the tasks that need to be done month after month to close an issue.

Happy magazine!

This article obviously has a simply proposal on how you could organise your magazine using Apollo. You will need to adapt it to suit your needs and your existing workflow. However, hopefully this article gave you a good starting point!