https://bugs.documentfoundation.org/show_bug.cgi?id=115285
Jean-François Fortin Tam <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|DUPLICATE |---
Ever confirmed|0 |1
--- Comment #3 from Jean-François Fortin Tam <[email protected]> ---
> This is huge oversimplification based on ignorance.
I've been doing interaction design for about a decade in GNOME, and I've also
seen people struggle with LibreOffice in all sorts of ways. I've been
supporting everyday people, book authors, nurses and doctors, and I can tell
from experience that pretty much nobody requires the level of "precision" that
the current filtering combobox has. Maybe you should refrain from presuming I'm
just "ignorant". "Opiniated", I'll give you that, but that's because I care
about making LibreOffice better ;)
> so that some ambiguous cases, like csv named dat, or xml, etc
Then your file is broken and that's not the GTK FileChooser's job.
And in such cases users can always decide to show "all files" and voilà.
Or use the operating system's file browser.
> some users may want to filter the list based on the file type
That's what the proposed file format "category" filtering accomplishes much
more quickly, and for more precise usecases (drilling down from inside the meta
categories filtering) that's what the searchbar is for.
> get an impression of the capabilities by looking over the list.
Not an issue. Users just want to open a file, not "get an impression of the
software's internal import filters capabilities" (that's what wikipedia and the
LibreOffice website or wiki are for). And if you really really want to have the
app's capabilities available on hand, then you could have a (?) help button
that shows the relevant documentation page explaining the "supported formats".
Still, the list of capabilities is typically something for organizational
buyers and decision makers, not the actual office workers who need to do things
quickly and efficiently...
...and showing a list of 176 items is NOT quick nor efficient for anybody. It's
just overwhelming to the point of uselessness.
I'm not exagerating that number by the way, I actually had to use the Gtk
Inspector to count the list of items because the GtkCombobox widget spans 6
times the height of my computer monitor.
Currently you're sacrificing usability by overloading the user with options
that they don't care about, for the sake of an unlikely technical edge case
that may affect 1% of scenarios (and those scenarios would have the easy
workaround of showing "All files", so they're not even truly affected).
Don't be afraid to make bold interaction design decisions in the best interest
of the 99%, please. The GUI is a means to an end (productivity), not an end in
itself. There are cases elsewhere in the LibreOffice GUIs where exhaustiveness
is expected, but this is not one of them.
Anyway, reopening not just because of the points above, but also because the
first part of my request was about remembering what the users chose (or
filtering to the relevant subcategory by default based on the application the
FileChooser dialog is called from). I don't simply want more "choices" à la bug
#94177, I want the app to help me get things done.
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
