GNOME Bugzilla – Bug 130576
[UI-REVIEW] Various changes to the application menu
Last modified: 2021-06-02 09:06:54 UTC
The following is a collection of changes to the main menu that I'm proposing; the reasoning for all changes is given separately below. [ Note: the gucharmap executable from the package in Debian unstable does not have a help menu. I think this is because the package was compiled without GNOME support. Whatever the reason, I'm simply going to ignore the help menu in my suggestions below. ] 1. Change title of File menu to "_Map". 2. Rename the different "Find[...]" menu items to "Search[...]" (while keeping the shortcuts the same). (This change might not apply if the change suggested in bug #130498 is rejected.) 3. Add a "St_atusbar" toggle item to the top of the View menu, followed by a separator. 4. Add a "_Normal Size" menu item to the View menu with a Ctrl+= shortcut (also see bug #130561). 5. Remove the Back / Forward items from the Go menu. Reasonings: 1. The HIG says regarding the File menu: "If your application does not operate on documents, give this menu a more appropriate name." While "Map" is perhaps not a perfect title, I think it is good enough as long as the application is titled "Character Map". ("Character Map" as the menu title is not possible because it consists of multiple words.) 2. The HIG says regarding the Find menu items: "If the command allows the user to search for content in places other than the current document, for example other open documents, other documents on disk, or a remote network location, label this item Search instead of Find." It might be debatable whether this really applies to the Find items in gucharmap (even with the suggested change); my personal conclusion however is that it does, if not directly by the letter than at least by it's spirit. 3. According to the HIG, this menu item should be present in every application that has a statusbar. 4. This is given in the HIG to supplement the already existing Zoom items. 5. Since I haven't found out yet what these items are used for I assume that they are useless and can be removed ;) I have a few more changes in my head. However, since I'm not completely sure about those, I'll have to do some more investigation before maybe adding them later...
> 1. Change title of File menu to "_Map". I don't know, that seems a bit confusing to me. I'd like to hear from other usability people. > 2. Rename the different "Find[...]" menu items to > "Search[...]" (while keeping the shortcuts the same). I'll keep this in mind for later. > 3. Add a "St_atusbar" toggle item to the top of the View > menu, followed by a separator. Why would anyone want to disable the status bar? It displays very important information. I see now that the HIG says status bars shouldn't display important information, but it's rather late to change that. > 4. Add a "_Normal Size" menu item to the View menu with a > Ctrl+= shortcut (also see bug #130561). At the moment ctrl+= does the same as ctrl++. Anything else is very confusing for users of US keyboards, in spite of what the HIG says. > 5. Remove the Back / Forward items from the Go menu. These are for link-clicking history (links are in the details tab). What is your opinion in light of this information?
As for the the `File' -> `Map' change I'll try to get some input on that later. (In general I try to keep track of such issues so that I can later ask them "en bloc".) > Why would anyone want to disable the status bar? It displays very > important information. I see now that the HIG says status bars > shouldn't display important information, but it's rather late to > change that. Some people (I'd argue most) might not even consider the currently displayed information important for them and therefore might prefer not to have the statusbar take up precious space (especially if they use the Character Map very often and don't have large monitors). The issue of "shouldn't display important information" is btw also still on my list of to-be-reported issues :) > At the moment ctrl+= does the same as ctrl++. Anything else > is very confusing for users of US keyboards, in spite of > what the HIG says. Hmm... using a US-keyboard myself (in spite of beeing german) I consider this to be mostly a problem of familiarity (something which isn't really helped by individual apps diverging from each other). It's true that the placement of the keys on the US-keyboard can be considered a minor nuisance. However, sometimes the advantages of consistency simply outweigh smaller disadvantages and I personally think this is the case here. (And consistency here doesn't only mean consistency with other apps but also consistency with other shortcuts, which also aren't selected based on the position of keys on certain keyboards.) Anyway, I'm not really interested in starting an argument over this one. If anything I think this should be argued with the people responsible for the HIG (though I think you can rest assured that they were aware of the problem with the US keyboard-layout when these shortcuts were originally defined; after all, other popular apps were using exactly that double-shortcut already at the time the HIG was written). > These are for link-clicking history (links are in the > details tab). What is your opinion in light of this > information? Ok, I see now. Hmm... if such history-browsing is possible at all, perhaps it would make more sense to at least enable it generally (i.e. even for characters selected directly) as this would get rid of the always disabled menu items and would help users understand what these entries are used for.
WRT the View->Statusbar item: I have been told that the current draft versions of the reworked HIG (e.g. the upcoming 2.0) says that no such toggle item should be present. Therefore it shouldn't be necessary to add such an item anymore.
Actually, there seems to have been a misunderstanding on my part and what I said above is not entirely true: the draft HIG still says such a toggle item should be present but there's at least some discussion (cf. bug 120968) on whether it should stay this way or not.
> Ok, I see now. Hmm... if such history-browsing is > possible at all, perhaps it would make more sense to at > least enable it generally (i.e. even for characters > selected directly) as this would get rid of the always > disabled menu items and would help users understand what > these entries are used for. Sure, but what counts as a character being visited?
The simplest approach seems to be to put the previously selected character on the history stack whenever any other character is selected (be it by mouse, a search or by following a link). One exception perhaps could be made with keyboard navigation where it might make sense to only add toggled characters to the history to not make it become to polluted.
Re-assign to default owner and QA.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gucharmap/-/issues/103.