I'm in the process of planning a centralization of our workflow, so that a single story gets purposed multiple ways, and I was hoping to get some discussion going on this topic, perhaps sharing some brain cells and previous experiences with others on the group.
First, the idea: Currently we are copying and pasting from our news system (NewsEditPro) or InDesign (depending on which editor is working that day) into the Drupal system. It's not very effective obviously, but it's what we were forced to do for years using TownNews, and we're just now beginning to expand our sites.
I want to be able to take the original document in NewsEditPro format, and find a way to automate the creation of a story node on our site using this file, while still being able to take that file to InDesign.
Now for the problems: We're doing this on a shoestring budget. We have no money available to purchase software like iQue, so turning the text format of NewsEditPro into an XML document seems unlikely, as does purchasing 13 site licenses for InCopy.
We know we're going to need to parse that data somehow, but we aren't sure as yet how we can do that since NewsEditPro doesn't give us any metadata capability, so we can't tag a byline as a byline, a title as a title, etc...
The biggest problem I can encounter is following a good philosophical approach to this. I could export XML from InDesign, but that leaves us with a scenario where anything we're not putting on a page first, can't really be automated for the web. It seems a little backwards to me.
We want to use a centralized system to better automate the website, but also to keep news flowing throughout the day, even though we don't product pages until the late evening. So I'm looking at options to create documents that can be turned into XML, uploaded to our site via a hotfolder script, parsed by a FeedAPI parser, and still sit in a queue to be placed on an InDesign page that evening.
I'm curious as to what other papers that are further along in this process than we are use to centralize their workflow, and the problems you may have encountered in doing it.
Comments
Similar problem
We have a similar problem.
I'm not a Mediaspan expert, so I assume that NewsEditPro is the older, dumber version of Mediaspan's software that doesn't put the data into a database, and doesn't include Transporter, so you can't script it to kick out XML?
That's what we have in several of our small markets, and under our current financial circumstances I can't advocate spending $130K for new Macintoshes, upgrades from Quark to InDesign, InCopy, etc., that would be necessary to get onto a current and reasonably useful version of Mediaspan/Baseview at just one newspaper.
As a result we're contemplating just going to cut/paste in those markets.
The interesting thing is that in Conway, Ark., where we DO have a new version of Mediaspan, the staff has chosen to cut/paste into Drupal rather than export as XML because it's faster, more reliable, doesn't require them to rethink the way they put stories on pages, gives them instant Web results, makes it easier to attach photos and multimedia objects, properly assign taxonomy terms, etc.
The editors make stories "live" on the Web whenever they're ready for publication, NOT after they go to print.
I'm in St. Augustine right now for another install and we'll see how that goes. We're telling everyone we're not dictating workflow; that's something that should be worked out by the people who do it. If it turns out they prefer to cut/paste or prefer to push XML, it's their choice.
Another option we're considering is moving some/all of our newsrooms OFF Mediaspan and DTI systems and onto NewsEngin, which is a Web-based commercial newsroom CMS that has drag/drop integration with InDesign. We have it working nicely with Drupal in Topeka, where it feeds NITF into DTI for print purposes, but posts directly into Drupal for the Web. The advantage NewsEngin has is it's software as a service -- based on the Amazon EC2 cloud, priced at $20 per seat per month, no capital required.
I know some people have rigged drag/drop from Drupal into InDesign, which would make it possible to use Drupal as a print CMS, but I have no idea what's involved. Our tech resources are rather siloed and incapable of seeing that as a possibility.
I think we may be on the path
I think we may be on the path to a workable solution, but it's far from a perfect one. It begins with the creation of a custom parser which will read our NewsEditPro files and create story nodes from them on our Drupal site.
We will be using NewsEditPro's notes modes to create a set of faux-meta data for each story. Title, Byline 1, Byline 2, taxonomy, and node weight, for example. A hot folder will be set up to upload those stories via sftp to our parser can then turn them into nodes from cron. The hotfolder will then move the stories to a folder that will act as the "queue" for our editorial team to begin layout.
Since notes mode doesn't get placed into InDesign when using the plugin for NewsEditPro, our editors can then flow the stories on to pages when they are ready.
It means a little extra work (to the tune of 15 seconds or so) when creating the stories in NewsEditPro, but it will act as a sort of centralized system where a single file is purposed both for web and print.
Obviously this is a slightly backwards solution, but in this economy, I think many newspaper IT professionals are being forced to bandaid solutions together rather than upgrade antiquated systems.
While it's no where near the perfect solution, my hope is that for a small investment in creating the parser, we can get 2-3 more years worth of life out of NewsEditPro which could put us in a better position for the InCopy/CS4 suite upgrades we'd liek to have to be on the right path for the future.
Hmmmm
I may want to take a look at what you're doing in January, when we get to working on the Brainerd Dispatch, which has an older version of Baseview. That's where we're thinking of going the cut/paste route, at least until we have a better sense of how much work it actually entails, and whether the problem is worth solving.
We did something similar to what you describe in 1994 at the Star Tribune, which had an old Atex system. All we really needed was a title, which we had reporters create using the Atex "co" (comment) markup. The stories all fed into a Web-based queue that online producers monitored, and a Web interface allowed for categorization and story weight to be added. That's fine if you have 10 people on your Web producer staff, but it's not going to work in 2009.
Future Workflow
Just a thought, but could the future of media be in reversing the work flow?
Sources enter content with qualities into a web based CMS. The finished raw content is then passed to the respective design teams that polish the turd and publish it for a specific format, (print, web, audio, video, mobile, etc.).
Those who will not reason, are bigots.
Those who can not, are fools.
Those who dare not, are slaves. - Lord Byron
The idea of working web to
The idea of working web to print has it's merits... until the first time your Internet provider blows a router upstream and you are telling your publisher that you're going to be very late producing a paper because everyone is driving an hour to the next paper down the road with working net access.
Well, you get the idea anyway. Until our grid becomes smarter, the idea of producing web content all day and using that to flow pages that evening is pretty risky.
Internal Drupal
I've long believed that a complete Web-based publishing system for newspapers would have separate internal and external systems that communicate through some sort of publish/subscribe system.
Mr. Yelvington, you are
Mr. Yelvington, you are correct in that statement.
I have begun working on a project to help centralize the workflow and repurpose the data. The idea will use a combination of internal/external service and a custom built InDesign plugin (as soon as I can find a qualified developer).
I intend to set up a locally hosted Drupal installation here in the office that will act as our front end news system. I believe I can do this with CCK and create field for editorial notes, as well as use the Revision and Workflow modules to create something fairly elegant that will allow reporters to file stories on Drupal, and editors to manage that workflow and the revisions.
When a story is complete, it will be placed into one of two nodequeues... "Ready for Web" and "Ready for Print", or something similar. I will build a custom feed for these queues, and the "Ready for Web" feed will be read by the remote web server and the nodes will be automatically created, complete with assets like photos, videos, byline, copy, etc...
The InDesign plugin will make those stories available locally once they are in the "Ready for Print" queue. The idea behind the plugin is to translate the RSS feed into an XML useable by InDesign. They would be flowed onto the page using a master stylesheet, pretty much the way InDesign is expected to.
I am not very far along in the process as yet. I need to set up a local test server running apache, mysql, and drupal, and at least begin testing feeding data to a remote web server running Drupal. Once I have that done, I will look for a developer who can create InDesign plugins for CS2, CS3, and CS4 and assist me in setting up the master stylesheets needed by InDesign.
The end goal is data neutrality and hardware/software independence. If our Internet connection goes down for eight hours, I don't want to not be able to produce a daily paper, hence the local server acting as a sort of gateway. I also don't want to be tied to expensive software upgrades that may potentially force expensive hardware upgrades just to keep current with Adobe or MediaSpan.
My goal is to create a browser based front end system that can feed the data to multiple other system quickly and easily.
If anyone thinks of anything I haven't yet, or can see any pitfalls in the plan, feel free to chime in.
Keeping an eye on this thread
I definitely want to keep an eye on this thread and see what possibilities develop or are explored. Today, one of the tech guys in the corporate office (on the other side of the country from us) asked me how I envisioned our newspaper staff getting stories into the the new Drupal/ProsePoint site I'm building.
"Copy and paste?" I said.
He said, "Oh, no, you'll be able to export out of Baseview in XML and use that to put stories online."
Someone will have to walk me through that process first, since I'll be the one training the rest of the staff.
I know our print system is several years behind in technology -- we're using InDesign CS, and I have no idea what version of NewsEditPro we have. (I'll take a look tomorrow; I'm at home at the moment.) I want to keep the website side of things as simple as possible for our staff -- so if they find that they prefer copy-and-paste, I'm more than willing to let them have that option. (Especially since one of the reasons for moving our website access in-house was so they'd be able to post/update stories online as quickly as possible in the event of breaking news.)
But I also need to look at what the corporate office is offering. I'm hoping they'll give me a chance to experiment with their XML plan soon, so I can get a feel for how it will work.
Katrina
Site builder, writer, trainer, graphic designer