<html><head></head><body>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... <div class="gmail_quote"> Astron <heinzlesspam@googlemail.com> schrieb:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif">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. </pre></blockquote></div></body></html>