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

[Christoph Noack]

Hi Cedric,

just a small status update - do avoid any impression that this topic
slipped out of sight ;-)

First, I'm currently unable to have a look at the feature. The daily
builds still date 2011-07-04 (last check: a few hours ago), so I rely on
the descriptions by you and Cor. Thanks by the way for your patience!

Am Donnerstag, den 07.07.2011, 11:30 +0200 schrieb Cedric Bosdonnat:
> Hi Cor, Christoph,
> 
> On Thu, 2011-07-07 at 00:15 +0200, Cor Nouws wrote:
> > Christoph Noack wrote (06-07-11 23:10)
> > > So, do we talk about:
> > >        * when editing headers/footers, then a new visualization shows
> > 
> > Yes
> > 
> > >          what's getting edited:
> > >                * new line and "Header: $PAGE_STYLE" are shown
> > 
> > Yes
> > 
> > >                * the remaining document parts are grayed out (a bit)
> > 
> > Yes
> > 
> > >        * editing headers/footers starts via "double click" on the desired
> > >          area
> > 
> > Yes
> > 
> > >        * during "normal" document editing, access to the headers/footers
> > >          is not possible
> > 
> > Yes - and those are a bit grey too
> 
> So only thing that aren't mentioned here are some bugs that are still to
> be fixed:
>   * Some borders / lines aren't greyed out ATM. I need to hack the way
> these are drawn to fix it.
>   * When scrolling down in the document, if you stay too long on a
> header / footer it gets it as a double click and turns to edit mode.
>   * When opening a document, there are some troubles with the cursor
> location and viewed area... though that may not have been introduced by
> that hack.
> 
> One of the points to note for the feature is that I added a "Edit /
> Headers / Footers" menu to switch the edit mode.

Mmh, unfortunately that spreads functionality for headers/footers
several places three - since our menus is not object oriented, we now
have stuff located in: "Insert", "Edit", and "Format" (via Page). 

Besides that, it is just too many entries ... of course, it could have
been any feature requiring new menu items - now its headers/footers. But
it motivates me to find a way with you to keep a clean menu. (clean = as
stuffed as today)


> > > If this is correct, then a "-1" from my side to the whole package. I'd
> > > like to understand more about the issues we currently run into (e.g.
> > 
> > Issues we run into with the changes or with the current behaviour?
> > a.  with the current behaviour.
> > Not so many. Only since headers/footers are easily accessible, there is 
> > some change that they get changed by accident.
> > And the difference between main text and headers/footers is not that 
> > big. Especially when people turn of text borders (menu View), cause they 
> > do not know those from Word (where they are turned of by default).
>
> The biggest problem I encountered there that really motivated the
> feature is that when you have a background picture anchored in the
> header / footer that goes behind the main body text, you almost always
> select that picture if you click on blank areas of paragraphs, table
> cells and so on.
>
> With that feature it's no longer possible as the picture is anchored in
> the header / footer and you are editing the main body... it can't be
> selected.

Okay, I thoroughly read your description about the problem and see the
motivation - but my conclusion is a bit different. To me, it doesn't
seem that we need to introduce another mode that is different to normal
text editing.

What makes it a bit difficult for users is, that I assume that the
header/footer boundaries are still shown - wrong, since editing is not
possible right away. Remove them when editing the document content?
Might be wrong as well ...

Additionally, the "graying out" leads to a reduced WYSIWYG-quality -
colors in headers/footers are shown differently to those in the main
document. Furthermore, if e.g. a picture is anchored in the header and
moved to the main document area - will it be grayed out as well? If yes,
then it is weird - since people might ask why they get watermarks in the
document. If no, then it is weird as well - since the user still doesn't
know how to edit the picture (the anchor in the header is invisible, I
assume).

To me it seems, that the "user perceived" issues weight heavier than the
fixed issue itself. So if the motiviation is to prevent editing content
"by accident", then my solution would have been something like that:
      * Imagine the old LibO behavior for handling headers / footers,
        now ...
      * Case "User accidentally edits header/footer"
              * If the user clicks into the header/footer, then a decent
                visual indicator explains that he is editing those
                (thats how I understood the initial idea)
      * Case "User doesn't want to accidentally edit the picture"
              * If there is a picture that is located (partly) on the
                main document background then the part on the document
                is mostly "inactive"
              * A simple click on the picture in the main document area
                shortly highlights the header/footer by keeping the
                focus in the main document (--> guide the user, because
                of the behavior today)
              * A double click on the picture in the main document area
                (without interfering with any text or other object)
                selects the object as today (--> if something doesn't
                work with single clicks, people usually try all kinds of
                clicking, so we give them a chance for editing by
                reducing some comfort for text editing)
              * If the user clicks on the picture on a non-text area,
                then selection works as today (but: is up for
                discussion, since it would also work with the two points
                above)
              * If the user right-clicks on the picture within the text
                area, he may get an additional choice to edit the
                picture (--> Some people know what "context" means and
                use the context menu. This would be a rather clean way
                to indicate that the object can be selected - but
                doesn't work well for touchscreen computers and those
                users who don't know ... *G*)
      * Case "Formatting header / footer"
              * Additionally, we could do users a favor and tweak the
                header/footer editing a bit, so that they have a
                dropdown / menu / indicator / whatever to quickly get
                access to header/footer formatting.

Thus, although only roughly outlined, this solution avoids menu changes,
the visualization is kept as today (border and WYSIWYG), no need for a
further mode that requires (invisible) double-clicking by the user.


> > b. with the changes: see the other mail. No real that I have found so far.
> 
> Jbfaure reported me quite some crashes / usability issues that were
> fixed in between.
> 
> > > whether the preconditions - partly very different from MSO interaction
> > > design - support/enable such a change). One tiny example are the current
> > > gray separator lines - being shown all the time,
> > 
> > As written, that depends.
> > 
> > > although the content
> > > itself is only editable via a (hidden) double-click. Furthermore, do we
> > > run into accessibility problems? ...
> > 
> > Ctrl-PgUp/PgDwn still work.
> 
> I wasn't aware of those shortcuts... and I'll need to trigger the mode
> change on those. When hitting Ctrl-PgUp/PgDown the cursor moves to the
> header footer but it doesn't switch to the header / footer edition mode.
> 
> > > Sorry for lacking proper understanding at the moment ... and maybe
> > > delaying things. But I did not get the idea of the change in the mail
> > > yesterday. But, I'll promise to help to make this a cool feature :-)
> 
> Indeed, making it a really cool feature would be awesome!

I hope this helped a bit to understand my thoughts ... it would be great
if you could add yours, e.g. if I missed the point (because there were
other reasons for that implementation). It really helps me to get a
better understanding.

So, now I have to leave - day job is waiting. So, Cedric, Cor, have a
nice day as well!

Cheers,
Christoph