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

[Christoph Noack]

Hi Astron, all!

A few thoughts ... I'm not good at managing my time currently, because
its already very late. So please excuse some briefness ...

Am Dienstag, den 25.10.2011, 18:45 +0200 schrieb 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.

Yep, would be one solution ... maybe we do some nasty tricks to make the
user believe it is a character-by-character update?
      * When changing a name / expression (e.g. entering a character),
        the system might check for the name / expression validity, and
        (if valid) update the table. The model stays unchanged. If the
        name / expression is invalid, further changes in the model
        mustn't be done anyway.
      * If the user exits the input field, then the model is updated and
        a undo item is created.

But still, I don't know whether its doable or solves the performance
issue. But I really think its very elegant ;-)

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

As said, it will work well from the logical point-of-view, but people
might hate it if small changes (like changing a name) requires
additional steps.

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

Personally, I'm in favor of the notification bar ... and if the user has
created an invalid entry, then we might even use the "bad" modal message
box and ask him whether to continue editing or undo-ing the change.

<dreaming>By the way, do you know the nice Android hover messages ... we
don't have something like that, but displaying something like "Name has
not been updated. Wrong characters used." on top of the dialog would be
less obtrusive.</dreaming> ;-)

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

Oh, okay, you had something similar in mind. Well, that would need to
have a layout manager, or? I tried to workaround that ...

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

Argh, yes, you're right. Undo might make more sense, but we should check
with the general meaning of "Back". I once wrote that down ... we really
should put that in the wiki.

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

Absolutely!

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

What a really well written (positive) statement ... :-)

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

Isn't the help one click away, anyway?

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

Clutter -> Of course.

Notification impact -> True. But I tried to address that with the small
warning sign.

Horizontal layout -> Not convinced yet, because (to me) it needs too
much space when thinking about a common case like "adding name" only.

However, the you've raised the 40% doubts to 80% ... will remove that in
the next dialog iteration. But I'll keep the help text in the insert
name dialog for now.

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

Well, I assumed that the user manually opened that window and accepted
its size. When opening the child window (insert name), I hope we can
move it above the manage names dialog.

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

True, but that's only valid for the range.

[...]

Good night everyone, and - Astron - thanks for the fine discussion so
far. By the way, I'll meet a fried tomorrow, so I'm offline for one day.

Cheers,
Christoph