Cross Media Publishing.

October 22, 2006 2:14 PM

How do you easily cross publish to both print and web?

We're a small newspaper who publish using the Adobe Creative Suite on Windows. We want to quickly and easily republish that info (text and pictures) on the web. We'd also like to be able to publish additional info direct on our website (like a blog or listings). So this prompts two main questions:

What's the best software to this?

What's the best workflow to do this? or is going from print to web even the best way? Do we really NEED Microsoft Word to write stories in? Is there a way to write our stories in some web app and then export that text to Indesign?

We currently have a website that is falling apart due to shoddy coding by the owner's brother's daughter (built in php and mysql). We've finally manage to convince him that we need a professional solution, but we're at lost where to go. Our current workflow calls for us to export text from IndesignCS2 in RTF format, open that document in Microsoft Word and past it to our site via IE (and it HAS to be IE in order to keep the formatting) The pictures we have to resize and change the mode in photoshop before posting. So there's lots of grunt work which sucks up lots of staff time.

Small budget (of course!) and we're not not techies and don't have much tech support. We need a fairly simple, almost brain dead solution, off the shelf solution. It would be great if something could just suck in the Indesign files, with its text and graphics and repurpose it for the web automatically.

Are there off the shelf solutions that enable a small publication (with small budget, say around $1,000-$2,000) to easily cross publish their content in print and web? We definitely want to put our stories and photos into some sort of database.

Futher inquires and info can be direct to [e-mail]

posted by anonymous to Computers & Internet (15 answers total)

I believe InDesign allows you to export to XML. This wouldn't be an off the shelf solution, but it would be easy to create a simple PHP script which pulled out the data out of xml files and displayed it.
posted by null terminated at 2:35 PM on October 22, 2006

Yep, InDesign and Xml tags are your friends.

You have to put some thought into how you"tag" your files and older documents will have to be updated.

Here's an overview of how it works.
posted by jeremias at 3:03 PM on October 22, 2006

Most cross media publishing solutions need your organization, as a publisher, to adhere to fairly rigid design rules, that can be coded as markup elements for both print and Web presentations with acceptable quality. Unless you are creating "images" of print pages (such as PDF files, or actual .jpg files), you'll never get "perfect" fidelity between Web and print versions of your content. And even if you do simplify the problem by limiting your design elements to standards that can work in both formats (maximum size of pictures, font selections that are cross platform, smoothly degrading color pallette), your workflow is probably not going to be "push button" simple, since much of the navigation structure (links, dynamic elements, multi-media) that make a Web site engaging, "professional" and profitable are not generated directly out of print markup.

For a budget as small as $2,000, I think an end to end cross media publishing solution is out of the question, even if your design requirements are trivial. The XML based approached is currently The Right Way to Think About the Problem, but you'll spend many hours of custom programming time implementing and testing it, even if your design issues are intentionally simplified as much as possible. Perhaps you could survey other newspapers for descriptions about how they handle the issue, although I suspect that most metropolitan dailies are spending many, many times your budget on cross media publishing systems, and still doing a fair amount of custom work and programming to bring their print content to the Web in timely fashion.
posted by paulsc at 3:05 PM on October 22, 2006

I did online production for my college's student newspaper last year and I tried using a content management system to organize everything. Mambo/Joomla worked at first, but as time went on, it was becoming obvious that it was too slow and complicated. The currently online production manager has moved everything over to WordPress, which has worked great.

If you'd like to see the current website, it's at www.cordweekly.com - it's not as fancy as some other newspaper sites, but it works and it's clean. Updating on the articles is done by simple cut and paste into the text fields.
posted by perpetualstroll at 4:09 PM on October 22, 2006

Just posting to say paulsc is right. This stuff is not easy at all, and there's no out-of-the-box solution.

Just the line "We definitely want to put our stories and photos into some sort of database." is worth a whole AskMe question by itself.

What you should really do is change the workflow so that journos put everything into a database, then the people publishing your paper get it out again in two different forms, once for the print and once for the web version.

But that's a huge, robust, frequently-backed-up database you're talking about, or you're risking major screwups. And a fully-featured database too, because you're going to want to store photos with metadata, and store them in such a way that the original can be repurposed for different resolutions, and indeed, can be searched by the metadata and re-used for different stories.
posted by AmbroseChapel at 4:14 PM on October 22, 2006

You're asking for a very expensive and complicated thing to be made very simple. I don't think you're going to get what you're looking for.

