Future of Master Pages: Difference between revisions

From Scribus Wiki
Jump to navigation Jump to search
No edit summary
Line 601: Line 601:
|-
|-
| 29
| 29
| Avox
| I think usability 1 can be discarded, no approach should be noticably
slower or faster than any other.
For the first criterium you have to keep in mind that development time is
also correlated to coding fun :-) ( difficult -> more time needed and more
fun to implement)
I'd like to add usability 3: long-term intuitivity. Some MS products have
features which are fast to learn, but they are so stupid that I forget how
to use them right away.
Here's my opinion on four options:
Status quo
---
development time:      zero
learning curve:        flat
long-term intuitivity:  medium
flexibility/features:  very poor
consistency:    poor
Just content editing
---
development time:      low (medium with automatic textframe linking)
learning curve:        flat (that's what users expect anyway)
long-term intuitivity:  high
flexibility/features:  low
consistency:    high
Style-based apporach
---
development time:      high
learning curve:        high
long-term intuitivity:  medium
flexibility/features:  very high
consistency:    high
Non style-based approach that allows local editing of objects
---
development time:      medium - high
learning curve:        high
long-term intuitivity:  medium - poor
flexibility/feaures:    medium
consistency:    poor
Please note that my assessment is independent of the UI (what context menu
/ editing mode / buttons / palettes are needed). For any approach there are
different UI options which might affect learning curve, long-term
intuitivity and consistency.
I'm also convinced that the "just content editing" would cover more than
80% of user requests.
So I vote for implementing that and reserving the style-based approach for
version 1.5+
| Gregp: It's hard to know if I agree with the assessment, yet nonetheless I like it, though I'm worried about this 'high' assessment of learning curve for
the style-based approach. Hopefully there might still be some basic "MPs for Dummies" operations that could be very simply used, like page numbering or putting banners on pages.
Louis:
> I'm also convinced that the "just content editing" would cover more than
> 80% of user requests.
I am convinced of this too.
> So I vote for implementing that and reserving the style-based approach for
> version 1.5+
This sounds pretty reasonable to me. I second this with enthusiasm!
|-
| 30
|  
|  
|  
|  

Revision as of 20:16, 11 August 2008

The discussion about the future development of Master Pages

Scenarios/Proposals

Editing objects on master pages for one or more particular regular pages.

This table is still empty and will be until a working agreement is reached about the scenarios and proposals to solve them.

#/Author Scenario Proposal Comments
1/a.l.e layout of a multilanguage flyer (same layout, partially adapted images, content may have small differences in length t.b.c.

Running summary from scribus-dev at lists.scribus.info

# Author Text Comments
1 Christoph list all master pages in the page list, so that the master page can be directly edited by selecting it in the list. This would have the same effect as selecting the master page in the Document Outline. Avox: Yes, that sounds very sensible.
2 Christoph have a button beside the page list that would open the master page of the currently selected page for editing. Again, technically the same as opening in the document outline, except that the user doesn't have to find out which master page is used for the current page. Avox: Yes, that sounds very sensible.
3 Christoph When it comes to editing an item only on the current page, there should be a second button to switch on the editing mode for master page items on the currently selected page.
4 Christoph There should also be a spin box to set the opacity of the actual page content, so that users can check how changes to the master page will affect the layout as a whole. Default should be 0%, so that the content is invisible. Avox: I don't follow your opacity explanation there.

Christoph: Perhaps it is clearer if you download the PDF file that's attached to the original posting. My idea was to edit a master page while the original page is still visible. The user could set the degree (transparency) of the visibility.

5 Christoph To disconnect an item from the master page and use it only on the current page, one could use the "Send to Layer" feature: Each document has at least one layer, so that sending the item to "Background" (or any other layer in the current document) should be enough to remove the item from the master page. Avox: That's unintuitive I think.

Christoph: If properly documented, I think this would be rather intuitive, because it simply extends the concept of layers (see my reply to Greg).

Louis: Paradoxal. Intuitive means one can figure out the feature by oneself, without reading the manual. At least for experienced users.

Christoph: No. In DTP, nothing is "intuitive". Just remember the many questions regarding very basic operations. "Intuitive" in this context means that there's one way to do it in a certain program (here: the many page features and layers), which can also be followed with other features (master pages).

6 Christoph Once the editing is finished, the user would have to click on the edit button in the status bar again. Scribus would then bring up a dialog similar to the current "Apply Master Page" dialog.
Options:
  • Apply Changes to the Current Page
  • Apply Changes to the Master Page
  • Apply to all Odd Pages (ie. those that use the master page)
  • Apply to all Even Pages (ie. those that use the master page)
  • Apply to the following Pages: (ie. those that use the master page, single pages and range)
Avox: Too complicated IMHO

Christoph: Again, this is just the extension of an already existing concept, ie, applying master pages to existing pages. In this case it would just be bit different: applying changes to master pages. From experience I know that people learn things easier, when the concepts seem familiar.

7 Greg Pittman 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. Christoph: 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.

8 Avox "From object styles to master objects"


On our roadmap we have the extension of the current inheritable style system from char/paragraph styles to line styles, table styles, cell styles, frame styles, ... to object styles.

A style is just a collection of settings, where each setting can be set or not set. If a setting is not set, it's inherited from the surrounding element (char settings from the paragraph style, paragraph settings from the document).

That's the situation without named styles. When the "based on" field contains the name of a style, undefined settings are taken from that style instead of from the surrounding element.

Ok, so let's say we have object styles which describe all settings of a pageitem, including position (normally we wouldn't want that in a style, but read on).

Now, instead of using a named object style for an object, we could also change the masterpage mechanism such that page items have a "based on" property which points to the corresponding master page item. Those page items would be fully editable locally. Changing the corresponding master page item would automatically change the settings of the descendant page items, unless they were redefined locally. Similar to the "Broom" Button for paragraph styles there would be an option to reset all settings to the masterpage item's defaults.

Applying a masterpage to a page would mean creating additional objects on the page which are based on the corresponding master page items. Those items would be locked by default, so editing a masterpage item locally means unlocking that item first. There should be another lock mode which fixes all settings except for content (text or images).

Deleting such an item would remove the item just from this page. There should be an option to recreate items which were deleted that way.

Applying another master page would remove the additional objects unless they were changed locally. Locally changed objects would stay on the page but loose their automatic masterpage connection (or they could be deleted anyway, what do you think?).

That mechanism should also work for hierarchical masterpages (is there already a feature request for this? :-) ) and for more than one masterpage per page. Come to think about it, it's also very similar to Inkscape's clone objects.

