After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 76800 - usability/hig-compliance suggestions
usability/hig-compliance suggestions
Status: RESOLVED FIXED
Product: gnome-terminal
Classification: Core
Component: general
1.9.x
Other All
: Normal normal
: 2.2
Assigned To: GNOME Terminal Maintainers
Havoc Pennington
AP4
: 84405 95220 124427 (view as bug list)
Depends on:
Blocks: 129568
 
 
Reported: 2002-03-28 18:38 UTC by Calum Benson
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Do all that (28.60 KB, patch)
2003-10-08 04:56 UTC, Mariano Suárez-Alvarez
none Details | Review

Description Calum Benson 2002-03-28 18:38:19 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
Comment 1 Havoc Pennington 2002-03-28 19:10:04 UTC
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...
Comment 2 Havoc Pennington 2002-03-28 19:14:35 UTC
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
Comment 3 Calum Benson 2002-03-28 19:37:46 UTC
- 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.
Comment 4 Havoc Pennington 2002-05-01 22:00:02 UTC
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?

Comment 5 Calum Benson 2002-05-14 14:24:49 UTC
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 :)
Comment 6 Reinout van Schouwen 2002-08-27 22:28:59 UTC
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.
Comment 7 Havoc Pennington 2002-08-27 22:55:31 UTC
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.
Comment 8 Calum Benson 2002-08-28 10:33:03 UTC
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...
Comment 9 Havoc Pennington 2002-09-22 21:48:59 UTC
See also #84405 on Go menu
Comment 10 Luis Villa 2002-11-22 20:02:09 UTC
*** Bug 95220 has been marked as a duplicate of this bug. ***
Comment 11 Dave Bordoley [Not Reading Bug Mail] 2002-11-22 23:09:10 UTC
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....
----------------------------------------------------------------------------------
Comment 12 Murray Cumming 2003-07-15 12:14:04 UTC
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.
Comment 13 Murray Cumming 2003-07-15 12:14:38 UTC
*** Bug 84405 has been marked as a duplicate of this bug. ***
Comment 14 Mariano Suárez-Alvarez 2003-07-16 05:56:41 UTC
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.


Comment 15 Havoc Pennington 2003-07-29 14:50:14 UTC
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.
Comment 16 Murray Cumming 2003-07-30 13:03:27 UTC
> 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.
Comment 17 Calum Benson 2003-08-07 16:18:17 UTC
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME
bug list :)
Comment 18 Mariano Suárez-Alvarez 2003-10-02 18:39:47 UTC
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.
Comment 19 Mariano Suárez-Alvarez 2003-10-08 04:55:51 UTC
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)

Comment 20 Mariano Suárez-Alvarez 2003-10-08 04:56:58 UTC
Created attachment 20558 [details] [review]
Do all that
Comment 21 Mariano Suárez-Alvarez 2003-10-14 13:00:32 UTC
*** Bug 124427 has been marked as a duplicate of this bug. ***
Comment 22 Mariano Suárez-Alvarez 2003-10-21 03:37:01 UTC
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.