Design Proposal: Style Editing Directly at Toolbars

Please do not edit this page unless you are the original author. Your feedback and comments are welcome in the Comments section below or on the ui@ux.openoffice.org mailing list.

The following design proposal is part of the collection of design proposals for “Accessing Functionality”, which is part of Project Renaissance.

Summary and Status

If you want to use in text objects text styles for a style based/global formatting of your text instead of hard coded formats you need to open the Styles and Formatting dialog [F11] to be able to change the style there and a new dialog is being opened with several tab pages where you can make your changes.

Idea: After I have created a text object or editing a text in objects the Text Formatting-toolbar is already opened. A simple Edit style-function should highlight the toolbar (you maybe know it from Web 2.0 applications) and the changes you now directly making on the Text Formatting-toolbar will be stored into the style instead of being hard coded only for this box. You won't need for simple changes (color, font, size, italic, bold, ...) the additional dialog and all the tab pages.

Status: Request for Comments

Mockup

Detailed Description

What and How

The toolbar(s) need to have a simple, well designed button for Edit style (not on mock-ups)

After pressing that button Edit style items which can be used for change a text style needs to be highlighted and also the toolbar needs to be more in front (in the mock-ups used float-feature of toolbars as one idea)

Also the style name should be displayed

the edit area needs to be locked but if an item on the toolbar is switched the text object should be changed like a live preview

The main toolbar, the slide panes ... should be put into the back

If Edit style is pressed again the edit area should be available again and the toolbar should look like before

Why

Instead of introducing a different dialog for editing the style of a text the well known toolbar is being re-used for it. Web 2.0 application doing this to save resources.

From user experience view it makes sense not to introduce additional dialogs when doing the same work. The user just want to change the text. He wants to change it not for one text object he wants to do it for many in his presentation (or any other kind of document).

The main reason for changing the UI from my point of view would be to reduce complexity. Mouse clicks are a good metric to see how complex it is to get a job done. Also the items you will get and where you have to make your selection is a big complexity issue (e.g. to select a tab page when 3 are visible at that time is easy; to select the correct tab page when 14 tab pages are visible is more complex). I have marked these barriers in ther numbering below.