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

Hi Markus,

officially, I'm not at the computer anymore :-) Therefore I'll try a
quick reply ...

Am Montag, den 24.10.2011, 22:53 +0200 schrieb Markus Mohrhard:
> 2011/10/24 Christoph Noack <christoph@dogmatux.com>:
> > Am Montag, den 24.10.2011, 01:49 +0200 schrieb Astron:
[...]
> > From the technical point of view I don't like that idea. I think
> without loosing too much performance we can only synchronize two
> entries: either table-model or selected element- table. But then we
> have a big problem how we get the model into that. The problem behind
> that is that we should not change the model for every changed
> character while typing a longer entry. I think changing the name
> forces us to delete the old name and insert a copy with the new name
> and changing the expression forces a recompilation of the formula.

Dumb question - what does "loosing performance" mean here? Do you think
it might work if the table is updated after (one example) 300 ms of
non-activity of the user (who stopped typing when changing the name)?


> > 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.
>
> Why don't we use this dialog for add and modify. I think we had that
> idea in our inital discusion in Munich. That would make it clear when
> we change something and we still have table and model synchronized.

That's true ... but managing ranges does imply rather common changes
like the range or the name of the range. At least Microsoft added a
"shortcut" to rename items - I assume they did run into the same issue.
The shortcut is an entry like featuring own accept/reject buttons.
Something I had hoped to avoid...

> > > > 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.
>
> I think I already implemented somenthing in this direction. I think
> the Add and the modify button are only enabled if the name is valid. I
> still think that allowing all characters and showing a warning that
> some characters are not allowed is better than too much magic that
> nobody understands.

Do we know the characters being not allowed in advance? In my statement
above, I guessed we don't know them ... that was my understanding in
Munich.

> Invalid entries in the expression line are much
> harder to detect. I think these errors can only be detected if we
> compile the formula.

How long does that take usually / worst-case? (just curious, I need to
learn some new aspects)

[...]
> > > 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.
>
> I like the undo inside the dialog much better that using global undo
> for that. The advantage of the old range name undo was that it just
> saved the state before and after executing the dialog. That made only
> one undo entry for several changes. Now we would have maybe 20 entries
> that are only created because we added range names or modiefied some
> of them.

Okay, I need to think about that ... Undo is sometimes a bit neglected
and is handled very differently.

[...]
> > 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)
>
> Should we really keep the old behaviour for insert one? I know that as
> soon as I get the dialog non modal it might work but I don't see the
> use of the old behaviour then.

I understood that to be an important use case ... from our
discussions :-) Do you think people don't need to insert single range
names in formulas?


> > > >      * 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.
>
> I'm a bit lost here. I don't know what aou are talking about.

Then please don't consider this section too much - but there is a common
pattern of having elements (colors, range names, gradients) and the need
to modify / add / delete elements quickly. Separate dialogs (see above)
make it too slow, input elements plus modification buttons cause issues
(because you always screw up one or two use cases users will need).

[...]

Okay, have to go ... thanks for the nice discussion!

Cheers,
Christoph