9 Terry Green (through Gregp) Thanks for the advice, will try and work round the problems with extra

master pages etc, one thing with the way they work in Indesign is I could put all the text boxes I needed on the Master page and set the different styles for each text box ie; Font Style,Size,Color,Fill color etc, then when I enter text into it on any page based on that master the styles and formatting and everything else with that text box or Image box stays the same, maybe Scribus in the future may have these features, it sure saves a lot of time.

10 Greg Pittman I don't know that changing Master Pages to meet his "needs" is a very good

answer. It sounds to me that what he really might want to use is a Template, or actually just a template page. Maybe this could be in some way linked to a Master Page, but I think that it needs to be a separate layer.*

As I look at 1.3.3.13svn, I see that you can't insert a page from a Template - at least I couldn't seem to make it work when I tried to import a page from one. Furthermore, there would need to be some facilitated way to find templates from the Import Page dialog - I found it because I knew where to look.

I think this may be only a slight modification of current capabilities, and therefore not so much of a coding challenge.

  • This of course brings up possibilities of other kinds of external

linking from Master Pages that might serve other purposes - even though a Master Page cannot be (easily) edited, something that links to it might be.

MrB: Actually, this is how master pages would work anyway in the future. A frame on a master page will be able to be formatted, so any text typed into it on a normal page will take up those settings unless overridden on that normal

page.

Templates are somewhat broken and need reimplementing anyway - I would not start to base any functionality on those that depends on the current operation/look or that would confuse two commonly mixed up phrases like master and template pages.

11 Louis 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...)

12 GregP Well, it would seem to make sense to me to have a listing/table which in

one column lists scenarios in which the current implementation of Master Pages is a roadblock or completely unintuitive. Another column indicates either the desired use or the intuitive approach, and trying to stay with the layout concept rather than conceiving of a particular software solution.

Hopefully, such scenarios can be real ones from the mailing list or from people's experiences rather than theoretical ones. Theoretical uses have no boundary, but at some point we have to be reductionists.

