[Libreoffice-ux-advise] Header and Footers separators design

[cedric.bosdonnat.ooo at free.fr]

Hello Christoph,

----- Mail original -----
> De: "Christoph Noack" <christoph at dogmatux.com>
> unbelievable ... at least for me: after several weeks I've finally
> managed to have a running libo-daily :-) So let's get back to work
> and
> have a look on your fine changes.

Cool!

> Am Donnerstag, den 18.08.2011, 14:42 +0200 schrieb Cedric Bosdonnat:
> > On Wed, 2011-07-06 at 09:52 +0200, Cedric Bosdonnat wrote:
> > I just moved the color definition to the options in the master
> > branch:
> > http://cgit.freedesktop.org/libreoffice/core/commit/?id=d40dce0f0f00b88dd645a0f334e3d7b2d6af6515
> > 
> > I also changed the way the colors are defined: you define the main
> > color
> > (the one of the line) and the background color is that color with
> > the
> > luminance multiplied by 2.5. I tested with several colors and it
> > looks
> > quite nice in those cases too.
> > 
> > I hope this helps to make it a nice feature,
> 
> Thanks! At the moment, I'm thinking about how to make use of that -
> we
> have several hard-coded elements that would benefit if we could share
> those color(s).

What are you thinking about? Those colors are already shared in the options... or there is something I don't understand

> So, what was the real intention of the feature - please bear with me
> if
> I didn't get it so far. Here some proposals to choose from (or to add
> one):
>      1. It should be avoided that people accidentally enter the
>         header/footer and "destroy" the given content / formatting
>         (on
>         several pages at once).
>      2. It should be avoided that people are distracted from headers
>      /
>         footers when writing on the document content. Thus, the
>         remaining elements get grayed out when not working on them.
>      3. It should be avoided that people don't know what kind of
>         header/footer they are editing.
>      4. 1 ... 3 at once

First it was #1, but then the user/customer requested the separator thing... so I guess they were way too used to that thing. I wasn't really found of that UI thing... but you know how customers are ;)

The original problem was that we had tons of .DOC documents with an enormous picture anchored as background in the header to live with. In a lot of cases, clicking in the document body picked the picture instead of picking some paragraphs... that's why I needed to avoid the user to mistakenly click on the picture from the header / footer.

> So, given all the alternatives, the current implementation misses
> some
> bits and pieces. From my POV, #1 could be solved differently, #2
> de-WYSIWYGs Writer, #3 could be solved differently. Personally, I
> really
> need to know what was the original requirement ...

I agree with the de-WYSIWYG-ation of Writer, do you have an idea to show that more clearly? I have to admit that I had to hack the painting quite intensively to get it working in almost all cases... and I'm not too proud how some bits in that area.

I'm ready to make it better, though I spent quite a lot of time and energy to make it working almost nicely and would be quite disappointed if I had to throw it all away. 

> Some of the things I've noticed:
>       * Enter: It is hard to identify how to enter the header /
>       footer -
>         the given visualization (borders) highlight active text areas
>         that can be entered via one click. But these areas are
>         inactive ... unless the user double-clicks (which is not
>         visualized to the user).

Is there anything we could do to make it easier to identify?

>       * Abort: It is hard to identify how / and cumbersome to go back
>       to
>         the document content. In contrast to MSO, there is no
>         visualization / hint how to do that. Examples:
>               * Double-click is unusual (in LibO) and there is no
>               visual
>                 clue

What kind of clue / mechanism would be more natural to users then?

>               * Although single-click doesn't work to go back to the
>                 document content, right-clicking once works - why?

Doh! that's a bug / something I missed in the implementation.

>               * ESC in header/footer goes back to the last position
>               in
>                 the document, but: if the user moved to another page
>                 in
>                 the meantime, it jumps to the old location

Where should it go to in those cases? Should it be moved to the beginning of the current page in all cases?

>       * Usability issues:
>               * I've noticed (as Cor pointed out) some issues, e.g.
>               it
>                 doesn't work well with Notes. For example:
>                       * Edit the header content
>                       * You can change into an existing note with
>                       single
>                         click (is that different to the document
>                         content?)
>                       * For exit, press ESC - the cursor is moved
>                       back
>                         to the document, but the content is shown
>                         inactive (although I can edit it) --> users
>                         get
>                         lost
>               * It also doesn't work well if headers/footers are
>               removed
>                 when editing them ... all the highlighting stays (the
>                 banner and the grayed out document). --> users get
>                 lost

Ok, those are clearly bugs and I need to fix them.

>               * I think the "Edit - Headers&Footers" behavior is a
>               bit
>                 strange. Its deactivated, if there is no
>                 header/footer
>                 on the page. But, its activated if either header or
>                 footer is there. Then, the missing item gets
>                 highlighted
>                 anyway ... without providing a clue how to really add
>                 this missing element. --> could be more supporting

An option here is to enable that menu item in all cases. If triggered when there is no header/footer in the document, then it would add them to the current page style. How does it sound?

>       * Technical issues: In my test environment (Fedora 15,
>         VirtualBox), I regularly have ghost cursors showing up - if
>         you
>         change the mode when the blinking cursor is shown, it doesn't
>         get removed (e.g. entering the header from the document, the
>         document keeps a non-blinking cursor).

Could it come from the fact it's in a virtual machine? I had that fixed a while ago... but I may have missed something.

>       * I'm still thinking how it should work in "facing pages" mode
>       ...
>         --> the common elements are usually mirrored in such
>         situations

Ouch... I haven't though about that case! There may be some tricky cases there.

>       * The feature could (as already pointed out) be more helpful if
>       we
>         actively show options like "exit, add header/footer, remove
>         header/footer", ...

Sure! Where would they be best to be placed? In some menu, a toolbar or somewhere else?

> Argh, just to mention that, beginning on Thursday, we'll have our
> family
> vacation until the Hackfest ... and there won't be any Internet
> connection, as far as I know.

Hackfest will be a good time to brainstorm lively on that :D

--
Cedric