Re: [Libreoffice-ux-advise] Option for gridline display in Calc (fdo#30800)

On Sun, 2011-07-10 at 22:07 +0200, Christoph Noack wrote:

> Just as a side note: I'm currently a bit unclear whether we balance the
> issue of "Excel compatibility" vs. "LibO consistency" when changing
> behavior. There have been some changes already that make it harder for
> users of other LibO modules to simple re-use their knowledge. What is
> the current design direction?

What we do is to keep both camps happy.  Excel compatibility is
extremely important for enterprise users for document migration point of
view.  If migrating from Excel to LibO Calc changes document behaviors
then that's a show stopper for them.  Of course, we can't ensure
identical behaviors in all cases wince Excel and Calc are two different
products in the end, but we would like to treat it somehow seriously.

With regard to LibO consistency, I need to ask you to clarify on this.
Do you mean this in terms of "consistent with the old behaviors of
previous versions of LibO / OOo", or consistent with the behaviors of
other features in the same version?

As for the current design direction, I would like to keep both camps
happy as much as we can.  If that's not possible then I would like us to
make a decision based on "what makes most design sense" and/or "what
makes it simpler and easier to maintain implementation-wise", and strike
a balance between the two in the end.  So, I'm afraid that, from my
point of view, each case should be approached differently.

> > I prefer removing the global setting because I believe it's redundant,
> > at least internally.  I'll explain more below.
> >
> > > So - in case you remove the per-application option, how would you
> > > migrate old settings? Just drop them? Migrate them to per-sheet options?
> >
> > Migrate them to per-sheet options.  Right now we have two settings to
> > control visibility of sheet grids, the global one and per-sheet one.
> > Also more confusing is the fact that, when the global grid visibility is
> > off, toggling the per-sheet visibility will not do anything.  Now, if we
> > continue to have these two separate options to control the same
> > visibility, we would have to define how the behavior should be when the
> > global and the local settings have different visibility values.
> > Personally I don't want us to go that route for simple things like grid
> > visibility.
>
> Mmh, the question is why there is such a wrong behavior? Although I'm
> sure that no implementation is perfect, I'm a bit unsure why this hasn't
> been discovered before ...

That's probably because this feature itself comes from Go-OO, and was
never in the Sun OOo before.  This is for historical reasons, and was
not really worked on to improve this situation since the inception of
LibreOffice, simply because of lack of time, until now that is.

> Since I got confused by this behavior as well, I started some rough
> investigation to get an idea about the problem. Here, I talk about the
> shipped version of LibreOffice, not the changes introduced by André.
>
> Some questions:
>       * How does the new grid behavior relate to the print options? Do
>         printed grid and viewable grid behave the same (with regard to
>         cell background colors)?

They are not related.  Obviously in most spreadsheet programs, grid
lines are shown by default, but they are not printed by default.  So, I
consider that the default expected behavior.  There is an option to
allow printing of grid lines, and it's off by default.

>       * Is the grid dependent from the high-contrast mode (e.g. is the
>         grid shown always if high-contrast is "on")? So having a "show
>         grid every time, no matter what" might a11y relevant.

This I don't know for sure.  I'm pretty sure it's independent of high
contrast mode, unless OOo implemented it differently.  I personally
haven't modified this behavior from the OOo baseline.

> Besides the issue you've already mentioned (global vs. local settings),
> here are some more:
>       * It is unclear to the user what is the default grid visibility
>         setting if a new sheet is created - at least if we remove the
>         global setting (currently you may have turned of the grids in
>         all sheets and add another sheet: grid "on").

Default grid visibility should be on from my POV.  That's what most (if
not all) spreadsheet programs do, and that's what I would expect.  BTW
in case it wasn't clear, the grid visibility gets stored with the
document.

>       * The location of the button seems wrong - it is part of the
>         formatting toolbar which (according to the recent documentation)
>         "contains basic commands for applying manually formatting."
>         Moreover, I don't find any documentation explaining the feature
>         and how it relates to the other grid settings.

Yes.  I'm aware of this.  I put it there to have it easily discovered.
BTW, this is in fact a very old feature of Go-OO.  It was first placed
probably around 2.4 or 3.0.  There was even a bug report for this (in
Novell's bugzilla) which I haven't had the chance to fix.

>       * The tooltip is very long and therefore inconsistent to the other
>         tooltips for Toolbar elements. Unfortunately, the "Extended
>         Help" is missing completely.

Ok.  The reason extended help is missing is for technical reasons.
Extended help is buried inside the help content XML file, and because
this feature was always kept as a patch in Go-OO, and patching a help
content is a huge pain, it was never done.

But we don't have that constraint right now with LibO, so I'm more than
happy to solve this issue.

>       * It seems that there is no equivalent for the switch within the
>         remaining UI. Toolbars are usually "shortcuts" to often used
>         functionality - they should not contain functionality only
>         available there. --> Although access via F6 is generally
>         possible, this is somehow an a11y issue.

Agreed.

> And one things that I personally think is required to work on: Why is
> this a separate button shown per default? Currently, there are some
> efforts to reduce the number of less used toolbar items.

For discoverability, at least at the time this feature was introduced.
We wanted a pretty screenshot with the icon for this feature. ;-)

> A general remark: Independent from why Microsoft enabled this behavior,
> it seems purely wrong from a high-level perspective. In the UX world, I
> don't know any case where the general visibility of markup elements is
> controlled by the formatting of the content. Markups are markups.

True.  All I can say is that, unfortunately, certain segment of users
have dependency on this behavior, and it was solvable.

> Looking at the number of issues (which is enormous given the size of the
> "feature"), I agree with André. We should decide what we want to have
> (generally), rework it, do some more QA here, and enable the
> documentation team to create some consistent help.
>
> Addressing single issues doesn't help here that much ... otherwise we
> would (e.g.) start to document sub-optimal behavior.

So, I take that you and Andre prefer just leaving this behavior as-is
for now, until we re-work this the right way later?  I'm fine with that.

> So, Kohei, André, how to continue?

Based on this thread, I think we should first have the complete picture
of how the re-work would look like, then decide on the details (whether
we implement it in full, or do it in steps etc).

That's my take.

Thanks a lot for your input, Christoph.

Kohei

-- 
Kohei Yoshida, LibreOffice hacker, Calc
<kyoshida@novell.com>