In a sense, Master Pages represent a special layer. Why can't they be more like a regular layer? Why can't the things you can do with a Master Page be applied more generally -- perhaps have the ability to apply all the objects on a given layer to as many pages as you want.

One might argue that this defeats the purpose of a Master Page, but it is appropriate to ask if Master Pages as they currently exist are even necessary.

Christoph: The problem is that a master page may contain several layers. My proposal tried to extend the current implementation of layers to avoid the

mess seen in QXP and ID by listing layers in master pages separately (they'll need a visual indication) and to move items between layers on real pages and layers on master pages or even complete layers if the user wants to do that. The Document Outline is one place to do this easily, but there could be others (eg the Layers dialog if layers should be moved to between regular pages and master pages.

Louis: Imagine the mess, now. Several layers into a master page... Where will this lead us?! (!!!) (SEE #18 for a counter proposal)

13 Christoph Now, instead of using a named object style for an object, we could

also change the masterpage mechanism such that page items have a "based on" property which points to the corresponding master page item. Those page items would be fully editable locally. Changing the corresponding master page item would automatically change the settings of the descendant page items, unless they were redefined locally. Similar to the "Broom" Button for paragraph styles there would be an option to reset all settings to the masterpage item's defaults.

Applying a masterpage to a page would mean creating additional objects on the page which are based on the corresponding master page items. Those items would be locked by default, so editing a masterpage item locally means unlocking that item first. There should be another lock mode which fixes all settings except for content (text or images).

Hmm, this seems to have a lot of potential, but how would you go the other way, ie, adding an item from a current page to the master page or a range of them? And is there a way to remove an item from a master page on a real page without deleting the master page?

Deleting such an item would remove the item just from this page. There should be an option to recreate items which were deleted that way.

Would recording it in the Action History not be enough?

Applying another master page would remove the additional objects unless they were changed locally. Locally changed objects would stay on the page but loose their automatic masterpage connection (or they could be deleted anyway, what do you think?).

I predict a lot of confusion if we do this ;)

That mechanism should also work for hierarchical masterpages (is there already a feature request for this? :-) ) and for more than one masterpage per page. Come to think about it, it's also very similar to Inkscape's clone objects.

Yeah, that would be a great extension, but maybe we should resolve the basic issues first.

14 Louis Also, layers may be well used in image editing but in DTP, believe me, they

are not. And I doubt this is going to change. People might get the concept rapidly (after all, a layer is a layer and this is easy to catch) but they often don't have a clue about the real use and benefits — and drawbacks, of course, of layers.

Christoph: They are used a lot, of course. I don't know of you, but for testing bugs I must have downloaded dozens of sla files, and I guess 40% of them

contained layers.

15 Unknown (to me) Master Pages are in fact a locked layer. The containers (empty text and image frames) are locked. The content is uneditable and locked. This works perfectly and has a predictable behaviour, always. At least in Scribus. Christoph: I don't think this is correct. Currently, a layer outside the master page is a document layer, not a page layer. And why shouldn't users use layers in master pages? Who are we to tell them they shouldn't?

Louis: I didn't say they shouldn't. People do just what they want! I only said it was not much in use among DTP pros (although I am sure you will find dozens who do, but that proves nothing, really). This of course is from my little experience.

Avox: Well, right now all master page objects are placed below any ordinary objects. We could change that so that MP objects of layer X are placed below ordinary objects of layer X, but above ordinary (and MP) objects from layer X-1.

16 Unknown (to me) The Master Page remains as it is, static. The Page Style has all the benefits of any other style. It can be edited and applied at will. People can apply it, and change their mind. Unknown: I dont understand the use of "static" here. You can already apply and re-apply master pages at will. If you edit the MP, all pages that use it change, too.

Louis: Static because the elements that are on the MP can only be edited on the MP. No possible tweak on the regular page.

17 Unknown + Louis > The only thing that's static is that MP objects look exactly the same on

> each ordinary page, minus page numbers. That's a limitation which we need to > address, at least for text content (eg. no text content on MP -> text object > is editable on normal page; MP object has text content -> text object is > static (minus page numbers) on ordinary page). That's the minimal solution.

