[scribus-dev] Editable Master Pages
christoph-schaefer at gmx.de
Sat Aug 9 17:18:59 CEST 2008
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
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!
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
> give it a second thought. After all, it is up to the user to determine what
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
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
> 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
> 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
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,
GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
More information about the scribus-dev