[Libreoffice] [UX] Some dirty stuffs around styles in calc

Christoph Noack christoph at dogmatux.com
Mon Dec 6 14:54:27 PST 2010


Hey Cedric,

thanks for having a look at that. And thanks for the good explanation!
It took me a while, since the problem is not only valid for Calc, but
also valid for all elements/documents that support protection.

I had a look at the OOO issue tracker and, wow, this seems to be on of
the ancient issues of OpenOffice.org; issue 4679:
http://www.openoffice.org/issues/show_bug.cgi?id=4679

Am Mittwoch, den 01.12.2010, 14:38 +0100 schrieb Cedric Bosdonnat:
> Hi all,
> 
> The other day when playing with a calc document, I discovered an
> annoying "feature". Create a new spreadsheet, protect one of the sheets
> and try to modify the cell styles: nothing shows up when clicking on the
> "Modify..." context menu.

Yes, same for me (of course).

And just for the record: If I try to change the content of a protected
sheet, then a message pops up that explains that changes aren't allowed
within protected sheets. Not that nice, but at least some feedback/
explanation.

> I had to run a debug session in sc to understand that the problem was
> caused by a protected sheet... which obviously normal users won't do. I
> see here several usability problems:
> 
>  1/ The "Modify..." context menu should be at leat unactivated
>  2/ You can still create new styles
>  3/ You can't even edit styles that aren't applied in the protected
> sheet
>  4/ There is no visual feedback for the user to understand what happens

Mmh, 2 is causing real fun - you can add more and more styles, but won't
be able to ever delete one of them :-\

> What's your take on this? Christoph, do you have any idea to improve
> that thing?

My problem: I have plenty of ideas to improve that, but all the ideas
can be assigned to a range between "quick but less elegant fix", and
"high-quality long-term proof solution" ;-)

So I just add some ideas ... and it would be great if you could judge
what kind of "solution" you are thinking about. Especially, since we
(all) have to decide within the next time, what kind of "product
strategy" will be the best for us (including our users).

However, let's start ...

Example 1.1: Simple Dialog

        If a protected cell style shall be changed, a dialog is raised
        to explain that it is used on a protected sheet. Nothing can be
        changed (or even viewed). The user has to un-protect the
        sheet(s) first.


Example 1.2: Introducing Some Good Manner

        Like Example 1.2 plus: The restrictions only apply to the cell
        styles that are really used on protected sheets. All remaining
        cell styles work like usual.
        
Example 1.3: Showing What's Going On

        Like Examples 1.1 / 1.2 plus: If a cell style is protected, then
        a small symbol gets shown in front of the Cell Style name (e.g.
        a small lock symbol). This informs the user in advance that
        something might not work.

(now, going towards the long-term proof solutions)

Example 2.1: Workflow Optimized Solution

        If the user opens a document that contains protected sheets,
        then a non-modal message [1] gets shown that explains that some
        of the editing features are disabled. (Maybe very similar to
        [2]). This message may belong to a LibO wide framework that
        provides a) automatic hiding these message bars after some time,
        b) not showing these bars at all (e.g. if the original author
        opened that document, or if users don't want to see something
        like that).
        
        The user interface marks those items that are locked within the
        current "environment" (may it be cells, sheets, or even the
        whole document). But, all the items can be executed, because ...
        
        If the user tries to use currently unavailable features, he gets
        some request (dialog, message bar, ??? - in the best case it
        would be modeless) that enables him to:
              * abort/ignore the current limitation
              * disable the protection temporarily
              * disable the protection completely
        
        What might be checked with users and within common workflows:
        Does it help if - if the protection has been disabled
        temporarily - that the protection may be re-activated again when
        a) saving the file, or b) asking the user when he attempts to
        close the document.
        
        Note: The non-modal messages currently brainstormed within the
        OpenOffice.org UX team might help here as well (see [3],
        virtually add some control elements *g*).

The last example involves a lot of framework changes, but - and this is
the good message - would enable a well defined behavior for all the
applications within LibreOffice. What do you think about that?

Concerning the framework and workflow stuff; I'm sure we'll touch this
topic more often in the future ... so it would be great to know whether
we might think about such larger changes in general. Otherwise we fix
only tiny bits and pieces (which is more than okay for a while...) but
missing the whole picture. Still thinking ... comments anybody?

But, Cedric, back to your initial question. Did that help? How do we
want to continue?

Cheers,
Christoph

[1] http://luxate.blogspot.com/2010/11/non-modal-messages.html

[2]
http://wiki.services.openoffice.org/wiki/File:DiMaS_Document_PasswordProtected.png

[3]
http://wiki.services.openoffice.org/wiki/User_Experience/Projects/NonModalMessageSystem#Step_2_-_Message_Style_2a



More information about the LibreOffice mailing list