Open
Bug 617858
Opened 15 years ago
Updated 3 years ago
font selection lists should not group sans and serif fonts into separate alphabetical sorts
Categories
(Thunderbird :: Preferences, defect)
Tracking
(Not tracked)
NEW
People
(Reporter: asa, Unassigned)
Details
It appears that the font selection list in Options -> Display -> Formatting -> Fonts, and the several font selection lists in Options -> Display -> Formatting -> Fonts -> Advanced all have two separately sorted alphabetical groupings within the listbox. It appears the lists are grouped by type (serif vs sans-serif)
This is pretty horrible UX because most people opening a list box, especially one this long, are expecting a single sort (alphabetical for a list like this.) If a user is looking for, say Times New Roman, she will quickly scroll down towards the end of the list and only start analyzing the list items when she gets to the approximate location she expects to find the items starting with T.
When the list has multiple groups, she'll consistently miss the Times New Roman and Verdana if it appears in the first group and she'll miss Areil and Courier if it appears in the second group.
The only time you can really get away with this is in an optgroup with clearly marked headers and even then, if the user can't see at least two headers visible in the same view, he may not realize that there are groups at all.
The usability of the lists is even further compromised because the group order isn't consistent across the various selects.
There are to obvious fixes here. The first is to return to a full alphabetical sort of all available fonts for all of the lists. This will be slower to use than my second proposal, but at least it won't be surprising or confusing to most people and it won't require deciding which fonts or font types ought to be in each of the different selects. The second, and far more usable fix is to actually split the lists and only show the serif fonts in the Serif: select list and only show the sans-serif fonts in the Sans-serif: select list. (I'll pre-emptively assert here that users do not need to be able to override serif for sans-serif or vice-versa -- or, that if they do need to, that this isn't the UI for that.)
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•