[scribus-dev] Editable Master Pages

[Louis Desjardins]

2008/7/31 "Christoph Schäfer" <christoph-schaefer at gmx.de>

> Hi all,
>
> In reply to Louis' and Greg's recent postings:
>
> Louis:
>
> "What I am missing in this discussion is the many non-said things about
> Master Pages. We seem to assume too many things from our experience without
> naming them. To me, the first steps towards a solution to any issue, is to
> identify clearly the problem. I think this still needs to be done. So,
> before going into the "solution mode" we should establish clearly what the
> problem is, make a list of what we like in the current way and what we
> dislike or find unefficient."
>
> I hate do disagree, but the issue has been discussed for years now, on the
> ML, on the bugtracker and on IRC. Just read the logs or the archives. So
> there's no need to start from scratch. If anyone wants know what people try
> to do with master pages and why they want this feature, it can be easily
> searched for. I wrote that text as a reaction to Craig Bradney's comment
> that we should be clear on HOW to implement it.
>
> People want to _edit_ items on a page that are visible but placed on the
> master page. Use cases: last minute changes, quick changes like removing the
> page number for a certain page without having to create a new master page.
> Users want to move items between master pages and normal pages. Users want
> to create a basic item that shows small changes on different pages, for
> instance a coloured frame that has different text content etc. There are
> workarounds for some of these uses cases, of course, but a workaround is an
> idicator that something's missing. We have seen related questions over and
> over again. Why should we now start discussing anew?


>
> Moreover, we kann dream up 1000 use cases, but we still can be sure our
> users will come up with at least 100 other ones we didn't contemplate. The
> purpose of my draft from the user perspective was to set no limits as to
> what a user can do, and I really think the approach is flexible enough,
> quite fast from a usability perspective, and also easy to use (in contrast
> to QXP and ID).
>
> Louis:
>
> "In other words, I respectfully think your proposal arrives too early in
> the
> process."
>
> No, it's rather late ;)
>
> Louis:
>
> "What I would propose instead, if I had the time and if I felt this issue
> to
> be a high priority would be to set a Google Doc such as a calc. sheet so we
> have a rows and columns document and I would state what we want to achieve
> in the rows and how it's implemented or if it is at all possible in current
> Scribus and in ID and QXP, and maybe another one (I can't think of now), in
> the columns. There could be a comment field for users and one for the
> coders
> so the various points of view are expressed. Of course, this table could be
> organized in any convenient manner so the ideas remain clears. What I say
> here is only a suggestion."
>
> Sounds quite complicated to me. We can discuss the issues here and then add
> to the bugtracker once they are resolved. Wouldn't that be easier?


A table seems to me more convenient than flowing text, for this kind of
discussion.

>
>
> Louis:
>
> "As I mentionned, it's been over
> 20 years we have DTP apps and the Master Pages concept is still a
> work-in-progress. "
>
> I'd say it's a rather mature concept.



> "This means it's a fairly complex issue and it also means
> that the way of implementing this is not as obvious as it seems."
>
> Hmm, what do you mean exactly?


I will go over this rather quickly. I can complete later if needed.

There are actually 3 proposals out there.

Scribus' is tight and allows no change outside the Edit Master Pages.

Quark allows any changes to the Master Page once it is applied to any page
and vice versa. What people miss here cruelly is a way to find out what
object came from the Master Page and what didn't. And when they make a
change on the wrong "page" (ie, the Document Page instead of the Master
Page) not only those changes will not apply to all related pages but that
very page they modified by error will not be affected by the Master Page
changes while the user expect the opposite. Once the link to the Master Page
is broken, there is no way back. Also, linking text boxes from within a
Master Page is possible but the procedure is not obvious and for this reason
many people prefer to do this by hand...

ID tried to solve the Quark dilemma and offers the possibility of making the
Master Page and the page it applies to in a sync way or in an un-sync way. I
am not familiar enough with ID to give a full explanation of how it works
but I fully trust it's also a bit complicated... (outside the theory, in the
real life, that is!).

The result of all this is often only power users make a proper use of Master
Pages and even then they get mixed up sometimes. This is why I say it is a
work in progress. The concept of Master Pages might be simple to be
expressed in a few words, but when it comes to implementation, it is not
that obviously simple.

Sorry to repeat myself but I do believe a summarizing table would help here.
Once we have put that together and get our ideas straight, it's going to be
a matter of choice and because of this, we will not make everyone happy.

The actual Scribus ways has drawbacks but Scribus is not alone on that
field. The other two big players have drawbacks too.

The Scribus way has the merit of being completely clear. The other two are
not as clear, although they seem to have more flexibility. And they actually
do, in a way. But there is a steep price for this flexibility, sometimes.

(It's a bit like the PDF not being editable... It was not meant to be, but
then people complained so much...)

>
> Greg:
>
> "Nonetheless, we have a prototype of what we
> might consider "editable" content with page numbering, so that anything
> editable might be considered in the same context, ie, not freely
> editable, yet allowed to incorporate a list of items/data that might
> change from page to page (something like using a database of some sort)"
>
> I doubt users would appreciate such an approach, as it's everything but
> obvious. It also sounds a bit complicated.
>
> Greg:
>
> "In that sense, Master Pages might be considered to align with content
> management of the likes of Drupal for websites."
>
> I don't know Drupal, but if you could elaborate, some good ideas may be
> derived from its concept.
>
> Greg:
>
> "Maybe Master Pages should be abandoned altogether, in favor of allowing
> all objects to have an attribute that allows them to appear on all
> pages, odd pages, even pages, or a list of pages. This would be a big
> change indeed, best put somewhere down the roadmap."
>
> Sounds complicated again, but who knows. I'd like to know more about the
> consequences. Also, master pages have been used for at least a decade, so I
> think the concept is familiar and even expected by many users.


I think we have a couple of things to do. First, complete that documentation
so people know what is going on and how to use this feature the way it work
now.

The idea of abandoning the Master Pages will certainly raise a couple of
eyebrows... Nonetheless, I would explore that path with much more confidence
than trying to resolve a somewhat complicated equation where you want things
to be static and dynamic at the same time... Or... we keep it as it is AND
we add the Object Attribute...

By the way, when duplicating pages, if we could at the same time manage the
text frame linking, it would solve another 5% of the cases where editable
Master Pages are necessary... (should I file a bug report for this one?)

Object attribute... object attribute. I will give this more thoughts. Sounds
very sane to me, and not that complicated (from the user perspective). Plus,
it could then be part of a style sheet attribute... Even saner?! But this
would mean that no matter where you are in your layout, if such an object is
set to be "tied" with another one, a move on any page where that object is
would affect the others... Glup! Maybe some more thinking is needed!

We have to think more.

Maybe what we need is the possibility to simply add content to an object
created on the Master Page, while being in the Edit Document mode?

We need to summarize. We need a table to summarize the ideas that were
expressed over the years in the bug tracker on Master Pages.

It's getting interesting, isn't it?

Louis


>
> Best
>
> Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20080731/830b0114/attachment-0001.htm>