[Libreoffice-ux-advise] [Bug 91130] Smaller default font name list

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #19 from Ole Tange <ota at prosa.dk> ---
> * Simplicity
> It is a huge control spawning over the whole screen but the use case is not
> to see all. And search (type and filter the dropdown) replaces the need for
> a large overview.

Why is it not _a_ use case to see all the fonts? I would reckon many users do
not have an overview over all the fonts they have installed (I, for one, do
not, and I consider myself advanced user). I agree this is not the _primary_
use case, but I really do not see why giving this overview should be seen as
something negative.

There is a reason we also let people see more than one file name in a directory
listing: It is simpler if they can get an overview by seeing more files.

In other words: I still do not understand how it is a goal to make it harder to
see all the fonts installed. Because the extension of that argument would be
that it would be simpler to present a single font at a time.

Maybe you can enlighten me?

> * Start from sidebar and withing dialogs doesnt work
> Dropdown is not only located in the top left area but also in dialogs and
> at the sidebar. The layout wont work on all positions.

Can you provide a screenshot of an example where you cannot envision this will
work? Then I may be able to suggest a mockuped solution.

> * Scrolling unclear
> Many columns mean you either scroll all, or each column individually, or
> you scroll horizontally. Not defined in the mockup and yet quite complicate.

As the fonts are sorted, the scrollbar will be at the right hand side
controlling all columns. Just as if you had a multi-column table on a normal
page in Writer.

The font dropdown already does scrolling of at least 2 columns: Font name and
font preview of non-western fonts.

If it is still unclear how this would work, I will be happy to make a mockup
showing the scroll bar and some scrolling action.

> * Keyboard only usage not simple
> Consider a keyboard only interaction where the user type Montse and presses
> down and enter to get the font she is looking for. In your proposal either
> many arrow steps or the mouse is needed.

To select 'Montserrat' the user will type: Mont

While the user does that, the dropdown dynamically filters the list. When the
final 't' is pressed the dropdown only shows these fonts (These are the only
fonts on my system that match the substring 'mont'):

Montserrat
Montserrat Black
Montserrat ExtraBold
Montserrat ExtraLight
Montserrat Hairline
Montserrat Light
Montserrat SemiBold
Montserrat Thin
Montserrat Ultra Light

Then the user presses 'down' to highlight [Montserrat] followed by 'Enter'.

In total 6 keypresses - including writing 'Mont'.

If this is unclear, I will be happy to make a mockup "animation" showing this.

How many keypresses would you find is acceptable including writing 'Mont'?

And while we are on it: How many mouse clicks/scroll-events would you find
acceptable to choose a font?

> * Slow generation of this grid
> The grid with WYSYWIG font preview sounds like a challenge for performance.

I agree, but I see several solutions for that.

On slow machines generating preview of the full fontlist is somewhat of a task.
One solution would be to generate those previews in the advance and cache those
on disk. My testing shows that a preview PNG of a font is around 2 kb.

The generating could be done when LibreOffice starts or when the dropdown is
accessed. If a preview PNG exists for the font, use that, otherwise generate a
PNG, and save it to the disk.

To make the UI responsive you could use a default font until the preview is
generated or loaded from disk. When opening the list the first time it will
then look similar to a web page where a lot of images is loading in parallel.

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