[Libreoffice-ux-advise] Header and Footers separators design
christoph at dogmatux.com
Tue Aug 23 15:18:03 PDT 2011
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
> 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
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
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
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
* 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
* 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
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:
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!
More information about the Libreoffice-ux-advise