I follow you on the second part of your sentence but on the first, I have some reserve. Putting content in a text frame does not affect the structure (ie, the text frame doesn't move). In XPress, putting text into a frame won't de-sync that frame and I can only guess it is the same in ID. What de-syncs an element is when you modify its shape or position on the page.

I agree that the minimal solution would be to let users put content into a text or an image frame that would have been first created on the MP.

As a side note, I trust that doing so would take care of a high percentage of the complaints, questionning or frustrations we hear about the MP. Sure, people would want even more flexibilty, but once this minimum is addressed, I am sure we'll hear less noise!

18 Louis Master Pages are in fact a locked layer. The containers (empty text and

image frames) are locked. The content is uneditable and locked. This works perfectly and has a predictable behaviour, always. At least in Scribus.

Maybe the problem is not named correctly? Thus, it may lead us to think the issue is the Master Page. It may well be elsewhere. The issue now is to allow going back and forth while editing the layout, from idea A to B to C then back to A or A', endlessly. And this of course defeats the idea of the Master Page concept. If a Master Page can be further edited downstream, this can have many effects on the operations downstream too. Such as proofreading, quality control, and finally, printing. And costs, of course.

Because the problem is not well identified, the solutions will always be akward. ID has come up with a complicated sync and de-sync options, while QXP has not solved the issue of the de-sync'ing... Maybe the solution doesn't lies there? I don't pretend to have the solution. I am only asking questions at this point.

We have this flexibiliy with stylesheets. We can edit endlessly any stylesheet. We can go from idea A to B to C and then get back to A or A'. Maybe what we are looking for lies in stylesheets, not Master Pages?

When I say, use the Page > Copy as a workaround to editable Master Pages, I know this won't solve an issue such as being able to reposition the text or image frames *after* the pages are created, all at once in one go — like it was asked recently on the mailing list. This would be the purpose of a Master Page in the old thinking. And it could well be the purpose of Frame Stylesheets in the new thinking. We could even extend this to Page Stylesheet... (is that feasible?)...

Really, what people want is more flexibilty on one aspect while they need stability on the other. In my opinion, trying to achieve both goals with the same tool might just lead us nowhere. We need a hammer *and* a screwdriver. We need duct tape *and* a wise-grip. And $100 can't hurt too! (joke from IRC...)

Repeat: Master Pages in Scribus are sane.

What we need is to find a way to position a frame precisely somewhere on a page and be able to create a 1000 pages with the same layout and then be able to change our mind and position this frame somewhere else, with precision, without altering the content. If there is no content yet, then Page > Copy is the way to go.

We also need to be able to manage the links between text frames.

And we need to identify what is a styled frame and what is a regular frame. I guess a styled frame would be locked by default. One could edit the content with no specific permission. To edit the position would require to go to the Style Manager... Of course, at any time, just like for any stylesheet, one could apply the "nostyle" attribute, thus setting this particular frame free. And this idea could be developed, of course.

In my opinion, layers have to remain what they are. This is already something to deal with them. Let's not complicate the concept more and more. Honest, we will never see the end of this. Bad idea.

By the way, the stylesheet concept has already been thought of nearly 2 years ago...

http://bugs.scribus.net/view.php?id=4606

Only, I would keep the static Master Page as they are, and use the stylesheets as described above.

Gregp: Maybe having a Copy To... function would help -- where you could copy to

the same page with particular coordinates, a different page with the same or different coordinates, all pages, or a range/selected pages. I don't have a fixed opinion about this idea of being able to edit one copy then have all of them sync together -- maybe the best thing there would be to use the Action History to go back to the point before you did a Copy To..., edit the original, then Copy To... once again. OR, have a dialog with a list of objects in the document, where you can click one or a number of them and carry out a collective operation, including delete -- perhaps just adding capabilities to the Outline dialog.

Avox: I dont understand the use of "static" here. You can already apply and re-apply master pages at will. If you edit the MP, all pages that use it change, too.

The only thing that's static is that MP objects look exactly the same on each ordinary page, minus page numbers. That's a limitation which we need to address, at least for text content (eg. no text content on MP -> text object is editable on normal page; MP object has text content -> text object is static (minus page numbers) on ordinary page). That's the minimal solution.

Making MP objects editable on the ordinary page (without changing the MP definition, that would be insane!) is the maximal solution. My proposal was to reuse the styles technology and the locking mechanism here.

A dialog as in style manger is inappropiate for master pages IMHO. No need to change the GUI here, except for how to enter MP mode. For un-synching / synching the user would have to do the following in my proposal:

- unlock the MP object on the ordinary page, then edit it - resetting some object properties would synch that property with the MP again - deleting the object would remove the MP object from the ordinary page - a new dialog would allow to re-add deleted MP objects to the ordinary page

Louis: Static because the elements that are on the MP can only be edited on the MP. No possible tweak on the regular page.

I follow you on the second part of your sentence but on the first, I have some reserve. Putting content in a text frame does not affect the structure (ie, the text frame doesn't move). In XPress, putting text into a frame won't de-sync that frame and I can only guess it is the same in ID. What de-syncs an element is when you modify its shape or position on the page.

I agree that the minimal solution would be to let users put content into a text or an image frame that would have been first created on the MP.

As a side note, I trust that doing so would take care of a high percentage of the complaints, questionning or frustrations we hear about the MP. Sure, people would want even more flexibilty, but once this minimum is addressed, I am sure we'll hear less noise!

I agree. Styles would allow the maximum flexibility.

Gregp: I think you also have to think about streamlining the process. For one thing, without changing the way links work, they could be easier to work with. Make the linking something like making a Bezier curve, where you activate linking, then left click, left click, left click, then when you're done, right-click or ESC to end linking and turn it off, with a message or tooltip to tell you this. As far as auto-linking, maybe there should be some semi-automated naming of frames, so that you could have families of text frames with similar names (think of the way that KSnapshot helps with naming screengrabs by automated numbering: eg, snapshot.png > snapshot1.png > snapshot2.png, and so on). This would facilitate auto-linking. It might also allow for rearranging the linking simply by changing names of the frames.

What about the idea of having, for example, an empty text frame on a MP, which in a sense "links" to an editable frame on a regular layer on every page where that MP is used. The content could be edited in the usual way, but you could go to the MP and change position and size, which then would change the position and size of the editable frame on the editable layer without changing content. Could/should you be able to change position/size on the regular layer? Perhaps, but you'd have to decide whether this might change the frame on the MP -- might be a problem, and perhaps might "break" this MP link, at least on that page. I'm trying to think in the terms of the complaints that people seem to have, but also preserving the "integrity" of the MP.

Avox: I'd rather see something like in Pagemaker: clicking on the overflow indicator goes into link-mode. Shift clicking will create new textframes as necessary. Unlinking is available via context menu.

I think role names are a cleaner approach than some elaborated naming scheme.

19 Avox a) all objects get a "role" attribute, which might be empty.

b) text frames get an "auto-link-to" property which takes a rolename. c) when a text frame which has the "auto-link-to" property set overflows, Scribus automatically links to the next object with the same role as the specified "auto-link-to" name. d) The next object is found by looking for objects which are placed below the current object on the current page or which are on top of a following page (yes, that means the text would reflow if you reorder two auto-linked frames on a page. And it's not so easy to create textframe links that run against the page order) e) Manually linking frames overrides the "auto-link-to" mechanism. f) Empty text objects from master pages are editable on normal pages and use the role/auto-link-to properties.

The current autotextframe functionality would be recoverd by creating those textframes with a fixed rolename on the master page.

Louis' scenario for bilingual text would be possible with this proposal.

20 Christoph Editing means just that: everything they could do to with an object on a regular page. This includes deleting an item or moving it to the regular page (which is the same as desynchronising). Christoph: There's nothing more we need to address
21 Christoph Perhaps a user would want to add an item from a regular page to a range of master pages or a static master page. I don't know why someone would do this, but you never know what users come up with.
22 Christoph How can a user access an item (or more) on a master page quickly without having to jump through many loops?
23 Christoph How will the changes be applied?
  1. Edit the content on the master page -> changes will apply to all master pages
  2. Apply the changes locally but keep the item otherwise in sync with the MP (there should be a "refresh mechanism" to override local changes, but I think this could be done by applying the MP again in the Page > Apply Master Page dialog).
  3. Detach the item from the master page and make it a part of the current page (and, perhaps, vice versa).
24 Christoph As for using styles, master pages are already styles in a sense: change a style and all text/lines with that style will change, change one MP, and all pages that use the MP will change. I agree that one could use the style "mechanism" like overriding styles with local formatting, but this has a serious drawback, which is already hurting us: if a paragraph style is being changed or another style is applied to the text, what happens to the local changes? Which one is preferred, the new style or the local change? There is no easy answer, and that's why I don't think the style mechanism should be used. It just gets in the way for quick changes and is probably overhead.
25 Christoph Louis' idea of using the context menu is correct, but we should keep in mind that it's already quite bloated. My purpose was to use existing features that are already there, ie. layers. Detaching objects from a master page by moving them to a document layer is quite easy. Frankly, I don't care if DTP people did fine without layers for years. The technology is available in Scribus, it works

reliably, and it's known to our users (and will be fully documented in the manual). Why not use it to save time and provide something easier than InDesign's insanely complex way? It would take four mouse clicks to detach an object ort to delete it

  1. switch to the editing mode
  2. right-click, then
  3. in the context menu Send to Layer/Delete
  4. switch off editing mode).
