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

Hi Christoph, Astron,

Here is a small update to tell you that we have some progress.

On Wed, 2011-08-24 at 00:18 +0200, Christoph Noack wrote:
> By the way, I played a bit with the colors and noticed that if you
> select black, then everything (border, text, fill) is drawn in black.
> When selecting dark green, the fill gets a very intensive light green...

Fixed.

> However, one thing that drives me mad is the ghosting - you've clarified
> for Astron. Let's pick the use case that people anchor pictures in the
> header/footer to use them in the page background - then the picture is
> dimmed when editing. Thus, it gets very hard for users to really judge
> the contrast of foreground/background. Consequently, this is an
> accessibility/usability issue then.

I completely reverted the ghosting.

> Okay, so let's start to draft a proposal together ... I've made up a
> quick sketch:
> https://picasaweb.google.com/lh/photo/NUEuQ6j9CINyL_MSY67zUg?feat=directlink
>
> The core ideas:
>       * Document content does not get altered (ghosting) to keep the
>         visual impression for the user. (Note: If the headers/footers
>         are disturbing, then we need a "Draft" view or users should use
>         the "Web View").

This is fixed as mentioned above.

>       * Accessing the headers/footers is possible without double-click
>         (a single click is sufficient). To prevent unwanted changes of
>         the header/footer, your visualization is used to explain what
>         this is about. In this case, the header/footer work the same way
>         as the document content, frames, tables, ... its consistent. So,
>         luckily, we can avoid another "mode" - although the "go back via
>         ESC" might be kept.

I had quite a hard time implementing the single click behavior as I
found out another usability bug: the background pictures were not
selectable at all.

Anyway, this is now implemented. The text boundaries are also shown only
for the edited area to highlight it even better.

>       * Visualization (separator):
>               * If a header/footer is available (see the upper part),
>                 then the tag is attached to the header's border. This
>                 matches the position of the real header. And, it
>                 prevents the unwanted drawing effects Cor once mentioned
>                 if distance header/document content is zero.

The zero-distance case will alway be a problem. I left it as it is as
discussed during the Hackfest.

>               * If no header/footer is available (see lower part), then
>                 the potential footer area is marked. Thus, the user may
>                 use the options button to add a footer there.
>       * Options button: As you and others already pointed out, it would
>         be a chance to make things easier to use. I'm still not sure
>         whether we'll use the "Notes" like drop-down, or whether we will
>         add the most common actions directly to the tab (is also a space
>         issue)

Button and dropdown menu on the separator label is still not yet
implemented: that's the next thing I'ld like to work on.

> So, the only thing that's still unresolved is the "users can select
> items anchored to the header/footer too easily". So, if this is an edge
> case (I assume), then might the following proposal work form an
> developer's point-of-view?
>       * If the focus in within the document are, and if an object is
>         anchored in the header/footer and is placed on the document
>         content area (maybe: only if document text is there as well),
>         then it will only react to a double-click (like your
>         implementation). Because ...
>               * We might add a tool tipp to explain that: "Double-click
>                 to edit"
>               * If single clicking doesn't work, most users react with
>                 repeated clicks - finally it will get selected.

Done, but no tooltip at the moment and a minor selection issue.

>       * If the focus is within header/footer, then editing of those
>         objects should be possible with a single click (like you've
>         already implemented it).

Done.

>       * Here, users should be made aware what's happening - so if these
>         items get edited, then the header/footer highlighting should be
>         shown.

Done

> Details are missing:
>       * Design of the tabs - they need "direction" (e.g. two rounded
>         corners) and a detailed options buttons layout.

As discussed a gradient will be added... but when the rest will be
already in a good shape.

>       * Position of the tabs - it might make sense to move them into the
>         visible area, if the user won't see it due to the current zoom
>         level / viewport.

This was quite a pain for me to implement, but I finally found out that
Notes' code was of great help for this. I had it working in the Geneva -
Lyon train back from Hackfest.

>       * Mouseover - it might make sense to respond to hovering
>         header/footer areas by showing the tabs or something like that
>         after some time. Then, the options are directly available for
>         the users - even if no headers/footers are available.

Good idea, but not implemented yet.

>       * If people don't like the document borders (e.g. for the
>         header/footer), then we should check whether all should be
>         replaced. Once I made a proposal that got implemented into
>         Symphony ;-) Here is the proposal page:
>         http://wiki.services.openoffice.org/wiki/DocumentBorder

I implemented the option 3 here. I also simplified the boundaries mark
when there are footnotes in the document: the footnotes are included in
the main body area. It shouldn't harm, doesn't seem too stupid and avoid
having too many decoration items when there are several footnotes in a
document.

Those changes have been pushed to master... so you can get them with the
next daily build.

Regards,

-- 
Cédric Bosdonnat
LibreOffice hacker
http://documentfoundation.org
OOo Eclipse Integration developer
http://cedric.bosdonnat.free.fr