[Libreoffice-ux-advise] [Bug 91415] Improve design of comment indicators to block less of the cell's content

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=91415

--- Comment #8 from ady <adylo811517 at gmail.com> ---
(In reply to Cor Nouws from comment #7)
> (In reply to ady from comment #5)


> Is it that there may never be any overlap in the content and the indicator?

No, of course I'm not demanding that; just that the current workarounds be
still available, especially the zoom, as it is the easiest to temporarily
apply. The current change seems to prevent it.

> Or..?
> Can I see images/examples somewhere of what works and what not?


First, apologies for the long text that follows, but this matter needs clear
debate (as shown by the several bug tickets, many comments, and prior attempts
of resolutions back and forth).

I have encountered some case with the comment indicator blocking some text or
number in a cell at some point or another in my life. Usually, I am able to
overcome such situation by means of zoom. Using the zoom is something that I am
used to use frequently, for other reasons, so it is natural for me to use such
method. Other users might not even think about that, so they might think that
they have a critical UI issue. There is very little mention of using zoom in
the related bug reports (which might indicate that they don’t even try it or
think about such alternative).

Other workarounds, besides those I already mentioned, can be text alignment,
indentation and border padding (all of which I also use for cases such as
filter arrows blocking text, either within or around the boundaries of the
filtering cell).

When I saw the wording, "scale…", I went and asked Heiko Tietze in irc
#libreoffice-design, and the screenshots and video provided show that, no
matter the zoom, the resulting text is still covered by the indicator. This is
not what happens as of LO 7.4.4, in which, most frequently than not,
temporarily changing the zoom can resolve the relatively minor problem – I say
"relatively minor", because it can be easily overcome by several
currently-available methods. It is still in the hands of users.

By changing the indicator to grow when we use higher values of zoom (i.e. part
of scaling it), which is part of the change according to the screenshot that
Heiko Tietze showed me, a relatively minor problem for some users in some cases
can turn into a permanent inconvenience (especially to visually challenged
users) that has no easy workaround (because no matter the zoom, if the
indicator covers a text, it will cover it under any zoom value once the change
is committed). There will be no longer an easy workaround in the hands of users
(especially if the file is read-only, when other properties cannot be modified,
but the zoom is yet available).

Having some artifact covering some text is not an exclusive issue with the
comment indicator. There is help text showing under the mouse pointer, and/or
filter arrows, just as common examples. The user has sometimes some method to
overcome or correct the situation (e.g. for filter arrows, and for comment
indicators), but sometimes there is no workaround (e.g. mouse pointer over help
text). The resolution proposed here seems to make useless the easy workaround
currently available (as of LO 7.4.4.), and will not solve the issue really (as
shown in the screenshots that Heiko Tietze provided in irc).

For example (of what _not_ to do), making the indicator just one color (i.e.
with no border of another contrasting color) would make it smaller, but such
hypothetical change clearly clashes with using a similar background color for
the cell or for the cell’s border, so you should _not_ make the indicator
one_color_only and without its border (i.e. its border, with a different color,
must remain).

If you can make the indicator smaller but still visible (e.g. triangle, still
with a border of a different color), then that’s an improvement (in UI) that
shouldn't affect negatively other users. Perhaps if the indicator can be partly
transparent (the alpha thing that was suggested before) then both objectives
can be maintained(?): the text can be clearly seen, and the indicator can be
clearly spotted.

It is possible that just making it a triangle is enough, in which case no new
bug enhancement requests would show up (and so, going step-by-step towards a
resolution can be helpful, rather than applying several changes at one time,
risking some unnecessary negative side-effects).

Reading prior tickets (some of which I already linked to) on the same subject
and prior attempts to improve the situation, demonstrates that there is some
balance to consider, and that some changes that are centered on the comment
indicator alone can negatively affect other aspects of UI and usage. Since I
have to rely on using the zoom more often than not (and the comment indicator
is not nearly the main reason for it, by far), I am perhaps more aware than
others that using the zoom can be an easy workaround for the matter in question
in many occasions, while scaling the comment indicator seems to have (according
to the screenshots that Heiko Tietze showed me) detrimental consequences. When
users would write to complain that, no matter the zoom value, the indicator
still blocks the text behind it, then one workaround that is available as of LO
7.4.4 would be gone, and a solution for that newly created situation would have
to wait for another 7 or 8 years (I wonder?). (Just in case, I don’t mean to
sound rude or to complain; I’m only writing what I worry about, since the very
instant I read the "scale…" phrase.


So, triangle, with border, 2 different colors (one for the triangle, another
color for its border, as it is now for the square), with some degree of
transparency. Maybe introducing the changes step-by-step (first the shape, then
the transparency) instead of all at once? I don’t know whether there are
negative effects (such as more resources needed just for displaying the
indicator, instead of using them for calculation power, for instance?), but
others can comment on those.

Now, if what I am describing that I saw in the screenshots is just my
misunderstanding, and the comment indicator will _always_ be smaller than what
currently is at any_and_every zoom (I am no stranger to 200% zoom, sadly) and
DPI scaling factor, then please accept my apologies for the noise.

-- 
You are receiving this mail because:
You are on the CC list for the bug.