No subject

Thu Aug 25 07:12:44 PDT 2011

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:
> The core ideas:
> =C2=A0 =C2=A0 =C2=A0* Document content does not get altered (ghosting) to=
 keep the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0visual impression for the user.

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

> =C2=A0 =C2=A0 =C2=A0* Accessing the headers/footers is possible without d=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(a single click is sufficient). To prevent unw=
anted changes of
> =C2=A0 =C2=A0 =C2=A0 =C2=A0the header/footer, your visualization is used =
to explain what
> =C2=A0 =C2=A0 =C2=A0 =C2=A0this is about. In this case, the header/footer=
 work the same way
> =C2=A0 =C2=A0 =C2=A0 =C2=A0as the document content, frames, tables, ... i=
ts consistent. So,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0luckily, we can avoid another "mode" - althoug=
h the "go back via
> =C2=A0 =C2=A0 =C2=A0 =C2=A0ESC" 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 =E2=80=93 the
visualisation might not even be visible because the user is at the end
of the page).

> =C2=A0 =C2=A0 =C2=A0* Visualization (separator):
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* If a header/footer is a=
vailable (see the upper part),
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then the tag is at=
tached to the header's border. This
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0matches the positi=
on of the real header. And, it
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prevents the unwan=
ted drawing effects Cor once mentioned
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if 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"

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* If no header/footer is =
available (see lower part), then
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the potential foot=
er area is marked. Thus, the user may
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use the options bu=
tton 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..

> =C2=A0 =C2=A0 =C2=A0* Options button: As you and others already pointed o=
ut, it would
> =C2=A0 =C2=A0 =C2=A0 =C2=A0be a chance to make things easier to use. I'm =
still not sure
> =C2=A0 =C2=A0 =C2=A0 =C2=A0whether we'll use the "Notes" like drop-down, =
or whether we will
> =C2=A0 =C2=A0 =C2=A0 =C2=A0add the most common actions directly to the ta=
b (is also a space
> =C2=A0 =C2=A0 =C2=A0 =C2=A0issue)

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

> =C2=A0 =C2=A0 =C2=A0* If the focus is within the document area, and if an=
 object is
> =C2=A0 =C2=A0 =C2=A0 =C2=A0anchored in the header/footer and is placed on=
 the document
> =C2=A0 =C2=A0 =C2=A0 =C2=A0content area (maybe: only if document text is =
there as well),
> =C2=A0 =C2=A0 =C2=A0 =C2=A0then it will only react to a double-click (lik=
e your
> =C2=A0 =C2=A0 =C2=A0 =C2=A0implementation). Because ...
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* We might add a tool tip=
p to explain that: "Double-click
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to edit"
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* If single clicking does=
n't work, most users react with
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0repeated 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).

> 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 =E2=80=93 which I admit seems slightly counter-intuitive given the
selection behaviour I just proposed.)

> =C2=A0 =C2=A0 =C2=A0* If the focus is within header/footer, then editing =
of those
> =C2=A0 =C2=A0 =C2=A0 =C2=A0objects should be possible with a single click=
 (like you've
> =C2=A0 =C2=A0 =C2=A0 =C2=A0already implemented it).
> =C2=A0 =C2=A0 =C2=A0* Here, users should be made aware what's happening -=
 so if these
> =C2=A0 =C2=A0 =C2=A0 =C2=A0items get edited, then the header/footer highl=
ighting should be
> =C2=A0 =C2=A0 =C2=A0 =C2=A0shown.
> Details are missing:
> =C2=A0 =C2=A0 =C2=A0* Design of the tabs - they need "direction" (e.g. tw=
o rounded
> =C2=A0 =C2=A0 =C2=A0 =C2=A0corners) 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.

> =C2=A0 =C2=A0 =C2=A0* Position of the tabs - it might make sense to move =
them into the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0visible area, if the user won't see it due to =
the current zoom
> =C2=A0 =C2=A0 =C2=A0 =C2=A0level / 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

> =C2=A0 =C2=A0 =C2=A0* Mouseover - it might make sense to respond to hover=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0header/footer areas by showing the tabs or som=
ething like that
> =C2=A0 =C2=A0 =C2=A0 =C2=A0after some time. Then, the options are directl=
y available for
> =C2=A0 =C2=A0 =C2=A0 =C2=A0the users - even if no headers/footers are ava=

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

> =C2=A0 =C2=A0 =C2=A0* If people don't like the document borders (e.g. for=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0header/footer), then we should check whether a=
ll should be
> =C2=A0 =C2=A0 =C2=A0 =C2=A0replaced. Once I made a proposal that got impl=
emented into
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Symphony ;-) Here is the proposal page:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0

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.


More information about the Libreoffice-ux-advise mailing list