- 1 Improving work with styles
- 1.1 Reduce the number of styles available by default
- 1.2 Revamping the Styles & Formating window
- 1.3 Rationalize the stuff around List Styles and numbering
- 1.3.1 “Default formatting” should bring back the default formatting...
- 1.3.2 Paragraph styles that are List styles should be linked to a list style
- 1.3.3 List Styles, Numbering styles, consistency and disambiguation
- 1.3.4 “Numbering...Restart at this paragraph” should be available is paragraph styles
- 1.3.5 “Line numbering” should not be close to other kind of numbering.
- 1.3.6 Drop the whole idea of levels for numbering other than Outline numbering
- 1.4 Clarify the "Next style" stuff
- 1.5 "Paragraph Style" Dialogue
- 2 Improving workwith fields
- 3 Color Chooser
Improving work with styles
Styles are great, so the apps should incitate the user to love them.
Reduce the number of styles available by default
Less is more. People will be more eager to use styles if they are not lost in the choice and are not proposed irrelevant styles. At the moment, there is a number of styles that are created by default, even if they're not used in the file. AFAIKT, it's not an ODF requirement.
Things seem to happen there : /writer/sw/inc/poolfmt.hrc and there /core/sw/source/ui/utlui/poolfmt.src
Every style but Standard should be deletable
That doesn't mean that the default document shouldn't contain additional styles, but they should be much less numerous. For instance, they could be :
- Paragraph styles : Default, text body, Title, Subtitle, Heading 1-10 ;
- Page styles : Default, First page, Landscape
- Character styles : Default, Emphasis, Strong emphasis
- Frame styles : ??
- List styles
Create additional styles on the fly when they are needed.
You don't need User index styles when you don't have a Table of Contents, etc. Those styles should be stored in a simple odt (pool.odt) file at the application level.
Make importing other styles easy and obvious
I know I can already import styles from the menu that says “New Style from selection” but we should have it a little bit more obvious than that.
Revamping the Styles & Formating window
The idea would be incremental "better than nothing" steps : that means changes that wouldn't disrupt users and that would be cheap to implement.
First Step : Tabization
The first step is to create logical groups of the different elements. It just clarifies the way the window works without changing user interaction (he click at the same places as before).
Second Step : Explicit commands
The second step is to move icons in a more convenient place and to redefine their actions :
- Icon "Add" adds a new style ; the triangle beneath opens a menu (Or if it's simpler : icons and triangle open the menu.):
- Add new style,
- create style from selection,
- Load styles.
- Icon "Edit" edit the current style ; the triangle beneath opens a menu :
- Edit style,
- update style from selection
- Icon "Delete" deletes current style
It would imply to change a little bit the user interaction, but icons are more explicit than the existing ones (actually, the Galaxy icons are already quite similar to these ones).
Rationalize the stuff around List Styles and numbering
“Default formatting” should bring back the default formatting...
...numbering included. Try this simple experiment: create a paragraph in Text body, center it and add a bullet to it. Then Format > Default formatting : the paragraph is left aligned back but the bullet is still there. ...and language setting included also.
(it sounds confusing, it is for the average user). What I mean is that by default the paragraph style called List 1 should have its numbering property, its numbering style (see next) set to the list style List 1, so that when you apply this paragraph style to a paragraph it actually looks like a list paragraph. I still haven't figured out why it's not already like that.
List Styles, Numbering styles, consistency and disambiguation
So as seen is the previous paragraph, we have one expression for two different things, and then two different expressions for one same thing. It would be nice to have one expression = one thing.
“Numbering...Restart at this paragraph” should be available is paragraph styles
It's available as a paragraph setting, so it should be settable at a paragraph style level.
“Line numbering” should not be close to other kind of numbering.
I know it sounds similar. But that's just confusing to the user, because line numbering is never used. I mean compared to the other kind of numbering. So it should be cast away to prevent confusion.
Drop the whole idea of levels for numbering other than Outline numbering
Clarify the "Next style" stuff
The "next style" attribute is a key point of style behaviour, but is hard to guess by the user. One problem is that "Next style" in a paragraph style is not the same as "Next style" in a page style, because "Next" doesn't mean the same thing. The first difference is that in one case it's static (paragraph) in the other (page) it's dynamic. May be it's just a question of wording. For paragraph's "Next style", may be we could have something like "Next paragraph created with style:", or something that mentions "creation", because the stlye of the next paragraph won't change when you change the value of this attribute.
"Paragraph Style" Dialogue
- The "don't change anything" state should be more obviously pictured
- "AutoUpdate" option : is it really a best practice to use that ?
- "Next style" : cf. dedicated section
- "Category": linked with the redesign of the Styles & Formatting window
- "Linked with" should be "Inherit from" and followed by the description of what's inherited
- "Contains" should be "Adds" (what is added to the inherited style
Improving workwith fields
Fields are very powerful, but using them is a little bit clumsy
Double clicking field with no automatic content should allow to edit its content
Typically, if you insert a Title field, double clicking it should open the File > Properties dialog presenting the "Description" tab and not the "Edit Field" dialog.
On the other hand, it wouldn't make sens for a field like page number, for which the current behavior is correct