Louis: A context menu can be less bloated in a given context. We can strip it down in the MP context, for instance.

It would be great to explain what works and what doesn't in the "insanely complex way" of ID.

26 Christoph The same goes for editing items:
  1. quickly switch to the editing mode for master pages
  2. edit the item
  3. then decide if the changes will be applied to the current page, to the master page itself or a range of pages that use the master page. Aside from the editing itself, it'd take four mouse clicks
  4. enter editing mode with a click on a button, then edit
  5. click the button again, which brings up a dialog to choose from
  6. make your choice and then
  7. OK).
I can't think of anything easier.
Christoph: The linking of text frames is IMNSHO totally unrelated to editable master pages. This should be discussed in a separate thread. Andreas' idea of roles is probably the way to go, but before that can be introduced, the linking of text frames should be fixed and brought on par with ID. That will be enough work, I think, for the near future. Andreas has quite a few great ideas here, IIRC. In this context, we probably also need to discuss changes to the page numbering, as we'd need to be able to have parallel numbering schemes for facing pages with different languages. I think there's already a bug report for this.
27 Louis 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. Which one is preferred, the new style or the local change? Good question. It could well be an option. And if it isn't, I am still inclined to think the Style+ way is fine.

28 Louis 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. Gregp: We clearly need to reduce much of the rigidity of MPs, so that changing

