Hi Eike, all!
Nice to have you here as well :-)
Am Samstag, den 10.09.2011, 20:44 +0200 schrieb Eike Rathke:
Hi Astron,
On Saturday, 2011-09-10 12:59:17 +0200, Astron wrote:
Yet, the problem for most people is that they have never extensively
worked with styles and might not understand intricacies like
inheritances.
I think much of the user's confusion can be avoided if the Stylist
didn't show the flat All Styles view initially, but the Hierarchical
view instead. This immediately gives a hint that styles depend on other
styles, even if the user has no idea of inheritance concepts.
Yes and no at the same time - using a hierarchical view usually groups
information (only), so people might still be unaware that definitions
get derived from the upper entries.
Furthermore, this concept would conflict with the (so often requested)
preview of all styles in the Stylist ...
Consequently, I think we have to aim for another solution.
If the Organizer tab for derived styles then instead of the simple
"Contains" would say "Contains not in parent style" or "Items different
from parent style" or some such, things would be much clearer.
Absolutely!
By the way, I'm also a fan of Astron's proposal [1] - referring to "this
style defines"). To address the problem of understandability, the order
of elements should be something like:
* Name: [My Headline]
* Defaults based on: [Headline]
* Definitions in this style:
* Font Style: Bold
* ...
* Behavior (or something like that as a group name)
* [x] Update automatically when editing the document
* Style class: [Custom Styles]
* For next paragraph switch to: [My Text]
In this case, "Defaults" from the inherited style gets explained as well
for this context (defaults is used for different things in Writer...).
Concerning the style (context menu) actions, I'm thinking about:
[New based on...]
# inherit from the upper style (like today)
[Duplicate...]
# copy all definitions from the original style, open the style dialog
# the new style gets the same hierarchy level
[Modify...]
[Delete]
Final menu:
* New based on...
* Duplicate...
* ---
* Modify...
* Delete
I haven't found a totally clean solution for the naming proposal when
using new vs. duplicate. Three approaches:
* dead simple: every new style gets an "Unnamed n" (n = number)
like today)
* more advanced: Having "My Style" ...
* New based on ...: "New (based on My Style) (n)"
* Duplicate: "My Style (Duplicate) (n)"
* mixed:
* New based on ...: "Unnamed (n)"
* Duplicate: "My Style (Duplicate) (n)"
Personally, I don't like the advanced version, since we can/should not
make sure that the string "(based on My Style)" is updated. If people
change the style the settings are inherited from, then we may "flood"
LibO with wrong information. Using the "mixed version" is a bit
inconsistent ... but might work for most cases.
Plus, a few improvements for the "from selection menu" would be helpful.
So far, no larger changes to the stylist - should be doable, or?
Thoughts?
Cheers,
Christoph
[1] http://wiki.documentfoundation.org/File:Organizer-rdsgn.png
Context
Re: [Libreoffice-ux-advise] to duplicate an existing style · Regina Henschel
Re: [Libreoffice-ux-advise] to duplicate an existing style · Cor Nouws
Re: [Libreoffice-ux-advise] to duplicate an existing style · Eike Rathke
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.