As announced in my recent blog we have planned to work on usability improvements in Writer. This will not be a general rework of the GUI but an elimination of some well selected problems we have identified so far and we consider to be possible barriers to the adoption of OpenOffice.org Writer. GUI work is complex because it can't be done based on technical considerations only. The GUI is the point where the technical perspective of the program developers and designers meets the user's perspective. Problems usually start where the technical perspective slips into the GUI too deeply. This forces the user to think technically and makes the process of understanding the features unnecessarily complex. Following the quote from Albert Einstein I used as a title for this blog simplification is necessary in these cases – but without an oversimplification that makes it harder for experienced users to utilize Writer's full and powerful feature set. A very good example for this is everything related to working with styles.

Many users, especially new ones, don't use or even understand styles. So if you want to win them it is important that they can use the application and explore its advanced functionality without taking lessons in “ styles and how to use them” as a precondition. I still think that they should get into styles later on to get the most out of Writer or OpenOffice.org in general, but it shouldn't be necessary in the beginning. On the other hand styles are a vital part of the OpenOffice.org document concept and pleasing users that want to ignore them shouldn't make working with styles harder for other users.

This is the challenge and overall I think that we cope with it quite well. If you don't need the additional power of styles using them or not is mostly a matter of taste but not a completely different way of operating the program. Nevertheless there are at least two cases where you currently need to understand what styles are, how they work and how OOo uses them: page attributes and outlines. Not surprisingly these areas sometimes are hard to understand for newbies.

The problem with page properties is not solely an OOo Writer problem, it is common to all text processors that are not page oriented but create pages only as parts of their layout. All programs have different ways to tackle it. In Writer we do it the following way: if you want to change page properties in Writer you must change them in a page style, perhaps you must even create and assign new page styles before in case you don't want to change the properties for all pages of the whole document. This can lead to questions like these:

• what's this “Default” menu entry when I call “Insert Header”?

• I've changed my page to “Landscape” - now all pages get this format. How can I apply this only to my first page?

• “I am a writer desperately trying to format a multi-page document with one header ON THE FIRST PAGE and a different header on subsequent pages. I have tried everything. Please inform.” (This is a current quote taken from the users@openoffice.org mailing list!)

I have started to collect some ideas around page styles (to be continued). These considerations will influence the work on issues for headers and footers and for page numbers, more issues might follow.

The outlining problem is created by a break in OpenOffice.org's attribute concept. The only way to assign an outline level to a paragraph is to assign a style to this paragraph that itself has a “default outline level” attribute set. Once a paragraph has got an outline level it is the start of a “chapter” and all of these paragraphs can be collected to a table of contents. In the future we want to have a “hard” attribute for the paragraph outline level also. This is killing two birds with one stone as it also improves our interoperability with Word. Working with this attribute shouldn't be different to working with e.g. the paragraph indent. It can be assigned directly or taken from a style. A paragraph with such an outline level attribute also marks the beginning of a chapter and will be part of a table of contents.

I hope that my little exposition gives an impression how we think about usability improvements. Whatever we do, we shouldn't jump to conclusions and we should be aware of another wise mans opinion about solving complex problem:

“For every complex problem there is an answer that is clear, simple, and wrong.” -- H.L. Mencken