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

Hi Christoph, Cedric, Cor, everyone else reading,

> > What are you thinking about? Those colors are already shared in the
> > options... or there is something I don't understand
>
> Oh sorry - I maybe mixed this issue up. Currently we have a lot of
> different colors for highlighting stuff in the system. Starting with the
> comments, spellchecking, ... till the colors for the selection of
> pages/slides in Draw/Impress. I thought some of these colors can be
> shared, so that it looks a bit more consistent. But, this seems less
> desired here - sorry.

Hm, I don't know what colour would be best for consistency here. I'm
not sure if the standard selection colour would really be fitting.
Unless we find something, I wouldn't consider the hard-coded blue
colour a problem (unless you are working on a blue background – maybe
adding a white outline in this case would be a solution, I don't know
if that's worth bothering with now).

However, I agree, the slide selection in the Impress sidebar should be
painted in the standard selection colour of the system. Both the
border of the selection and the highlight colour should be derived
from that... and that's a completely different bug.


> By the way, I think that the separator might be indeed helpful -
> although it is still not the header that gets separated. A bit
> nitpicking: the separator highlights the margins, the header is only a
> sub-area.

From my point of view, ideally the separator (I like it, too!) would
be in the middle of the margin between header/footer and content. This
way, it wouldn't clash with any content in most cases. But I see why
that would make things a bit harder to implement.


> 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.

I have an idea about this, but I am not sure it's any good. goto [1].


>      * 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 second this, with maybe the addition of the double-click area I
propose above (because I don't think the visualisation is enough,
especially in the case of a "background" image you described – the
visualisation might not even be visible because the user is at the end
of the page).


>      * 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.

I like the separator, actually, it makes the area much more visible.
And those drawing effects can probably also happen with only a "tag"
present.

>              * 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.

Contrary to the mock-up you provided, I think the tag in the footer
area (when there is no footer) should read "No footer" (not "Footer:
Default") and then next to it should be a "+" button to add one (or
maybe "+ Add"). No menu there as I couldn't imagine what other items
might fit..

>      * 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)

Yes, please reuse the Notes-style drop-down menu. We shouldn't make it
harder to see where there are clickable areas and where there are
none, so an already known element might be helpful (I am not really a
friend of buttons that don't look native, but if we have to use
something non-native, it should at least be known from another
context). It's also more scalable.
Items for the drop-down I can think of right now:
* "Edit document content" (or something similar that jumps back to the
main content area)
* "Header/Footer options" (leading to Page Style's Header respectively
Footer tab)
* "Remove header/footer".


>      * If the focus is within the document area, 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.

I don't know if I just had the same idea independently or not, but I
like this two-area idea. And I think the part overlapping the content
area should react only on double-clicks (even if there is no text).

[1]
> 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.

Hm ... that's true. Can the two different selection areas also look
different? (The part in the header/footer area lighter, the other part
normal – which I admit seems slightly counter-intuitive given the
selection behaviour I just proposed.)


>      * 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).
>      * Here, users should be made aware what's happening - so if these
>        items get edited, then the header/footer highlighting should be
>        shown.
>
> Details are missing:
>      * Design of the tabs - they need "direction" (e.g. two rounded
>        corners) and a detailed options buttons layout.

I like them square... it also makes adding a drop-down button easier.
If the tabs are hanging from / sitting on a dashed line, that's
probably enough.

>      * 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.

* For the horizontal position of the tabs it makes sense that they
should sit at a fixed number of pixels from the right corner of the
current document view.
* The vertical positioning should be fixed on the page IMHO. And the
page should scroll up/down enough to show the tabs and the header
respectively footer in question. Of course there will be corner cases
where the header is practically more than a full screen page long and
this doesn't work. In this case, the divider probably can't be
visible.

>      * 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.

This is a very good idea. Is there code to let the tabs/separators
fade in smoothly? That would probably add quite a bit to the overall
impression.
I wonder, though, should the tab's drop-down menu then have an
additional element like "Edit header/footer" or not? (If it has,
people might not realise they can just click into the header/footer to
edit content.)

>      * 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

Oh wow. I wondered why that was different in Symphony when I tried it.
But to be honest, I think the Symphony solution looks a bit odd.
I'd like small plus signs on all corners and easily movable dashed
lines on mouseover...

> > > Argh, just to mention that, beginning on Thursday, we'll have our
> > > family
> > > vacation

I wish you an enjoyable holiday.

Astron.