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

Hi everyone,

2012/1/19 Christophe Strobbe <>

Hi Graham,

At 03:09 19-1-2012, Graham Lauder wrote:

On Thursday 19 Jan 2012 00:22:11 Christophe Strobbe wrote:
At 03:47 18-1-2012, Andrew Pullins wrote:
Im for the one button being a drop down, iv been wanting this to be one
button for some time. to me the slider/button with a slider drop down
sounds like a bad idea.

My main concern is whether new UI widgets are keyboard accessible and
screen reader accessible. A slider is a bit more complex for a screen
reader user.

A more general question raised by all those toolbar buttons: how can
we modify the UI to encourage the correct use of styles (as opposed
to direct ad-hoc styling)? Does anybody have ideas about that?

Stop people from using MSO first :)

Take styles out of the tool bar or replace it with an indicator ie It
the styles in the present context but clicking on it opens the stylist
rather than allowing styles to be applied from the dropdown.

I find it very important to be able to see what style is in use at the
current editing location (that is what I hate about the MS Office Ribbon:
as soon as you leave "Home", you can no longer see what the current style
is unless you open the Styles panel or the Apply Styles panel), but opening
the Style pane when you open the Styles drop-down list sounds like a bridge
too far for me. Keyboard focus would need to be handled very carefully for
blind users and other keyboard users. It is also potentially confusing for
magnification users, because not all magnifiers follow the focus when a new
window, pane, etc opens.

I would think opening the style pane would discourage more users from
using styles, since the user could no longer apply a style quickly without
a huge pane taking up his precious screen real estate.

Fonts and sizes are features that, in most situations, should be done with
styles rather than hard-coded. My advice would be to change the font
drop-down into a font icon and decrease the width of the font size icon
(right now, it takes 6 decimal places, and LibO can only go up to "999.9"
anyway) to decrease their prominence as well as allow room for more
commands on the toolbar. Furthermore, these two items should be moved after
after "bold", "italic", and "underline", as those are used more commonly.

That's not really a solution, though. Styles need to be cleaned out.The
styles drop-down needs previews. The style drop-down needs to be made more
powerful, as powerful as the style pane: a user needs to be able to add and
edit styles from here. In my Citrus UI proposal, I have a separate style
drop-down for each selection type, so it's easier for users to distinguish
whether the style they're applying will be applied to the paragraph or just
the selection and so that they can access more styles easier. I also
applied a color to the buttons, so that they're more prominent and easier
to target.

 Have the stylist pane docked by default on the right for left to right
flow. Left dock is too intrusive for normal work flow. Symphony does this
rather well.

Yes, I like this. (In LibreOffice, I typically have the Navigator and the
Styles and Formatting pane docked above each other on the left).

 Do away with "Default" template and have multiple available templates at
install. First run then would have a "choose your normal template" dialog
something like the "Master Pages" dialog in Impress but with an obvious
"create your own" option. That would show off basic document elements
such as
Title, Heading, sub head, text body, para indents, font faces, list
styles and
page styles and maybe headers and footers.

Sounds good, but many people configure Impress so it doesn't start with
the wizard; they might do the same with a similar wizard. If you only run
this wizard on the first run of Writer - as you seem to be suggesting -
that should be OK. The trick is then to make the concept of styles as clear
as possible.
(I'll come back to this when I have more time and ideas.)

I would leave wizards out of this: if a user just needs to create a simple
document, it only serves as an annoying barrier, not as a helpful feature.
If the user chose to not show it again, he might also have trouble finding
it again when he needed it.

Document themes would solve this brilliantly -- let's hope they get
implemented. See

 Install a large wet rubber glove that jumps out of the screen and slaps
when they try to format on the fly.

I would prefer electric shocks through the keyboard - think of Stanley
Milgram's "obedience to authority" experiment ;-)

For most use cases, hard-coding is actually the better option than styles,
since it's much faster. (If the user suddenly realizes he needs to
italicize and underline all the bolded items in his document, he can just
use "Find and Replace".)

 OK trying to code the last one might be a bit of a challenge, but it is
something that would be an excellent behaviour modification tool. ;)


Best regards,



Christophe Strobbe
K.U.Leuven - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
B-3001 Leuven-Heverlee
tel: +32 16 32 85 51
Twitter: @RabelaisA11y
Open source for accessibility: results from the AEGIS project
Please don't invite me to Facebook, Quechup or other "social networks".
You may have agreed to their "privacy policy", but I haven't.

Unsubscribe instructions: E-mail to 
Posting guidelines + more: http://wiki.****
Netiquette <>
List archive: 
All messages sent to this list will be publicly archived and cannot be

Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


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.