Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index

Hi Octavio, all,

thanks for bringing this back, I wasn't sure I had sent it to the right
list. Right now I've subscribed to the design's list (thanks Bernhard), so
we're talking (feel free to keep out of
replies if you want).

This mail is just too long, so go on to the end for conclusions.

I'm going carefully through the chapter 3 of "getting started guide" and
chapters 6 & 7 of "writer guide" available here:, all of which on using
styles. I want to be sure I know at least the present way of doing things
before suggesting any new way (again; thanks Bernhard for highlighting the
flaws in my reasoning). And I'll continue to follow this list and try to
come up with ideas and suggestions.

As for the ones that arose, I would agree with Octavio: as soon as I read
Bernhard suggestions, dialog and notifications came to my mind, and I too am
not very fond of those. The problems were well put, but it needs to be
worked out.

The things Andy brought up: a) better documentation in Help and b) reducing
or permitting deletion of built-in styles, seem reasonable to me. We have
many "Customized Index" styles pre-built, which sounds counter-sense, and we
have more paragraph styles refering to lists and numbering than lists and
numbering styles for themselves. Documentation is always welcome, but quite
frankly I believe a big improvement in documentation doesn't always reflects
in big improvement in usability, because most people don't ever read them.
Some documentation is needed, but that we already have (and I believe
there's already some additional work being thrown on that).

So we go to Octavio's suggestions, which go on pre-built styles reasoning,
and seem to be on that same line. Last weekend I was helping my girlfriend
with some formatting in a long document, and while formatting styles, we
ended up with a Title 2 following a Title 3 which in turn was following a
Title 1. It seemed OK, but turned out to be wrong when we generated a PDF,
which uses titles hierarchy to make indexes. The same happened with my poem
book: I used different title styles, depending on whether the poem had a
title or not (so it's first line had to be a different title style in the
document). So I learned I had to respect hierarchy, but whether I should
create new styles based on that Title 1, or if there was another way, and
furthermore, if my PDFs would respect the hierarchy with my new styles, none
of this was clear. We need reasoning, and the first thing to achieve that,
IMHO, is to narrow down the number of built-in styles -- the second is to
find a way to make it clear what are those remaining good for.

But I'm just repeating wiser men. The big problem is, if I got it right, how
to make use of styles easier (instead of necessary, obligatory, as I had
suggested earlier), without getting in the way of user's current workflow.

I believe we should note that there are different ways to use styles: some
use it all along (like Bernhard -- "I like using styles for character
formatting too"), others just use them for paragraphs (myself, in the long
run), others just don't (my gilrfriend before I doctrinated her :-)). I
guess this is an almost political decision, whether we want all these uses
to be equally acceptable, or if we want to impose a right way of doing
things. Depending on the answer, we can focus our efforts.

I say "almost political" because I've heard more than once that
compatibility with MSoffice was not a problem, provided you have used
styles. And copying and pasting gets really messy (at least in a way that
seems incoherent/inconsistent) if you're not using styles. This may seem a
subjective feeling, but I trust LibreOffice much more after I started using
styles. My girlfriend even experienced applied direct formatting simply
disappearing after re-opening a document (on OpenOffice -- this could be a
bug, but then again, the inconsistency feeling: we should know that it's a
bug, and not just the way things are -- she said to me: this is no good
software; and she's a long time happy, supporting linux user).

This "subjective feeling of consistency" is a great achievement for any
software. If one feels it is consistent, he may go to the Documentation to
learn how he may benefit. Otherwise, he might feel it's not worth it, and
may grab a pirate copy of MSoffice just the same (which is not that
consistent either, but you know the story).

Sorry for writing such a long mail. I guess my main point was: do we want
people to start using styles all of a sudden (my original intent), or do we
just want it to be easier for those who already use it, or plan to use it,
and to let the others continue to do direct formatting as they are
accostumed with? If it's easy enough, it won't be a "power user" thing
anymore, and more people will use it. But is there known issues against
using direct or hard formatting? What will bring the most "subjetive feeling
of consistency" in using the software?

Best regards to all (and congratulations for GSoC admission).


2011/3/27 Octavio Alvarez <>

On Sat, 26 Mar 2011 16:33:39 -0700, Bernhard Dippold
<> wrote:

 Hi Rafael, all!

I don't know if you have noticed Octavio's reply (it raised your mail to
visibility again), because he didn't CC you, what seems to be usual here on
this list (in opposite to any other LibreOffice list).

I put him in the To: field. However, you did not Cc: me in this message.
I'm interested in everything related to styles.

 What I was thinking is how to make new users (or even old ones) to use
style-based rather than direct formatting.[...]

Styles are a very mighty feature - but as you state below, they are not
accessible enough to be accepted by the average user.

And *this* is where we could improve. Instead of trying to forcedly push
styles to the average user we could try to make it more user-friendly and

To start off with an idea (I think you will like it): we could fix the
always visible, whatever-is-named, Styles dropdown in the toolbar. Let's
assume the user visits the dropdown (maybe he is just exploring). Let's
accept the following facts:

1. "Default" without a noun has no meaning: "Default" *what*?

2. "Heading 1" and "Heading 2" are technical names, not explicit enough,
and therefore, not user-friendly: Does it mean "The first and second
heading in my document" or "Different types of heading [disregarding a
nesting level]" or "The level of nesting of a header"?

3. Having "Default" as the default causes problems: So, we start writing.
We leave it as "default" (because, it's the *default*, right? We trust the
developers.) We write a couple of paragraphs and headings (for which we
choose Heading 1 and 2). We change "default" line spacing to "double". Why
did it change the line spacing of my headings?! How do I change my
paragraph spacing *without* modifying my headings? The advanced user will
tell him to set all his paragraphs to "Text body" first, always, or change
all the regular paragraphs to Text body, skipping the Headings (which is a
pain). Then, why, oh why, is Text body NOT the selected-by-default style.
Same thing with Header and Footer.

4. Paragraph styles are the easiest to understand, and the one that gives
the user the most immediate benefit. He will have a solid base for a
uniformly formatted document, assuming he considers that as a benefit
(some users don't). Also, should he discover "Insert > Indexes and Tables

Indexes and Tables...", just by clicking OK he will save himself hours

of pain.

My proposal:

1. Adjust it to have something like "[ Regular paragraph |v]". At least
"regular paragraph" with a dropdown implies there are *other kinds* of
paragraphs, which paragraph styles is all about.

2. Have the dropdown show as options: "1st-level title", "2nd-level
title", "3rd-level title". I would add "Document title" too. Those names
are friendly names that would map to Text body, Heading 1, Heading 2,
Heading 3 and Title, *or* have these styles renamed all over LibO. My
problem with the renaming-all-over idea is that it would break the sorting
order of

3. I would take "Default" out of the list and put "Text body" as the
selected-by-default style (and rename "Default" to "Root" in the S&F
window or any better idea.)

(How all this could break already existing documents, I don't know.
TEsting would be needed.)

4. Rename "More..." to "More styles..." <---- HERE you introduce the term
"styles" as a "kind of paragraph".

5. In the S&F window, between its toolbar and the style list, add an
explicit label "This paragraph is a: [ Text body ]".

 All that applies to paragraph styles, but once you are in that path,
it's quite easy to take a hand on character and page styles. As for Bold
and Italic, and some of the other character formatting, I guess it poses
a problem, for which I don't have any answers yet. The most uses of Bold
and Italic are with direct formatting.

But it is the mightiest area IMHO:

HTML provides styles like "strong", "emphasized" and so on, so at least
some people know about this option.

Now we need a way to set both at the same time. What if it is a foreign
word (italic) inside a strong statement (bold)? We don't have that yet.

 What we would need: An easy way to ask the user what he wants to do.

I am against dialogs as much as possible. It takes away the input focus,
which is a source for "what is happening here?".

 Perhaps by using the new notification feature (currently worked on at OOo)
we could inform the user that he enters a different style when he adds an

That's the problem "just adding an attribute" shouldn't alter styles
at all.

 And in case this is not his intention we could provide different options:

- Apply new attribute to selection only (single paragraph/character style
- near to hard formatting)
- Apply new attribute to existing style (modifying all appearances of the
style in the document)
- Create new style with the new attribute and the already existing ones
(provide an easy name like "Standard bold" or "Textbody red background"). If
the new style already exists, the selection can join this style. This should
be standard behavior.

This implies a dialog! The user would not even understand why is the
program asking him something he doesn't know how to answer.

What do you think of these ideas?


Twitter: @alvarezp2000 -- @alvarezp

Unsubscribe instructions: E-mail to
List archive:
*** All posts to this list are publicly archived for eternity ***


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.