[scribus-dev] Editable Master Pages

[Andreas Vox]

Am 09.08.2008 um 17:18 schrieb Christoph Schäfer:
> ...

> 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?


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+


/Andreas