Draft of end-to-end publishing solution: Difference between revisions
Donnellymp (talk | contribs) No edit summary |
Donnellymp (talk | contribs) No edit summary |
||
| Line 31: | Line 31: | ||
1. We get product information (on paper | 1. We get product information (on paper | ||
) from merchandisers, i.e., those who buy the products. These sheets include photos, product id numbers, data like color, sizing, etc., buyer name, etc. | ) from merchandisers, i.e., those who buy the products. These sheets include photos, product id numbers, data like color, sizing, etc., buyer name, etc. | ||
2. The copywriters (in a different department) take that information and (sometimes using old copy as quasi-templates) create different copy for that sku for different audiences and locations: best buys, insection, dealer, label, etc. This is all written in Word and a copy is saved to the server in a folder. | 2. The copywriters (in a different department) take that information and (sometimes using old copy as quasi-templates) create different copy for that sku for different audiences and locations: best buys, insection, dealer, label, etc. This is all written in Word and a copy is saved to the server in a folder. | ||
3. Then the Word documents are printed out, put in folders, and routed to fact checkers and proofreaders | 3. Then the Word documents are printed out, put in folders, and routed to fact checkers and proofreaders | ||
4. Meanwhile, designers are laying out (in InDesign) pages with product images and placeholders for copy | 4. Meanwhile, designers are laying out (in InDesign) pages with product images and placeholders for copy | ||
5. The copy sheets are then brought back to the original copywriter, who keys in the changes, then marks the finished docs with the color green and writes in each "OK TO PLACE" | 5. The copy sheets are then brought back to the original copywriter, who keys in the changes, then marks the finished docs with the color green and writes in each "OK TO PLACE" | ||
6. The designers periodically check the server for "green" files and flow them into the placeholders (this is where some thought that giving InCopy-like products to copywriters would shorten the process) | 6. The designers periodically check the server for "green" files and flow them into the placeholders (this is where some thought that giving InCopy-like products to copywriters would shorten the process) | ||
7. Sometimes the text it too long or too short, so the designer goes back to the copywriters for cuts | 7. Sometimes the text it too long or too short, so the designer goes back to the copywriters for cuts | ||
8. When the page proofs are done (text/images and other assets like bursts/promotions), they are printed out and routed in clear plastic folders so they can be proofed on paper by 4-5 people | 8. When the page proofs are done (text/images and other assets like bursts/promotions), they are printed out and routed in clear plastic folders so they can be proofed on paper by 4-5 people | ||
9. Once they proofs are done, the designers make the changes | 9. Once they proofs are done, the designers make the changes | ||
Revision as of 22:08, 31 January 2007
As a start it would be good if users described their use cases, e.g. Matt Donnelly:
I work for a wholesale pet supply company that publishes print catalogs in addition to several websites. We have no workflow, no content management system (CMS), no wikis, and the editors use Word while the designers use InDesign. We're a growing company that struggles to communicate well with each other as well as with our customers.
I'd think it would be terrific to find some way to glue together Scribus, OpenOffice, Gimp, a CMS app, a wiki, etc. to create an end-to-end publishing solution that takes companies through the entire catalog creation lifecycle and gets new info on/from the websites fast. Fold in Web 2.0, and it's a goal.
The closest we've come is the idea of using InCopy for editorial and InDesign for layout. This would at least get editors and designers on the same (virtual) page. But it doesn't solve the problem of effectively sharing information, workflow, modular content that can be reused across catalogs/websites, etc. Microsoft is trying to do some of this with SharePoint/Office integration...
Use Case #1 (Matt Donnelly)
The idea is to get all the information in one place and massaged as quickly and efficiently as possible. There would be workflow engines/CMS in the process to make sure materials are routed properly, quickly, and efficiently. This would also identify bottlenecks, send alerts, etc.
Now our system works this way:
1. We get product information (on paper ) from merchandisers, i.e., those who buy the products. These sheets include photos, product id numbers, data like color, sizing, etc., buyer name, etc.
2. The copywriters (in a different department) take that information and (sometimes using old copy as quasi-templates) create different copy for that sku for different audiences and locations: best buys, insection, dealer, label, etc. This is all written in Word and a copy is saved to the server in a folder.
3. Then the Word documents are printed out, put in folders, and routed to fact checkers and proofreaders
4. Meanwhile, designers are laying out (in InDesign) pages with product images and placeholders for copy
5. The copy sheets are then brought back to the original copywriter, who keys in the changes, then marks the finished docs with the color green and writes in each "OK TO PLACE"
6. The designers periodically check the server for "green" files and flow them into the placeholders (this is where some thought that giving InCopy-like products to copywriters would shorten the process)
7. Sometimes the text it too long or too short, so the designer goes back to the copywriters for cuts
8. When the page proofs are done (text/images and other assets like bursts/promotions), they are printed out and routed in clear plastic folders so they can be proofed on paper by 4-5 people
9. Once they proofs are done, the designers make the changes
This is a rough sketch. Some obvious needs come out of this:
1. Tracking documents throughout their lifecycle (from docs to text on a page, etc.) 2. Making sure all assets for each product stay with it 3. Finding a way (a la InCopy and InDesign) for editors to edit copy even in layout, while designers stick to design 4. A workflow tool to track edits, comments, etc.
More could be said, but that's the gist ;-)
--Matt from Boston
I propose a separation in four sections:
1. CMS / Database
Do we want to choose one system, eg. Exist, MySql, Zope or whatever or do we want to be able to use different CMS / database systems? Database connections are already well normed, but CMS APIs would need some work to adapt.
What do we want to store in the CMS? Just text and images? Or do we also want workflow support? What about versioning?
2. Scribus
No real choice here! :-)
The work would be to allow external linking to text and maybe provide a mechanism to pull content from the CMS automatically.
Another nice idea would be if Scribus could save its docs, templates, scrapbook and styles in an XML database like Exist.
3. Content Editors
Plain text, OOo, LyX, ...
Scribus already supports import from plain text, html, OOo and others. It would be nice to have an import plugin for XML+CSS, with an option to substitute CSS fonts and colors automatically.
4. Image Editors
InkScape, Gimp, Cinepaint, Xara, ...
Once those *all* support CMYK it's a mere question of linking those apps to the CMS.