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

[Astron]

Hi Markus, Christoph, erveryone reading,

I'll quote from both of your mails, Markus's first:

> 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 it is common practice in most Gnome/Mac applications to only
actually "set" the edited value only once the user clicks outside of
the input box. This also gives users a bit of a safety net here. This
model would work very well for changing names (I think).

I'm unsure if this model could also work for the expression line. I
was to propose checking to see if the input is a valid expression in
there before visualising it in the spreadsheet and saving the formula
as an Undo history step, but you explained that this probably won't
work.
So, if it helps performance a lot, I'd again say: validate and update
the expression only when the user clicks outside the input box. This
will hurt usability a bit, though, because it is always good to see
such consequential changes happen live.


> 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.

So, what you're proposing is:
#1 a list of ranges with a few buttons
#2 a dialog to add and modify named ranges.
Is that correct?

While this is IMHO more logical than Christoph's proposal where you
use a different dialog for adding and modifying range names (also from
the standpoint of the aforementioned performance requirements), it
seems to me to be a bit inelegant. If for performance reasons
necessary, I could imagine it working quite well, though.


A tidbit from Christoph in between:
>>> 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 ;-)))

I see, but wouldn't office computers usually come without speakers
anyway? And those working on a laptop will mute their speakers, too.
Additionally, of course, why not still use the notification bar in
such a case?


And, again, Markus:
>> 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.

Fair point. But that's why I also proposed the beep (that still won't
help in office situations, as I noted above). Combined with a
non-modal bar that should stay up until the user closes it, I think
though, it should be alright.


Christoph:
>>> 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 only asked because of the slightly confusing naming "Back." By the
way, I remember I had some stake in a proposed redesign of button rows
[1]. If Markus wants to be really nice, this dialogue could be a
testbed for the redesign (sorry for speaking with you in the third
person, Markus).
The change in this dialogue would consist of integration with the
global undo/redo system and a combined [Undo|Redo] button with icons
on it. I'll make a new mock-up, so you see what I mean (if you are
interested).


> 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.

See above, what I describe would cut that number down quite
drastically. For expressions, a general rule should be: only store
working expressions in the history (i. e. if the user clicks outside
the input box the result should only be stored in history if it is
valid – the user can't leave anyway, there's a modal warning box when
she tries to close the dialogue).


>>> 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.

I tried it since then.
I'll admit to at first having confused the Insert > Names function
with the functionally and UI-wise relatively similar Data > Range
function (which doesn't provide an option to Insert into the
document).

Christoph, then Markus:
>> 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.

Two questions for my understanding:
#1 So, you're for removing the Insert all functionality in its entirety?
#2 Is there any use case the list would make more sense in?


Christoph, then Markus:
>> ;-) 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.

See Options > LibreOffice > Colours. The usage of this page is quite
similar to the usage of the current Define Range dialogue.
So, many of the lessons learned here can be applied in other areas.


Christoph:
>>> >      * 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).
By the way: if that really ends up in the dialogue, I am strongly in
favour of adding a link to a help file, explaining what formula
expressions can be used. I'll admit that I was too dumb see what could
be done with any other operators but ":".


Again, Christoph:
>>> 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).

Three reasons against it:
# it's a bit more clutter in the interface
# I think that me that always having text in that area will make the
notification bar appear less "notable" when it appears, so user might
completely ignore it
# in a horizontal layout, space problems are less relevant as you can
easily fit ten entries (admittedly, this is only a reason to adopt my
mock-up, so disregard this)
How good these are, you decide.

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

You knew I'd readily cheer for non-modal dialogues, didn't you?

Oh, something I almost forgot, two things about Christoph's last
mock-up/the separation of Define and Manage Names:
#1 if you use the work flow Manage Names > Add..., then you'll having
both windows on screen – effectively here you lose the advantage of
having only a small window open (unless you close Manage Names for the
time Define Name is open – which would IMHO be a legit solution for
the situation)
#2 there always is the option of rolling up the window with the ↑
button at the end of the expression bar – if you choose a range with
your mouse, the window will roll up automatically – even today.


Regards,

Astron.


[1] http://wiki.documentfoundation.org/Design/Whiteboards/PropertiesButtonLayout