As a publisher of any size there is a large number of tasks required to get a book from initial conception through to publication, and the challenges increase with the number of books you’re managing, the number of staff and departments, and the variety of products.
The date by which these tasks must be completed is often related to the publication date of the products being produced. For example, a task to “confirm the product prices” might be required to be completed by three months before the publication date.
The to-dos functionality helps your organisation manage these tasks by providing ways to list all of the tasks to be performed in production of a book, to assign the tasks to a user who has responsibility for either doing the task or for making sure that a third party has done them (e.g. to check that a printer has shipped the products), to see all or some of the tasks on external calendar systems such as Outlook or iCalendar, and for tracking whether and when the tasks have been completed.
A to-do is always associated with a work, and each work has its own page on which the to-dos are listed. This is generally the best place from which to create new tasks, as you can also see the other tasks specifically for that work.
There are three elements of a to-do
“What needs to get done?”
Enter a description of the task that needs to be done.
It might be tempting to phrase these in terms of a task that should be completed by a third-party, such as
Print books. However unless the person to whom the task is going to be assigned is going to be actually doing the task (
Finalise subject coding), phrase it according to the task that will actually be done by the assignee:
Send files to printer
Check printer proofs
Confirm job with printer
Check printer has shipped products
Because to-dos do not have a duration, use multiple to-dos to indicate the events that mark the beginning and end of tasks. For example if a proof-reading is expected to take five days, use two to-dos “Start proof-reading“ and “End proof-reading“ five days apart. This also allows you to show progress by completing the “Start” event Because each to-do is associated with a work there is no need to mention the name of the work in the to-do description
“Who is responsible?”
The person responsible must be a user of the system, as they will be the person who checks the activity off when it is complete.
There are three options for specifying a date.
Firstly, you can leave the task without a due date. Avoid this if possible, as undated to-dos will not be listed on external calendaring systems, and if there is no date by which it is due then you have to womder whether it is worth doing at all.
Secondly, you can specify a fixed date. This might be most appropriate where the urgency is dependant on an external factor, such as the need to send metadata to a sales agency by a particular date that they have dictated.
Thirdly, you can specify a relative due date. This lets you say that a task is due some time before, or possibly after, some event associated with the work such as a publication date. Quite a few of these “base dates” will be listed in the drop down, such as:
- “Earliest pub date” – the earliest date on which a product is expected to be published
- “Latest eBook pub date” – the latest date on which any ebook product is expected to be published
- “MS delivery date” – the manuscript delivery date on the contract
These should be self-explanatory, although it is likely that some of these will have no date value showing – you may not be currently planning on a PDF ebook for example.
By selecting one of these base dates and entering a number of months and/or days, you are specifying the date by which the to-do task should be completed.
For example, if you know that the products should be at your distributor one month before the publication date you can specify a task forCheck delivery to US WarehouseasDue 1 months and 0 days before earliest print pub date. If the earliest print pub date changes at any point in the future, due to delays in the manuscript delivery for example, the due date for this to-do will automatically change.
Positive numbers are treated as “before” and negative numbers as “after”, so you can create a to-do “Conduct anniversary performance review” with “-12” months, which will be twelve months after the publication date.
You can mix positive and negative numbers, so “2 months and -1 days” means “one day after two months before …”, and “-12 months and 5 days” means “five days before the first anniversary”.
If you select a base date that has no value, such as “Earliest audiobook pub date” on a work for which there is no audiobook planned, the due date for the to-do will always be blank until that base date has a value.
The due dates of the to-dos in Consonance are often going to be estimated well in advance, and could clash with other dates that are not expected to be stored in the system such as staff vacations, public holidays (in countries where key suppliers such as printers operate as well as your own), or industry events that you’ll be attending.
It might also be helpful to be able easily to identify situations where completing a task a little early or late may be beneficial. For example, if you are meeting with an author on Wednesday it may be helpful to push back a briefing with a cover designer until the day after, or advance a
Check with author on peer review feedback to a few days before.
Furthermore, because of the natural bunching up of publication dates that many publishers have, you may find that the due dates of similar tasks across multiple works naturally coincide with each other, and you may want to tackle several related tasks together.
To help identify, and either avoid or take advantage of these situations, the due dates of to-dos can be made available to external calendaring systems such as MS Outlook, iCalendar, Google Calendars, Lotus Notes, etc., where they can be viewed alongside all of the publishers other commitments. These calendaring systems might be installed on your computer, such as for iCalendar, or be a web-based system such as Google Calendars.
This is called “subscribing to a calendar”, and the technology is described in more detail in this article.
Two types of to-do calendar subscription are available:
- A full client subscription, in which the calendar system will see all incomplete to-dos for the entire client account.
- A user subscription, in which the calendar system will see all incomplete to-dos assigned to a particular user of the system.
You can access your own user calendar subscription URL from your dashboard, on the to-dos panel, or the full client subscription URL from the to-dos page accessed under “Workflow” on the main menu.
you can also subcribe to other users’ calendars by asking them for their own URL – by adding multiple users’ calendars into your system you can use the calendar system controls to show them in different colours and to temporarily hide them.
Why use to-dos instead of schedules?
To-dos serve a very similar purpose to the existing schedules and tasks functionality, but with some important functional differences. Some of these differences, particularly where they represent current limitations in to-do functionality, are likely to change in the near future as the to-dos get further development attention.
Firstly, to-dos can be defined with a relative date that will change their expected completion date based on publishing and other system dates. This is not, and never will be, available in scheduled tasks.
Secondly, to-dos do not have links between them. This is likely to change in the future, with the ability to state that a to-do is blocked by others.
Thirdly, there is currently no templating functionality available for to-dos. It is likely that in the future we will let to-dos be added to a work by copying their definitions from another work.
Fourthly, to-dos are directly aimed at integration with external calendaring systems, which are a great way of working with them.
Should we be using to-dos?
To-dos are a very new feature with more development due soon, but we are commited to the current feature set and it is safe to use them without fear that they will fundamentally change or that data will be lost due to an upgrade.
We are encouraging all clients to try them and to provide feedback on any ideas they have that will improve the functionality. For clients currently using Schedules and Tasks, we can migrate that data over to to-dos.
It is unlikely that Schedules and Tasks will get much development attention in the future. they are very reliant on third-party open source libraries that we do not have great influence over, and which have a rather different approach to project management than a typical publisher.