one's mind about a layout doesn't end up being a lot of undoing and redoing of time-consuming work. I think it's also clear this is not just a matter of tacking on a bunch of new functions to MPs.

29 Avox I think usability 1 can be discarded, no approach should be noticably

slower or faster than any other.

For the first criterium you have to keep in mind that development time is also correlated to coding fun :-) ( difficult -> more time needed and more fun to implement)

I'd like to add usability 3: long-term intuitivity. Some MS products have features which are fast to learn, but they are so stupid that I forget how to use them right away.


Here's my opinion on four options:


Status quo --- development time: zero learning curve: flat long-term intuitivity: medium flexibility/features: very poor consistency: poor


Just content editing --- development time: low (medium with automatic textframe linking) learning curve: flat (that's what users expect anyway) long-term intuitivity: high flexibility/features: low consistency: high


Style-based apporach --- development time: high learning curve: high long-term intuitivity: medium flexibility/features: very high consistency: high


Non style-based approach that allows local editing of objects --- development time: medium - high learning curve: high long-term intuitivity: medium - poor flexibility/feaures: medium consistency: poor

Please note that my assessment is independent of the UI (what context menu / editing mode / buttons / palettes are needed). For any approach there are different UI options which might affect learning curve, long-term intuitivity and consistency.

I'm also convinced that the "just content editing" would cover more than 80% of user requests.

So I vote for implementing that and reserving the style-based approach for version 1.5+

Gregp: It's hard to know if I agree with the assessment, yet nonetheless I like it, though I'm worried about this 'high' assessment of learning curve for

the style-based approach. Hopefully there might still be some basic "MPs for Dummies" operations that could be very simply used, like page numbering or putting banners on pages.

Louis:

> I'm also convinced that the "just content editing" would cover more than > 80% of user requests.

I am convinced of this too.

> So I vote for implementing that and reserving the style-based approach for > version 1.5+

This sounds pretty reasonable to me. I second this with enthusiasm!

30