[Libreoffice-ux-advise] [Bug 158069] Scroll through font selection listbox using arrow keys and preview change on document canvas

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=158069

--- Comment #9 from Bob English <bobofenglish at zoho.com> ---
Sorry for taking this long.

Being a user not a developer, there's some stuff in here I don't understand,
but this I do:

(In reply to V Stuart Foote from comment #7)
> Our Design Guideline
> 
> Actions -- 
> 
> When the dropdown/combobox is on toolbars or sidebar, changes should not
> become effective until the user leaves the control or collapses the open
> widget. 
> 
> In particular, hoovering over the expanded dropdown or wheeling respectively
> navigating with arrow keys the closed control should not apply the selection
> on-the-fly. The change is made effective with tab and enter only.

Well, it's right, and how it seems to work, but it still makes no sense nor can
I see what purpose it serves to work that way.

Following it, I first have to select a font in the dropdown which I can both
with the up/down arrows, and wheel (So far so good), which works kike this: 
The combobox font changes, but the highlighted text does not change, so I
cannot see my selection applied:  Who needs to change the font in the list, but
not in their document?  What possible purpose does that serve?  Even if once
applied, you don't like your changes, the undo [Crtrl]+[Z] will fix it right
quick.

I still have to click, hit [Tab] or [Enter] on a font in the list to apply it,
and as soon as I do, the focus is back in the text for click and [Enter], but
for [Tab] it moves focuses to the right onto the font size dropdown. Now to see
the next font I cannot just continue scrolling, I have to click in the box
again, or in the case of having used [Tab] I will be changing the size, again
only in the list.  Livable if you only have like 10 fonts to choose from, but
most of us have a whole lot more.  Applying any change via click or [Enter]
should not take the focus off of the the control and put it back onto the last
cursor position in the document.  For tab to move to the next control, does
make sense as the next logical step, albeit you still see no changes to the
selected text on scrolling until you click or hit [Enter] or [Tab].

All in all, needing to go through all that (Add that I have hundreds of fonts)
just to see how font changes will look, exactly where you want to see them (in
the actual document) is not in the true spirit of WYSIWYG!  What I see change
in a control selection I want to get on the selected text!  I can scroll
through the list and read pretty font names all day without even having
anything selected in the document, but if I select something then of course I
am doing so in order to do something with or to the selection.

Guidelines are great, but only if they serve a real purpose and make sense, and
as a user I really don't care what all they do for the developers, if it gives
me the user no benefit.  I care but what it means to me as to functionality and
my workflow, and for that it is counter productive by adding a few unnecessary
steps, and compounds them when you want to try many fonts to see which looks
best.

Seeing only the font name in it's appearance in that list is not sufficient to
imagine it in the document itself, and to what is selected:  I Want to see what
I will get; WYSIWYG, and that totally makes sense, and is of course most likely
why GIMP, Inkscape, and most, if not all programs that have selection controls
do apply selections within scrolling through them in real time.

-- 
You are receiving this mail because:
You are on the CC list for the bug.