[Libreoffice-ux-advise] new range name dialog proposal

Christoph Noack christoph at dogmatux.com
Mon Oct 24 12:46:08 PDT 2011


Hi Astron!

As promised ...

Am Montag, den 24.10.2011, 01:49 +0200 schrieb Astron:
> Hi.
> 
> I am probably sometimes out of my depth here, so bear with me if I
> propose unreasonable things. I had never used this feature until
> tonight.

And although I used it from time to time, Markus still surprises me with
the alternative uses cases :-)


> > The main idea is now, that there is no difference between the currently
> > selected element in the table above and the entries below. Example: If
> > the user clicks on an element and starts changing the name, then this
> > name will be changed "live" in the table above as well. Same for range
> > options or the expression.
> 
> So far, I like this.
> Still, a core point I would like to question about the current
> mock-ups is that there are a Define Names and a Manage Names dialogue.
> IMHO, there must be clever way of combining these. I'll try to think
> about an own mock-up.

I already saw your mail.

So why the separation ... my aim was to let people easily and quickly
add a new range name (there is a shortcut for calling that dialog). This
Define Name dialog should only use very few screen space. The Manage
Names is meant for organization / advanced use (non-modal).

Originally, I even wanted to provide a simple way to switch from the
Define Name dialog to the Manage Names dialog ... but I had to change
the Manage Names dialog (so that Adding / Editing names becomes more
clear), so that this doesn't work anymore.

However, I still think that separation makes sense.

> > Some more core behavior:
> >      * If the user wants to add a new name from the Manage Names
> >        dialog, then we now go to the "Add Names" dialog (that makes
> >        adding new names really clear).
> >      * If the user changes a name / expression in the Manage Names
> >        dialog and this entry is invalid ...
> 
> Can we restrict the characters that can be entered to the valid ones?
> Pressing an invalid key could simply result in nothing, except for
> maybe a slightly annoying beep (and non-modal information).

Oh, my colleagues would love to have such a beep when working in an
open-plan office ;-)))

As far as I know, it is currently not possible to know the characters in
advance, because the valid characters are influenced by localization
settings and some other stuff. We may only know that "something" is
wrong - any input has to be evaluated by the expression parser.

However, ignoring key presses might be possible in this case (first
checking, then ignoring), but I don't like that - it doesn't tell the
user what's wrong. And, many people do not look at the screen, so that
defining a name might be a surprise.

Finally, incorrect ranges (e.g. "A1:B") have to be covered as well.

But, will think about that ... maybe there is a better solution.

> 
> >      * The user should be always able to exit the current change with
> >        ESC (restores last entry before the started to edit the field).
> 
> Yes. And the change should be revertible with an Undo button (is that
> what the "Back" button is for?).

Yes. I assumed that people might run into problems rather often, so Undo
triggers (guess!) Undo. I placed it within the dialog, since this kind
of "non-modal" dialog is rather seldom in LibO. Maybe it is not needed
in the long-run.

> >      * If the user selects more than one entry, then ...
> >              * we deactivate the text fields (maybe even the Scope
> >                field)
> >              * Paste (or Insert, no terminology decision yet) inserts
> >                all selected items.
> 
> I hope I understand this correctly: it inserts the selected range
> names into the currently selected cell in a format like
> "Cappuccino;Chocolate;Cookies"?

No.

> Then, I see two problems:
> # "Paste" shouldn't overwrite text when the current cell was
> double-click/F2-edited before opening the Manage Names dialogue
> (otherwise formulas might be deleted). Is that workable?
> # How is it possible to handle inserting multiple range names
> correctly? Some format work in certain formulas and when using certain
> ranges, some don't, i. e. neither "Cappuccino+Chocolate+Cookies" nor
> "Cappuccino;Chocolate;Cookies" is possible in all cases. Is clever
> guessing based on existing formulas possible here?

Today we do have two options:
      * Insert one: the name is inserted (and if the user doesn't edit
        the cell, then the content gets replaced)
      * Insert all: a list of all names and their ranges gets inserted
        (I propose the same behavior for multiple selected items)

> >      * We could get rid of the "Modify" button -> improves the number
> >        and meaning of the buttons
> 
> Good. In the current interface it is used confusingly (not that there
> isn't precedent for this in other LibO dialogues – colour options, I
> am looking at you!).

;-) Yes, the "Add" and "Modify" is a pain ... especially in combination
with a list / a matrix of already existing elements that get changed.
That's why I thought about multiple use cases, so that any change is
"Modify" and adding is made a separate step.

> >      * Since we need to "reserve" space for the "Information Text"
> >        above the edit entries, we now can explain the user that he
> >        might also use formula expressions (if he adds a named range).
> >        For the rest, I strongly suggest to keep the common naming (for
> >        Calc and Excel users).
> 
> Cool. But about the mock-up wherein two items are selected: you may
> beg to differ, but I don't find "2 range names selected" to be very
> useful information. I think this one could go.

Hehe, I'm 60% for adding such information, because: a) the space is
there (without layout management), and b) we can explain the user that
several items are selected (he might not see that, since some items
might be hidded due to scrolling).

However, if we use the "balloon" style non-modal messaging, it needs to
go anyway.


> >      * Once we do have non-modal messages, the Information Text line
> >        isn't needed anymore. Same info will be provided via message
> >        balloons (or similar).
> 
> I find the majority of balloons to be aesthetically rather less
> pleasing and will fiercely defend the humble yellow-coloured
> information bar against attacks such as your own. :)

Touché! ;-)

> > A final note: Please be aware that this is something new to
> > LibreOffice ... we currently don't have such a dialog concept, although
> > I find it very promising. What do you think?
> 
> Like it.

Mmh, now let's ask the other 24.999.999 users ;-)))

Astron, thanks for your feedback ... I really like to have your input
(be aware that it sometimes needs a day until I know how to implement it
properly).

Cheers,
Christoph



More information about the Libreoffice-ux-advise mailing list