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

Hi everyone..,

Please bear with me, if this mail seems incoherent ... that might be
due to my mental state right now... And I'm sorry for the silence, but
I'd been planning to reply, but I wanted to have proper time.
In general, I still second Christoph's view.

Eike brought up a pretty good point, though:
> > con modeless dialog:
> >
> > - marking a range in the spreadsheet can no longer automatically be
> > used for the expression line ( nice feature in my opinion )
>
> Mmh, I had hoped it would still be available when e.g. editing the
> expression ... click in the field, select the cell range. To me, the
> "mode change to edit" is much saner communicated than today.

Thinking through Christoph's proposal, I can kind of see how it might work:
Giving the expression field focus would put the spreadsheet part of
the window (cells + headers + tabs) in a mode where it behaves like it
does in today's modal dialogue. If you then select any part of the
content, it would be used as the range expression (immediately after a
selection is made, the expression field would lose focus[1], the
content area would react normally again). Or, if you select any part
of the main window/dialogue "chrome" [2] (all of it still shown as
active), the expression input field would lose focus.
Does that compute? Is that too complicated for users?

For Markus's use case (see mail above), this still wouldn't cut it
(but see below). I think we all can agree that this will never be
possible in a modal dialogue.

However, Markus's current use also wouldn't work with today's
mock-ups, because we have integrated the "Insert" functionality into
the dialogue. "Insert" needs to have a cell to insert the range name
into and this cell must be selected somehow prior to inserting. If the
expression line always got the focus if any spreadsheet cell was
selected ... there'd be trouble.


By the by, as you've started doing pro/con lists (very helpful – a few
of things at least I hadn't thought about before):
one more pro:
Inserting should work much better. With a modal dialogue, inserting
will always be pretty awkward, because you can't build an expression
with the range inside a spreadsheet cell easily. Also, we'll have to
discuss what happens when a range name is inserted: should the "Manage
Names" window close (from the user's perspective that might be
unexpected) or should it just stay put (in the case where the user
wants to just quickly insert a name, less efficient)?

one more might-be con:
The case of multiple open spreadsheets. I think that's solvable with
enough code, but initially it might seem daunting to handle.


Quoting from Eike again:
> The allowed characters are defined in ODF OpenFormula
> 5.11 Named Expressions
> http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part2.html#__RefHeading__1017964_715980110
> with the 'Identifier' EBNF and actually do not depend on localization or
> separators used.
>
> However, showing a list of characters that are not allowed is way out of
> the possible, as it would encompass hundreds (or thousands?) control
> characters and separators of the Unicode range. Provide a positive list
> similar to the EBNF definition (but just saying "Allowed are letters,
> digits and underscore and the name must not represent a cell address" or
> some such for simplicity), or/and dynamically display the first invalid
> character encountered.

Your positive list is pretty long even in English (would be two lines
within the notification bar) ... I'll just count that as a point pro
ignoring invalid keystrokes (I still like the idea, yes).

By the way, looking at the linked spec, I noticed that even
Christoph's proposed UI overhaul lacks a way to use external sources.
Is that by design?


In closing: I won't try to give any final opinions here. It's of
course up to Markus to decide what he wants to code. And doing the
changes in two steps might be unsatisfying initially for everyone
involved, but it'll also give us the chance to hear some feedback from
a wider audience.
I'll update both my modal and my non-modal proposals in the coming days.


Astron.


[1] I hope that wouldn't overly optimise the dialogue for the common case
[2] this term copyright Mozilla, Google 2000–2011