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,
Rafael.
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.
Context
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.