[Scribus] Ideas on collaboration

[Louis Desjardins]

>>>>>>It has been mentioned before that multiple editing of DTP files 
>>>>>>is not a good idea.
>>>>
>>>>I don't agree.
>>
>>Don't agree either. We need a way to achieve this, sooner or later.
>>
>>I recall a discussion on that specific issue months ago. For one 
>>thing, I was pointing out the need for database relationship for 
>>formatting on the fly and creating layouts. In some workflow, there 
>>simply isn't any other efficient way to produce a document. Fast.
>
>Well, somehow that's what I meant when I wrote about multiple 
>editing of DTP files as a bad idea. In my view, and your comments 
>further down seem to support that view, separation of layout and 
>content is essential.

Absolutely. This is one key issue. Nonetheless, this calls for one 
nuance. When we get to the last touch of a nice piece of 
layout/typography, intense collaboration between the two teams 
(content/laytout) is compulsory. For example, a title could be too 
long from the layout perspective... at the same time it reflects 
exactly the author's idea... With good collaborative work, this can 
be worked out - it has to! - and will only be if everyone listens to 
the other.

On the "DTP file being edited", the basic idea is to let teams 
organize their workflow the way they want, thus provide them with 
tools designed for this. As I see it, it's more like multiusers 
having access to a database. One specific file cannot be edited 
simultaneously by two co-workers is the basic rule. Other than that, 
security levels could be applied so some part of the page can/cannot 
be edited and or workflow specifications (agreed by the people 
working on that project) could be established.

This way, many people could work on the same document, to accelerate 
the production process. In some areas, this is definitely a need: 
newspapers, ad flyers, catalogs, to name a few.

>If you look at how company publications are sometimes patched up, 
>moving through x departments for approval, including all the 
>commenting tools, bitmaps moved around, a third and fourth font 
>added ..., you know what I mean. In the end you have a poorly 
>formatted *.doc file on your desk/computer with pictures from the 
>website that (might) look good on screen. If you tell the 
>$OFFICE_SUITE users, that despite all their work, the file can't be 
>printed, they will be at least disappointed, sometimes even angry.

I agree. We could say this is where starts the uncollaborative work 
in workgroups! The workaround is, simply put, education and workflow 
awareness. What people have to understand is publishing is a 
complicated task. The computers are only a powerful tool to help get 
the job done. Computers don't do the job! Humans do. The workflow is 
there to help humans accomplish that in the most efficient possible 
way. If people don't agree on the workflow, then it's useless!

>My idea was to let the content remain editable, but not the layout. 
>It's enough to let different people work on a text after or before 
>the layout is defined (depends on the customers). The reason for my 
>text frame approach was based on my fictious catalogue: the authors 
>know how much text can be submitted to "their" text frames. But they 
>can submit changes until the last minute before the plates will be 
>produced. The (future) scribus user will only have to update the 
>_content_ of the text frame, check hyphenation and finally produce 
>the PDF.

Actually, if content and layout are separated (which is good), then I 
guess it would only be reasonnable to allow separate editing 
authorization for each. Works on both sides imo. And we cannot afford 
to let the proofreaders aside of the workflow!

(snip)

>>Well, in my view, if we are overworked, the last we want is a badly 
>>pre-formatted text. :)
>
>I'm sure you won't mind if I say: 100% agreed ;-)

:)

(snip)

>>Going back and forth, up and down the hill, can puzzle any 
>>production team and make professionals look like pee-wees: a sure 
>>way to miss something important at some level and make *the* 
>>mistake that will force a reprint. And remember, lots of clients 
>>don't have the money for decent proofreading, but they sure have 
>>the money to reprint if anything goes wrong. Now, just how much 
>>costs proofreading? and a reprint?
>
>Gorgeous! Thank You! That's real life! But again, submitting text to 
>a database and to let the DTP people simply update the files and 
>therefore the _frames_ before producing the plates could make the 
>whole process a lot easier.

Agree! The database approach is very interesting.

Cheers!

Louis