Arc XP print integration
Arc XP is digital first
It is important to note at the beginning of this discussion about print integration, that Arc XP is a digital-first platform. This refers to a prioritization of digital products while viewing more traditional channels, like print, as downstream destinations. This digital-first emphasis does not suggest replacing traditional channels with digital channels, but instead, a reordering of priority. We view your website as the first priority for content, with print, social media, newsletters, and so on as other channels or destinations for that same content. That said, we do understand that there are still many reasons why print is an important piece in your publishing pipeline, so let’s explore how to get your content to that destination.
Questions to ask when deciding on the proper setup
We encourage you to explore three questions to find the best print integration solution for your organization.
Where would you like to budget or plan your print products? Will this be inside the Arc XP platform or somewhere externally, like your print CMS?
How will you transfer content from Arc XP to your print CMS? Depending on the answer to question one, we have several options for what we want to use to trigger the sending of your articles to your print system.
Where do you plan to make print-specific edits?
Standard models
Arc XP provides three standard print models.
Publication model | Composer Send model | Feed model |
|---|---|---|
|
|
|
Model 1 - “Publication”
 |
The first model is the Publication model. This is the preferred model, allowing for the most integration and visibility of content within the Arc XP suite of tools.
 |
A sample workflow might look like this:
You write an article in Composer.
At some point, probably prior to it being published or even edited, an editor “pitches” the article to a WebSked Publication, which can be done directly from within Composer or through WebSked. During the setup, we will have mapped the Publication sections/editions to correspond to a print section or sub-section. Pitches can also be sent to a “backlog” where an editor can make the placement decisions at a later date. More about Publication pitching in Managing WebSked publications.
During, or in advance of, the print planning meeting, editors responsible for print begin reviewing the pitches in WebSked and “book” them into a given print edition (today, tomorrow, hold for the weekend, etc.) and slot them into the appropriate section and sub-section. They can also order the articles to set their priority within the section/sub-sections. Finally, they can use the notes fields to communicate things related to design or page placement. We can use this “booking” action to send that article, and its assets, over to the print CMS.
 |
If the organization so chooses, the editor could also use the “finalize publication” (the small lock icon) to signal that the section is complete and send all articles in that section over to the print system at the same time. The benefit of this model is that you can control the order of the articles as well as block that section from further pitching, however it does delay your print team from receiving individual articles as they are completed.
If changes are made to the article after they have been sent to print through the Publication, an update may be sent through the “Send to print” button in Composer. This will most likely create a new branch of that article within the print CMS and allow you to accept or reject that new version, but this may vary depending on your print CMS system.
Note
The publishing of the article online is a completely separate process, and the published state of the article will not matter when sent to print.
When to use this model
If your newsroom is large or you have a large amount of content across multiple sites, this model will allow you total visibility into all content in your system through WebSked.
Integrated Copy Desks that want to use the Arc tools to budget and track options for your print product(s).
Newsrooms with multiple or varied print offerings.
Model 2 - “Send to Print”
 |
The second option is the “Send to Print” model. This removes WebSked from the workflow, which may be more desirable for independent print operations that want to handle budgeting decisions completely outside of Arc or for smaller newsrooms not using WebSked for planning.
 |
A sample workflow might look like this...
An article is written in Composer.
At some point after the article has been completed, an editor clicks the “send to print” button in Composer, which fires an integration that sends that individual article to the print CMS.
Within the print CMS, choices can be made about the placement of the article within the print layout.
If changes are made to the article after they have been sent to print, an update may be sent through the same “send to print” button in Composer. This will most likely create a new branch of that article within the print CMS and allow you accept or reject that new version, but this may vary depending on your print CMS system.
* The publishing of the article online is a completely separate process and the published state of the article will not matter when sending to print *
When to use this model
If your newsroom is smaller or does not produce a lot of content.
Independent copy desks, empowered to make pagination decisions.
Newsrooms with only a single print product
Model 3 - “Feed”
 |
The final option is the “Feed” model. This model automatically creates articles within the print CMS, then uses certain actions to sever the connection between the article in Arc and its counterpart in the print CMS. It can use the same actions as either of the two models above.
 |
A sample workflow might look like this...
An article is written in Composer, and a copy is created in the print CMS simultaneously. Rules can be set to feed only certain content based on things like section or ownership of the article.
Edits to the article in Composer are reflected in the print CMS.
There are two options now for how the connection with the print CMS is severed:
If changes are made to the article after the connection has been severed, an update may be sent through the same “send to print” button in Composer. This will most likely create a new branch of that article within the print CMS and allow you to accept or reject that new version, but this may vary depending on your print CMS system.
Note
The process of publishing the article online is completely separate, and the article's published state does not matter when pitching or sending it to print.
When to use this model
If you use most/all of your content in your print product(s).
If your copy desk works almost entirely in the print CMS they are empowered to make all placement/pagination decisions.
Editing for print
Now let’s talk briefly about the last question on the list - where to make edits to your print product. Arc does not have the ability to branch or create a specific version of the article just for print, so you can choose do one of the following...
Editing within the print CMS
This means that you are creating your article for the web, without the size or content restrictions of print, then sending that version over to your copy desk to modify and fit into the print product. This is the most common method.
Makes sense if...
Your copy desk is empowered to change articles to fit better in the print product.
The changes you make in the print product are NOT returning to the online versions of the articles.
Combination of editing in Composer and Print CMS
We do have some ways of making comments inside the body of the article (through the “internal notes”) as well as through the Publications, which could be passed across to the print system to give instructions to your print desk. The editing action would still happen in the print CMS.
Makes sense if...
Your reporters/desk editors have more input as to how the article should appear in print.
You want a closer match between print and web articles.
Matching print and web
Some organizations have decided that if an article can be told in 500 words in the print product, then maybe it doesn’t need to be 1000 words online and that additional effort should be put towards creating more articles and more URLs to drive more traffic.
Makes sense if...
You have a strong sense of the length that is required to tell the story in each article.
You feel that writing longer on web, even if there are no physical restraints, is not a good use of your reporters’ time.