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

Hi Astron,

a few additional thoughts ...


Am Montag, den 12.09.2011, 17:57 +0200 schrieb Astron:
> Hello everyone,
>
> On 12 September 2011 00:51, Rafael Rocha Daud <rrdaud@gmail.com> wrote:
> > As for the naming scheme, Christoph, is it really that important? People
> > usually change the default names: granted they know what they're doing, any
> > name would fit.
>
> 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].

Agreed. And you both already explain why the naming scheme is
important ...

Rafael, I used that nameing scheme since usability is about checking
what might happen if people click the "wrong" action, if they have to
interrupt their work (and come back later seeing something on their
screen), if they don't read the help (or the dialogs), if they just
click okay (and then searching what they've did).

Thus, a good naming scheme helps them to understand what's going on -
having "Duplicate" (or "Copy"), or "New" in the name is something they
notice _because_ they change it.


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

Fine as well - I hoped the parenthesis will help to avoid confusion for
stuff like "Headings 5".


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

Yep, thanks Astron. At a certain point, if you can't control the
constraints, then a "don't try to be too smart" is the right way to go.
Otherwise people don't know what's going on (usability refers to it as
understandability) and loose control (controllability is an important
usability factor) - so dead simple is good (sometimes).

The "Child" term is something I would like to avoid - for several
reasons. First, it is something also derived from the information
science world and is something which is less neutral (family
relationship may create localization issues for some languages). It
would also require to rename stuff like the "hierarchy" to be
consistent. Next, it is not a word that describe "doing" something - so
we would end up with something like "Create child..." (a bit funny *g*).
And, the most important thing, we use "New" throughout office to handle
objects (New Slide, New Sheet, New ...).


> > 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]:

As I said in the other mail, depends what we want to do with it ...
where a user need help.

> # 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).

At least, we should try to present only those that make sense - there is
even an underused "Automatic" setting that nobody understood so far (or:
only a few people...).

> # 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]).
>
>
> Em 10-09-2011 12:49, Regina Henschel escreveu:
> > > How to make a chain? For example "text body" -> "list" -> "numbering 1" ->
> > > "numbering 1 End". I know how to make it, but how should the UI look, to
> > > make it easy and understandable to normal users? Your proposal does not
> > > solve the problem "I want a list, but the last list item needs a larger
> > > spacing to the next paragraph." Perhaps a third entry [child] is needed.
>
> Anyone who puts this much thought into the layout will figure it out.
> I am pretty sure this is not the most common of cases (although I
> assume making this easy would render LibO more suitable for
> professional users). As you already noticed, you yourself are not the
> epitome of an end user.
> 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).

Well, a -1 from my side. If that counts ...

Cheers,
Christoph