https://bugs.documentfoundation.org/show_bug.cgi?id=91130
--- Comment #19 from Ole Tange <o...@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. _______________________________________________ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise