[Libreoffice-ux-advise] Header and Footers separators design
Cedric Bosdonnat
cedric.bosdonnat.ooo at free.fr
Tue Sep 6 02:48:44 PDT 2011
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
More information about the Libreoffice-ux-advise
mailing list