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

[Christoph Noack]

Hi Cedric, Cor and Astron!

Sorry for not answering earlier ... currently I'm way behind some LibO
issues, headers/footers, family stuff. So please bear with me if replies
need a bit time. Or, please point out if something is very urgent to you
- this helps to prioritize may day :-)

Ah, and of course I've read the mails from you all - I'll try to address
some stuff during this mail. But for now, let's dig into the issue...


Am Montag, den 22.08.2011, 15:44 +0200 schrieb
cedric.bosdonnat.ooo at free.fr:
[...] 
> > De: "Christoph Noack" <christoph at dogmatux.com>
[...]
> > Am Donnerstag, den 18.08.2011, 14:42 +0200 schrieb Cedric Bosdonnat:
> > > On Wed, 2011-07-06 at 09:52 +0200, Cedric Bosdonnat wrote:
[...]
> > 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

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.

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


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

Okay, #1 seems to make absolutely sense to me - although I'd like to
address it a bit differently. I aware that the solution might be
slightly different to what Word provides, so it might not fully be in
line with your customer needs - but I hope they will agree that it
should fit with other stuff in LibreOffice and the remaining user base.

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.

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

Okay, but I'm a bit hesitant to change the basic behavior of Writer
because of one customer using foreign document formats that behave
strange. I assume one solution would have been to mark being
"background" pictures.

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.


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

True, true - I totally understand that :-( And to explain myself here: I
thought about this issue since weeks, since I knew that it was a lot of
work for your. Being quiet (in terms of mails) doesn't mean that such
stuff is neglected by myself. On the other hand, it would have been
great to get a ping when you've started the work ... to at least know
what changes might be waiting for us ;-)

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

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

Okay, this is the first proposal which tries to balance the current LibO
behavior and your needs - including all the nice things that can be done
with your implementation. Furthermore, it solves all the usability
issues I've pointed out in my last mail (but it may introduce new ones
I'm unaware of *g*). However, I have a positive gut feeling - maybe you
shar it. Even if not - please comment :-)

And, Astron, Cor, any major mis-thoughts on my side?

[...]

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

Ooh, coool! It seems that I really have to recover during the vacation,
because this will be topic number 3 or 4 to work on :-)

And before I forget that - please have a good trip to Munich. Most
probably I'm unable to reply until then ... tomorrow, I'll try to attend
the SC meeting (deputy stuff) and need to finish some private items.

Enjoy your night!

Christoph