[scribus-dev] Editable Master Pages

["Christoph Schäfer"]

Salut Louis,

Please calm down. There's absolutely no reason for personal attacks, really. 

We're not here for fighting. 

Please note that for some unknown reason I don't receive the 

mails to the list, only the digest, and trying to find needles in a haystack, i.e. real 

postings hidden between endless quotes, quotes in quotes, and quotes in quotes in quotes is 

no fun if you just see the black and white display with no highlighting. Thanks to Alex we 

now have the Wiki page, which made it a bit easier to follow some thoughts and 

reasonings.

In a sense you're right: I didn't listen. I tried to, but there was too much 

noise, read: quotations. This is like a dozen or more people talking at the same time. If 

we could agree to cut the quotes down in the future, that would already help a lot to avoid 

misunderstandings. And please continue discussing here, your input is invaluable!

Now, 

let's use our time machine and travel back in time. While I'm not often on IRC these days, 

I do read mrscribe's logs. Questions about editable items on master pages pop up at least 

once a week, so there's obviously a problem that needs to be addressed. A while ago, Craig 

Bradney wrote to this list, that the problem will be fixed, once we know how. So I sat down 

and tried to write down a proposal with the particular issues of our users in mind. I 

looked at QXP and InDesign and found both approaches bad. QXP, as described by you, uses 

the "dumb" approach, which can cause a lot of confusion. InDesign, while the feature itself 

is well implemented, has serious usability issues. My basic thought was to keep the costs 

low in every respect: developer time, learning curve and working speed. So I looked at 

what's already there and works and then based my proposal on that. Unfortunately, the 

discussion seemed to drift away from the orginal problem, at least partially. So, due to 

the unreadable postings, I merely re-stated my original proposal, not because I wanted to 

stop the discussion (quite the contrary), but to get things back on track and to find a 

workable solution. The discussion so far has brought up many interesting thoughts and 

questions, but can we, please, discuss with less voluminous quotes? I refuse to read 

postings with 1% hidden new content and 99% quotes, in which I'd have to use a magnifier to 

find the real message. In such a case I won't even try to listen, because I can't hear. If 

this is stubborn, then so be it.

Now, back to the discussion:

> Well, for paragraph 

styles, the most common change is enriching text.
> Nothing to hurt. I agree however that 

changes to a MP could be far less
> trivial and thus it may not be advisable to have this 

Style+ I was thinking
> about. But before throwing the idea away, I would still consider it 

and
> give it a second thought. After all, it is up to the user to determine what
> he 

wants on the MP. He'll see right away if the change made is in
> contradiction with his own 

layout. So, in fact, I see no real problem to
> the Style approach.

What would that mean 

in terms of speed and the learning curve? Could you describe what the user would have to 

do, how many clicks/dialogs? In other words: what are the costs?

> Good question. It could 

well be an option. And if it isn't, I am still
> incline to think the Style+ way is 

fine.

Again, how would it work? Can you describe a theoretical step-by-step procedure 

(count the clicks and the dialogs)?

> Could be. We are precisely discussing the case. So 

far, I think we need
> more thoughts and case scenarios.

Maybe, but with my proposal I 

wanted to discuss a specific scenario (or some related scenarios). If we think of all use 

cases of master pages, we end up in a general debate, which might be interesting, but won't 

solve our users' urgent problems. And these problems need no scenarios. They're described 

every week on IRC and quite often on the ML.

> A context menu can be less bloated in a 

given context. We can strip it down
> in the MP context, for instance.

Right. What would 

you remove in that situation?

> It would be great to explain what works and what doesn't 

in the "insanely
> complex way" of ID.

I sent you and Andreas the relevant pages from the 

ID manual. Greg has the printed issue, as far as I know.

> Then, tell us why you think so. 

Other than that, it's only an opinion.


Well an opinion, humble or not, is just that: an 

opinion ;) What's the problem? Discussion is an exchange of opinions. 

If we want to 

discuss linked text frames on master pages, why not, but why should we do it in this 

context and why hidden in hundreds of quoted and unrelated lines? 

> This is again a 

demonstration of your difficulty to listen to what others
> have to say. There are tons of 

case scenarios where linking is important at
> MP level and where it does save lots of 

time. The importance of this will
> also increase as Scribus text handling capabilities get 

better. Text
> formatting for one thing could be done in one single "formatting" document
> 

(just like galleys used to be) and then this formatted text could be copied
> and pasted to 

an entirely structured and linked empty "layout" document.
> Being able to link text frame 

in the MP can save hours of work, depending
> on the complexity of the document. Catalogs, 

for one piece of work, with
> lots of text levels and formatting can be done in days 

instead of weeks.
> Having said that, you can of course maintain your "not so humble 

opinion".
> This is up to you, of course.

Again, what has this to do with the problem I 

tried to discuss with my proposal? I may be stupid, but I don't see a direct relationship 

except that both are related to master pages.

> To be honest, I think it is very harmful 

to the discussion to come up
> strongly with your "not so humble opinion" in a case where 

it is obvious
> you seem to miss some valuable information.

As already said, I may have 

missed something, because of the noise. Also, I don't say (and never said) you're wrong, 

just that it's not directly related. Having a feature as described by you would be great, 

but it's another topic. Perhaps you can show me the link I'm missing. That's what most 

people would call a discussion.

Finally, I made my proposal with the hope that our 

discussion would bring up something better, because I know the drawbacks, and you, Greg and 

Andreas have pointed to even more drawbacks. I still think the original approach was 

correct, namely asking for the costs in all possible aspects. Maybe we can add different 

categories of costs to the Wiki page: development time (can only be answered by the 

coders), usability 1 (working speed), usability 2 (learning curve) -- both may or may not 

be mutually exclusive --, flexibility/features (something that's easily available and 

understandable may mean a limitation for power users), consistency with other operations in 

Scribus (apart from the specific master page issue I raised, there are other dialogs that 

need an overhaul, but this is yet another topic), short-term gains and long-term costs, ie. 

how would a specific short-term solution get in the way of future enhancements and 

improvements? So far, the discussion has mostly covered the last two categories: where to 

draw the line, what features need to be available, what isn't required, should we abandon 

the concept of master pages altogether etc. I don't think the other categories have been 

part of the equitation enough, yet. One of the reasons for Apple's success is that UI 

designers determine what and how features are going to be implemented. From UI to code, not 

the other way around. Perhaps we can create UI workflows for all (and I mean all) 

suggestions that have been made so far, based on Alex's table. These could also include an 

approach that would mean abandoning of master pages altogether, even if we throw the draft 

overboard later. Just let's be curious where it will lead us. I'm sure some interesting 

questions will come up for each person that works on such a draft. It's probably better 

than discussing possible issues here and there without a focus. Let's be creative and 

discuss openly once we have some UI scenarios/solutions that can be tested against the 

categories. Why should we waste our time with useless infights? This is Scribus, after 

all.

Louis, please note that I send this reply with all respect, sympathy and admiration 

for you personally, as well as your achievements, experience and knowledge. I really think 

something went dead wrong here, due to communication issues. Hopefully, this outbreak was 

nothing but a tempest in teapot.

All the best,

Christoph



-- 
GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196