(Actually, I don't even think what you're looking for is ideal, for any newspaper. There's definitely a notion out there that because they're all words, you can republish newspaper text as web text and it's just the same -- it's all content, after all, right? I think this is as if early TV types just played a radio show and put up some static images in front.

Web and print publishing are two different things and should be treated as such. Headlines, for instance, are often written to a very tight space and carry less meaning than they would if written without space constraints. Same goes for stories.)

I'd suggest getting an off-the-shelf CMS such as movable type, and looking into XML import for it. You can tie these in with a gallery app (such as gallery2) and build fairly complex workflows. I wouldn't recommend trying to automate it all, for the reasons given above, but if you have one guy importing the XML and editing as he goes, it could work quite well.
posted by bonaldi at 4:16 PM on October 22, 2006

What I used to do when I was online editor of my college newspaper was open up individual page proofs in InDesign, then copy/paste the story/headline/subhead/cutline text from there into a CollegePublisher Web form. (CollegePublisher being the newspaper's online content management system/hosting provider.) We did it that way because all pages were copy edited in InDesign, so the original Microsoft Word documents (the format stories were submitted in) were outdated once the text had been imported into InDesign and edited.

If there was any special formatting in the InDesign document, that would be stripped by the copy/paste to a plain-text Web form, so I'd have to go back and reformat all bold and italic text, plus URLs, by hand. The online editor also was responsible for creating "saved for Web" versions of all images, within size/resolution/color encoding constraints provided by the Web site's template, as well as creating Web versions of the full-issue PDF.

This system normally took one person 4-5 hours per issue, three issues a week. Not that bad, really—not even a full-time position. You could just hire someone to do this sort of thing part-time.
posted by limeonaire at 4:39 PM on October 22, 2006

Also, a question to think about (since you, being anonymous, can't answer it here): Does your office have one central server that all work is saved to (that's backed up on a regular basis)? If not, that should be your first concern—if you're going to have someone handle your Web content, all your print content is going to need to be in one place so they can easily and quickly access it.

And as for an alternative to opening photos up in Photoshop one by one and reformatting them for the Web, there really isn't one. Your options are to either have the photo editor create these when they edit the photos for print and save them in a prespecified location or have a Web editor edit them as part of their regular duties—either way, someone has to edit them.
posted by limeonaire at 4:46 PM on October 22, 2006

An addition to AmbroseChapel's comments: XML data can not only be pulled from InDesign, but can be pushed into a document. Using an ODBC compatible database, you should be able to pull content into InDesign directly from the same database you're using to push data out to the web. This gives you a single point of entry for both forms of media.

I know of at least two newspapers that do this for their classifieds and it's wonderful. That being said, the two newspapers use expensive third-party solutions to automate the layout side once the content has been brought into InDesign.
posted by fatbobsmith at 4:51 PM on October 22, 2006

To answer your overall workflow question: the complexities of print layout generally make it easier to move print content onto the web than web content into print. For example, if you write your stories in a web-based CMS, then try to import that content into InDesign, you might discover that your headline is too long for the layout. In addition, fine-tuning article length tends to be one of the unique headaches of newspaper layout, in my experience, so it makes more sense to get the length right in InDesign then export that to the website rather than the other way around.

Also, the only sane way to run a newspaper website is by storing content in a database, so given the print->web workflow described above, your question becomes: how do I easily insert insert content from InDesign into a database? As others have said, you're going to want to do this via xml (exporting it from InDesign). Happily, InDesign provides very good xml export support; Adobe describes the basics of how to do that here, but the short story is that you:

1. Select a mapping of styles to elements... in other words, tell InDesign that the byline style should generate a <byline> element. This only needs to be done once... your settings can be saved to a file.
2. Use InDesign's XML structure pane to select the elements that you want to export to XML.
3. Export to an XML file.
4. Use an XSLT processor to transform the XML file to an (x)html file (a simple command line operation that is given the name of an input file and writes the output to a new file).

For example, if you have a document that contains a story that you want to make into a web page, and that story consists of a text element for the headline, a text element for the body text (which includes the author's byline), an image, and a text element for the image caption, the XML that you'd tell InDesign to produce might look something like:

<root>
  <fullstory>
    <headline>Man Bites Dog</headline>
    <bodytext>
      <byline>Anonymous</byline>
      <p>This is the first paragraph of a <em>Pulitzer-Prize-winning</em> article.</p>
      <p>This is the second paragraph.</p>
  </fullstory>
</root>

Generating this xml from an InDesign file can't be automated entirely, but once you know what you're doing, it should be doable for a document containing 10 or so stories in less than 10 minutes. Once you've got the xml, inserting it into the database (and thus the website) programmatically using a script is instant.

Regardless, the take-away message here is that the peculiarities of print layout make it difficult to write a universal software package to cross publish print content to the web, and whatever solution you use will have to be partially customized. No matter what, you'll likely need a techie to help you create a partially customized solution... you can't just buy off-the-shelf software for it. The good news is that InDesign has solid xml support, which means that creating such a solution shouldn't particularly difficult, and I'd guess should to be doable within your budget. I don't know much about the freelance markets for work like this, but try mefi jobs or your local university. Feel free to email if you have any questions.
posted by gsteff at 5:14 PM on October 22, 2006

When I started writing my previous comment, I was going to reccomend XSLT, before I changed my mind, so ignore step four above.

Reading through the other comments, going from the database->InDesign is doable too, as some have suggested, as long as you don't need to tweak the content of your articles themselves to meet your layout needs. My experience with small publications is that this is never the case, and everyone screws with headline lengths and paragraphs to make things look pretty. If your layout system is good enough that you rarely need to adjust content for layout needs, then the database->InDesign route would probably be preferrable.
posted by gsteff at 5:21 PM on October 22, 2006

followup from anonymous:

Thanks for all the responses and for pointing me towards InDesign's XML features. I had played with Quark's XML ability back in version 5 and had come away disilluisoned, but it looks like InDesign has made a lot of headway in this.


But on reading all the responses I realize that maybe we're thinking too far ahead. Simply put it's certain that the Internet has become and will continue to be a huge force for publishing. That's fine, but like most newspapers we've been twittling our thumbs while change has happened. Now that we've got the 'Net religion, we want to think ahead, to not lock our content down to a particular media. After all, if the web allows more space, then why limit ourselves, why shouldn't a writer do more than just a page or two columns worth or whatever is dictated by the print space. I'm not talking about writing that just dribbles on because there's room, but being able to include the whole interview with so and so, and really get into the details of a piece without having to cut somewhat important stuff just 'cause there's "only two columns to fill"

So why not start with publishing for the net first?

But maybe we're trying to fly before we can crawl.

Yes, we have a central Windows server, where all our images and text are stored, plus a few old macs.

paulsc: We're not looking for perfect fidelity between the web and print. We're hoping to just be able to have the text and photos in a database (with tags) and then be able to shoot it onto the web or print. We realize tweaking will need to be done, mostly for print. And yes, I've talked with several friends at the big daily and they have the hugely expensive bells and whistles.

odinsdream: Anonymous due to politics.

perpetualstroll: We want to avoid cutting and pasting and reformatting text that's already been formatted. We view it as a waste of time and redundant work. We hate that :)

fatbobsmith: Could you email or tell me here the links to those papers you mention?

gsteff: Why is going from database to Indesign not good if you need to tweak the content. Once it is in InDesign, what difference does it make?
posted by jessamyn at 7:21 PM on October 22, 2006

Going from the database->InDesign can be problematic because any changes you discover that the print layout requires will then have to updated in the database. For example, if you discover that the article as added to the databse is too long after attempting to lay it out, you'll have to update the db, not just the InDesign file. That may not seem like a big deal, but if you have 10 articles in an issue, and each one needs to be lengthened or shortened by a line or two to make it meet your layout demands, it will be a significant drain on productivity. Another example is modifying headlines so that they fit into the necessary number of lines. If your layout is inflexible with regard to content, you won't know what the final form of the content is until you do the print layout in InDesign, which makes it rather silly to add it to the database before you do that.

Being able to publish content exclusively online is wonderful if you can do it. But online news outlets aren't nearly as profitable as print ones. If you're in a position to be able to fund the creation of lots of content for your website that won't go into print, power to you, it's both technically and editorially preferrable.
posted by gsteff at 7:36 PM on October 22, 2006

To be clear, I'm assuming that you want the articles on the website to be identical to their print counterparts. You don't have to do that, but it seems kinda weird not to.
posted by gsteff at 7:38 PM on October 22, 2006

My company is in the process of doing something very similar. We are creating training that is delivered both via. the internet and via. print. Our solution is end-to-end XML. We're hiring a contractor with experience doing this, (XML and XSL transforms for print and web) for 3 months @ $150-$200 and hour. For those of you counting, that's up to $96,000.

The first month will be developing everything, the second month will be entering in all of the old data, and the third month will be transitioning the 8 man team. In the end, we still don't get a website, but we do get all of the wonderful XML to pull into our HTML or Flash interface.



This "big picture" isn't something you can do professionally and afford it (I'm assuming $100,000 + $[cost of website] would be too much for a small newspaper). You could hire a student HTML/XML wiz, pay them a decent salary + benefits, and get the same thing, but it would take up to a year to get everything working together.
posted by hatsix at 9:23 PM on October 22, 2006 [2 favorites]