GNOME Bugzilla – Bug 76800
usability/hig-compliance suggestions
Last modified: 2004-12-22 21:47:04 UTC
- Menus and menu titles all need access keys and title caps capitalisation. - File->New Window should have Ctrl+N shortcut (or am I just missing how to turn shortcuts on? I thought profterm used to have shortcuts... have they just been removed altogether?) - file->New Tab ... could be Shift+Ctrl+N? - File->Close Window should be Ctrl-W - File->Close Tab could be Shift-Ctrl-W - Edit->Copy/Paste could be Ctrl-C, Ctrl-V - Terminal menu should probably be "Terminals", according to HIG - Help->Help Contents should just be labelled Contents and have F1 shortcut - Tabs would look better if they didn't fill available space, but were just as wide as the tab label - Go menu items should perhaps all be on Terminals menu, so we could lose the Go menu altogether, i.e: Terminals <tab list> --- Pro_file > _Reset Reset and _Clear --- _Previous Tab Ctrl+PgDn (if shortcuts active) _Next Tab Ctrl+PgUp (if shortcuts active) - New Profile Dialog-- should pre-fill with a default profile name. Either Create should be disabled when there is no text in the box, or a default profile name should be created when you press Create with a null string, rather than popping up the "you have to enter a name" message. - Edit Profile: all controls need mnemonics, some numeric text boxes too wide (should only be as wide as typical input), layout on General tab in particular needs some work to improve grouping and reduce number of alignment points
You don't have keyboard accelerators? There should be quite a few of them (for e.g. new window). Something may be going wrong. They are all Shift+Ctrl+whatever by default though, because things like Ctrl+C conflict badly with things people frequently enter into shells (the approach I took was to add "shift" to all the standard accelerators). I don't quite understand Terminal->Terminals - everything on that menu applies only to the single current tab or window and modifies that tab/window. The primary motivation for the Go menu is to have a place to display the keyboard shortcuts for switching tabs...
While you're looking at this - an essential feature which is currently missing is "new window/tab with profile" to create a tab with a particular profile. e.g. if I have my "ssh to maching foo" profile then I need to create the tab with that profile, it doesn't work to change the profile of a tab post-create. Should this option: - replace the plain New Window/New Tab menu items - be new menu items in File alongside them Should it: - have a submenu: New Window With Profile -> Foo Bar - pop up a dialog to choose Foo, Bar
- Shortcuts... could just have been broken in that build, we haven't had a clean build since then that I can check :/ - "Terminals"... not really my taste either, but the HIG currently says that the menu in an MDI app that contains the window list should be called "Windows", "Documents" or whatever, even though some items on it may only refer to the current window. I don't think I'd be desperately upset about this one if you chose to ignore it... - The "New terminal with specific profile" feature... current HIG guideline would suggest that a submenu is the thing to do here, with the first item being the most common and having the Ctrl+N (or possibly Shift+Ctrl+N in this case) shortcut. The profile specified by "Profile to use when opening a new terminal" setting should probably be separated out as first in the list and have the shortcut... I guess you could call this "Default Profile" so you didn't have to dynamically mess with the menus: New _Window > Default Profile Shift+Ctrl+N --- <list of all profiles> New _Tab > Default Profile --- <list of all profiles> or you could drop in the actual name of the profile, and put up with the fact it would be duplicated in the list of profiles below that. You might consider numbering the profiles in the menu too, so you could assign a mnemonic to the numbers (like the recently-used-file list you see everywhere on Windoze)-- dunno how hard that would be to implement. I'm not sure whether the "new window from default" or "new tab from default" item should get the coveted "Ctrl+N" shortcut, either... whichever you think is more likely to be the most-commonly used, I suppose.
I think the important bits of this are in for 2.0. Still several small tweaks mentioned that I'd like to do. I did the New Window with Profile stuff as you suggested and I think it came out pretty well. I do like the Go menu, adding it to Terminal just feels wrong to me - right now Terminal has all the operations on the current tab, and Go has moving between tabs, nice clean separation. Plus Go is potentially a really long menu, right?
I take the point, it just seems really odd that we have a menu whose main purpose is to switch between tabs... no other notebook control on the GNOME desktop seems to need one :) And in other apps, the "Documents" or "Windows" menu is used to switch between open documents or windows, hence it seemed logical that the "Terminal" menu should be used to switch between open Terminals here. Ah well, we're past the UI freeze now anyway :)
I'd like to point out here that, to get gnome-terminal in line with other GNOME apps, Profiles should be replaced with Preferences. The user may not know the difference.
I don't think just s/profile/preferences/ on one menu item helps, it just makes it all more confusing. Right now you have to learn a concept you didn't expect to learn, but it's all consistent and coherent once you do. I like how konsole handles profiles/preferences.
At the very least, I think "Current Profile..." should be at the bottom of the Edit menu, since that's where Preferences always goes. Then the user will at least get a dialog that *looks* like a preferences dialog when they select it...
See also #84405 on Go menu
*** Bug 95220 has been marked as a duplicate of this bug. ***
These are my comments from the dupe --------------------------------------------------------- the current menu titles could use some changes s/file/terminal gnome terminal doesn't do work on files so file is a bad title, terminal is better. this is consistent with the hig recommendation as well. What to do with the existing terminal menu. I recommend moving reset and clear into the edit menu, since these menu options basically edit the current terminal view. Profile and set title could probably be moved into the view menu view, since they affect how the current terminal is viewed. These are both kind of stretching it but i think thats ok. oh and s/go/tabs but thats another bug i already have open.... ----------------------------------------------------------------------------------
This stuff does not seem to have been done, so moving to GNOMEVER2.3 keyword, and adding ui-review keyword. I'll add it to the 2.3 ui-review page.
*** Bug 84405 has been marked as a duplicate of this bug. ***
Most of the above suggestions are already there. Except that: a) The keyboard shortcuts proposed by Calum (and the HIG) conflict with mostly everything one might run in a shell, so adding Shift to them (or something) is inevitable; b) The Terminal menu can't be changed to Terminals, because its items apply to the current tab only, and because c) The items in the Terminal menu act `inside' the current terminal, and those in the Go menu act *with* the terminals (tabs, actually, hence point 5 below) d) The Create button in the New Profile dialog is now disabled until the user has entered a profile name (as of a few hours ago) e) I think having all tabs the same width is good because tab titles may change rather frequently (think bash prompts...), and their resizing each time one cd's would be too distracting. Related to Calum's second comment, see also his bug 88318. Some extra things I'd change are: 0) I would try to have all possible menu items be actions, in general; see below. 1) In the File menu (I can't think of a better name for it...), change New Window -> Open New Window New Tab -> Open New Tab New Profile... -> Create New Profile... Move the Close Window item to the end, because that's morally the Quit here. 2) The Edit menu is different because it's the only one with a verb for a title, so these are possibly redundant, but for the sake of consistency, change Current Profile... -> Edit Current Profile... Keyboard Shortcuts... -> Edit Keyboard Shortcuts... Profiles... -> Edit Profiles... I'd reorder these as Edit Shortcuts, Edit Profiles, Edit Current Profile. (All these Edit words do look repetitive, I guess; evolution has a few menus like that...) 3) In the View menu, leave labels as they are, but move Hide Menubar to the end, putting a separator right before it (a menu called View which starts with an item called Hide is weird...) 4) In the Terminal menu, change Profile -> Change Profile (and not Set: there are too many `set' words here) Character Encoding -> Set Character Encoding and add a separator before the two Reset items 5) Rename the Go menu Tabs and maybe add a Windows menu after it? (Not sure about this one, but I have found myself wanting this were there) 6) Change the right-click menu from this: to this: _New Window Open _New Window New _Tab Open New _Tab _Copy _Copy _Paste _Paste _Profile Change _Profile _Edit Current Profile _Edit Current Profile _Input Methods... Show _Menubar Show _Menubar _Input Methods and do not show the keyboard shortcuts in it. Also put a separator right before Copy, and maybe after Paste; maybe a Close Tab after Open New Tab would help, too, and alleviate bug 71444.
2) I don't know about, I always think of it as Edit->ThingToEdit, e.g. Edit->Preferences as in most apps (maybe we should just change Current Profile to Preferences so Calum will love me) 3) For View->Hide Menubar, Epiphany has View-> [ ] Menubar i.e. a checkbox, maybe we should be consistent with that (should at least specify one or the other in HIG) 5) Not a big fan of a Windows menu but Tabs might be OK. Windows seems to duplicate window manager/panel functionality. If window list grouping worked right in particular. The other changes sound OK but would appreciate UI team feedback. Not sure what the release team will allow at the moment, either.
> Not sure what the release team will allow at the moment This is a UI-Review bug, so you are free to fix it before August 4th.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
Re: Havoc's remarks: 2) Ok 3) The HIG actually says checkboxes are the right thing in that case. 5) I take the proposal of the Windows menu back, actually; it seems the window list is going to get better soon, anyways... Before doing this, I'd love some input from UI people, though.
Here follows a path for your ui-reviewing pleasure, which does most of the above: 1) In the File menu, s/New/Open/ and make it Open Terminal, not Open Window, as discussed in bug #92215. Move Close Window to the end. 2) In the Edit menu, move Edit Current Profile to the end 3) In the View menu, made Show Menubar and Fullscreen check menu items (the first one will never be seen when it is unchecked, but when it is visible, one has extra visual indication that it is a toggle this way) Separated these two items for the rest, and add stock items to the Zoom ones 4) In the Terminal menu, s/Profile/Change Profile/, s/Character Coding/Set Character Encoding/, 5) Rename the Go menu Tabs 6) In the context menu, s/New/Open/, and make it Open Terminal instead of Open Window, as above; add a Close Tab, and move the Input Methods to the end; turn the Show Menubar item into a check item. Also add a couple of separators at appropriate places, and do not show the keyboard shortcuts here. 7) Finally, the patch changes the way menu item icons are dealt with, so that now, in particular, when /desktop/gnome/interface/menus_have_icons is false, the space which would be ocupied by the icons is removes (currently, the icons are hidden, but the space is still there)
Created attachment 20558 [details] [review] Do all that
*** Bug 124427 has been marked as a duplicate of this bug. ***
This is in HEAD now, so that people will get a change to try it and complain with 2.5.0. Everything here except Calum's 2nd comment has been taken care of, but that is alsio in bug 88318, so I'll close this. Reopen as appropriate, of course.