[Libreoffice-ux-advise] to duplicate an existing style

Rafael Rocha Daud rrdaud at gmail.com
Mon Sep 12 11:30:57 PDT 2011

Hi Astron, all,

Em 12-09-2011 12:57, Astron escreveu:
> Hello everyone,
> I think the naming scheme has a certain importance; then again, you're
> right, people will want to change the name and we should offer that
> immediately after duplicating/creating a style (much like any file
> manager I ever used does) -- that is: create the new entry and
> immediately set a cursor there to edit its name [1].
> That said, the mixed scheme looks good to me, although it might be too
> technical if we put the "n" in parentheses, so I'd leave those away.
This seems very sane to me.
>> The thing is:
>> inheritance is permanent, so if you say "based on" one might think the
>> parent style don't influence the child style anymore after creation.
> It is not permanent: you can manually change it. Christoph's naming
> scheme was an attempt to make implementation easier by not having to
> track inheritances if the user doesn't change the name.
>> Maybe
>> "New (Child of My Style) (n)" would be an even better aproach.
>> That's what I think, but I didn't get quite well your rejection of "New
>> (based on My Style) (n)" and what you meant by "flooding LibO with wrong
>> information". Could you explain this a little further?
> See my comment above (if you don't track inheritance changes, titles
> might contain wrong information eventually), I think that's what
> Christoph meant.
OK, now I got the picture.
>> And about the style preview: do you think we need a preview of all styles at
>> the same time? In MSOffice it is like that, but they can only show a handful
>> of styles at once. I'm not sure if it's useful to preview all styles like
>> that. We could though still have our list, and only preview the style that
>> is selected on that list. It would still allow to compare to the current
>> applied style -- which is already visible in the text itself.
> Absolutely agree, but want to add two things [2]:
> # We need to cut down the number of styles that come by default to at
> most 10 (!!) for any given type of style. My count suggest that there
> are about 60 paragraph styles today, most of which look the same (if
> there are technical reasons, we need to overcome those).
I guess everyone agree on this one. Maybe we should start a dedicated 
page in the wiki at some point to address this specific issue. Only not 
sure if this is a first thing (in which case I would start that page 
myself if that's ok for all) or if we should go first for other 
usability issues around this path.
> # I don't think presenting the preview inside the list is a good idea,
> it might be better to either have a special tooltip or something that
> looks like a tooltip but always appears at a specified position next
> to the styles list (think Abiword font preview [3]).
I like that Abiword preview, but not sure if it fits well for styles. 
Styles are much dependent on context, so it's not enough to show one 
line, but you have to show how it behaves in comparison with "default", 
"text body" or at least "next style". Please check my proposal [1]. 
Preview wouldn't go within the list, but in a box inside Styles and 
Formatting window. That box would be collapsable (does that word even 
exist?) as per someone's suggestion.
> Maybe you are right. Labelling it "child" should be clea(r/n)er than
> the current "New from...". If everyone agrees, I will prepare a patch
> for such a string change (but because of building issues, I won't be
> able to test it, I think).
This would be a must, but sadly I can't test it either (12 hours or more 
to compile on this laptop -- maybe less, the code is already much better 
these days, but still).
> And, finally: Eike wrote:
>> 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.
> You are, of course right about one thing: the tree view can give a
> good overview. On the other hand it also looks more complicated. This
> is an impression we might want to avoid, so I would not go for it as
> the default view.
> Most users know tree views only from the Windows Explorer (or worse,
> "regedit") and they know that Windows Explorer always scared them (it
> is easy to bury something somewhere in the structure and to be unable
> to find it again). I am pretty sure Microsoft know why they buried the
> Explorer view under "Accessories" (possibly even "System tools"..? not
> sure.) since XP.
> Note that in 7, Microsoft introduced "Libraries" that mesh several
> folders and individual files, and can make navigating your disk quite
> the pain (I mention this only as a negative example for Microsoft
> introducing half-baked features where the user experience just isn't
> right [at least for me, as a non-permanent Windows user]).
Agreed. Never thought it that way, but agreed. We'll come up with 
something. At some point.
> Regards,
> Astron.
> [1] By the way: there are many places where LibO could profit from
> editing labels in-place/on double click, such as changing the
> worksheet name or changing the slide name ... 1993 called to say it
> wants its dialogue boxes back.
> [2] If you are for a list of styles, with each style name previewing
> the style itself: consider the case where a style uses a symbol font
> like Wingdings (pardon me, OpenSymbol). That would look odd and be
> plenty uninformative. Next, consider the case of style that uses a 4
> pt font. Also odd.
> [3] http://wiki.documentfoundation.org/File:Abiw-fontselector.png .
> Incredibly useful preview, something to copy, basically.

Best regards,

PS.: is libreoffice-ux-advise the list for this discussion? Maybe the 
devs would prefer to wait for some resolution before reading all this 
thread. Maybe not, it's a honestly question.

More information about the Libreoffice-ux-advise mailing list