Draft of end-to-end publishing solution: Difference between revisions
No edit summary |
(call for use cases and proposal of sections) |
||
Line 1: | Line 1: | ||
[[Category:Scribus_development]] | [[Category:Scribus_development]] | ||
As a start it would be good if users described their use cases, e.g. Matt Donelly: | |||
---- | |||
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... | |||
---- | |||
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. |
Revision as of 16:21, 31 January 2007
As a start it would be good if users described their use cases, e.g. Matt Donelly:
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...
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.