Hi all,
A quick mobile answer: I'd like to avoid any unwanted jumping from within the dialog, so if we can
avoid any jump in the document when the dialog is opened, that would be good.
But, at the same time, I'd suggest to have the focus in the table when opening the dialog, so the
user can start navigating.
To me, two contradicting goals at the moment. But maybe not setting the focus in the table, but on
e.g. the add button helps.
More thoughts later ... maybe not today.
Enjoy your day,
Christoph
--
Sent via mobile...
Astron <heinzlesspam@googlemail.com> schrieb:
Hi everyone,
After implementing parts of the "Select Range" button I think it is
redundant. If you want to see the range then you can either go to the
range line directly or click the button after the range line and the
range is highlighted in the document. I think that for nearly all use
cases this should be enough.
Ah, so changing the range expression also jumps towards the target. Yes,
then it is less needed.
But let's have a look at the "default functionality" in the dialog
(pressing ENTER, or double clicking on an entry). Having no "Select
Range" leads to the alternatives ...
* Going to the Text Field "Name" makes sense visually - it is the
very next field. But I assume that name changes are less likely
than checking / modifying the range. Thus, undesired.
* Going to the Text Field "Range" might make sense from the
use-case point-of-view. But, we don't have a "default
functionality" visualization like for buttons. Thus, people
won't know that easily. Furthermore, using the keyboard and
jumping to the ranges (the visual check) doesn't work anymore,
since the focus is moved from the table to the edit field.
* Avoid to go to any input field / button, but executing "select
range" (without having such a button). But, user don't see this
functionality and I don't know whether omitting this button will
cause problems for accessibility.
If I may voice an opinion, I happen to agree with Markus on this issue
– I think the visualisation should appear on single-clicking/↓↑ arrow
selecting the list entry, as it does today and of course when
modifying such an entry.
For a solution to the focus problem, why not go for option 1?
* Name is the most inconsequential field (given that the names are
updated automatically in formulas when applying), so if the user
doesn't notice the focus change immediately after double-clicking, it
won't hurt at all.
* Going to "range" is just one extra tab away.
* It makes sense for keyboard users. (Entry table, Tab→, Name field,
Tab→, Range field, Tab→, Scope field, Tab→, Range Options, Tab→ (the
five buttons), Tab→, Entry table)
* It makes sense visually.
I hope that beginning of next week the first big part of my work hits
master. It is only a rough plan and I'll drop you a second note as
soon as I pushed all my changes and think it is ready for some first
tests by you.
Will love to try, too.
Astron.
Context
Re: [Libreoffice-ux-advise] new range name dialog proposal · Markus Mohrhard
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.