Closed Bug 22222 Opened 25 years ago Closed 25 years ago

Close menu item needs to be next to Quit menu item

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 17014

People

(Reporter: sujay, Assigned: german)

References

Details

using 12/20 build of mozilla 1999122012

1) launch mozilla
2) launch editor
3) Close editor

notice when you try and pull-down to Close, its not located next
to Quit like it should be....

move it down near the Quit option...see 4.x...its really annoying
looking for it...

linux only.
*** Bug 22223 has been marked as a duplicate of this bug. ***
Yes, this drives me crazy, searching for Close since it's never where I expect
it to be.
Assignee: beppe → cmanske
Target Milestone: M13
assigning to cmanske
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
This is exactly as in the spec: http://gooey/client/5.0/specs/menu_framework/
If you don't like it, complain to German!
Status: RESOLVED → REOPENED
Reopening, will comment more in the next action.
Assignee: cmanske → german
Status: REOPENED → NEW
I can't read the spec Charley references (the fonts are three pixels high and
just look like tiny blobs on my monitor) but this must have been a mistake.
Close is right above Quit in Unix 4.x and in every other normal Unix app.

German says he'll take a look.
Resolution: INVALID → ---
Status: NEW → ASSIGNED
Please take a look again at
http:/www.mozilla.org/projects/ui/netscape/menu_framework/ and let me know why
you think this should be different for Linux/Unix users. (We may have to do a
platform specific overlay here, if it turns out that is too much against X
conventions). For Mac and Win this is the proper position.
Even on Windows, in 4.x the Close menu item was down at the bottom of the menu
right above the Quit item.  That makes sense, since Close and Quit do very
similar things.  In Seamonkey (I see this on both Linux and Windows), Close has
moved up to a higher spot next to Save (which doesn't seem related at all). I'm
not sure why Sujay says this is Linux only Sujay: where do you see Close being
on Windows and Mac?
Yeah Akkana, you're right...on Mac, the Close menu item is way up there also...
I'm checking Win....
Win also has Close item way up there....what is the logic in keeping
Close far from Quit in the menu?
Component: Editor → UE/UI
OS: Linux → All
Hardware: Other → All
Summary: [PP]Close menu item needs to be next to Quit menu item → Close menu item needs to be next to Quit menu item
Changing platform/OS to All and Component to UE/UI.  Not just an editor issue,
this is the case in the browser as well.
Heh. This is an issue which has been quietly festering in GUI apps for ~15 years
now. There seem to be two schools of thought. (1) Close is the opposite of Open,
so should be right next to Open in the menu. (2) Close and Quit are related
(similarly destructive), just like New and Open are related (similarly
constructive), so Close should be next to Quit.

The apps I have available on Win98 are evenly divided between the two schemes,
and IIRC this dichotomy is present on MacOS as well. so this is one of those
cases where you have the luxury of deciding what actually works best, rather
than following platform guidelines. My preference: (2).
The document management functions - "new, open, close, save, save as, print" are
all related and should be grouped close together as they currently are
in Mozilla.  You open, close and save a document, but you never quit one - you
quit an application.   The quit menu item is unrelated to the close menu item
(other than quit usually having the side effect of closing all documents).   The
object on which the menu items are operating is the key determinant for menu
item grouping here - there should be positioning cohesion for each of the
operations you can perform on a document or application.

Most modern Windows applications put Close back up where it should be - near
Open.   A quick scan of the applications on my computer which follow this
standard are: {all the MS Office Apps, Paint Shop Pro, Adobe Acrobat, WinZip, MS
Visual C++, etc}.    If 99% of UNIX applications use the other convention then
maybe Mozilla needs to follow it (for UNIX only - not because it is correct from
GUI design point of view, but because it is an overwhelming standard), but on
Windows at least Mozilla SHOULD NOT move the Close menu item down next to Quit.
I suspect Mac platform is same circumstance as Windows (but it has been a few
years since I quit the Mac scene for Windows).
Severity: normal → minor
Also, Close is a much more frequent operation than Quit, so from a user motor
task speed viewpoint, Close should be near top of File menu (not at the bottom),
while Quit is only used infrequently and can be at bottom.
* Close is not a document management function, any more. It is a window
  management function -- now that it is common to browse read-only files (the
  Web), view more than one document in the same window (session history), and
  have more than one window open on the same document.

* In an ideal world, we wouldn't have a `Quit' item at all, except for the
  operating system as a whole. I shouldn't have to care about apps, only about
  documents. That ideal is nearer than you think: IE4/5 doesn't have a Quit
  item, just a Close item. And where is it? At the *bottom* of the File menu.
  I predict that Mozilla's Quit item will disappear by version 7, leaving the
  Close item looking rather odd if it's not at the bottom.

* The Windows UI guidelines say: `If your application supports an Exit command,
  place this command at the bottom of the File menu preceded by a menu
  separator. When the user chooses the Exit command, close any open windows and
  files, and stop any further processing. If the object remains active even when
  its window is closed -- for example, like a folder or printer -- then include
  the Close command instead of Exit.' Mozilla has both Close and Exit, at the
  moment (see previous point), so why not put *both* of them in the right place?

* User motor task speed is a complete non-issue. If someone wants to close a
  window with the mouse, they'll use the window's close gadget, not a menu item.
  The menu item is there just for completeness, and to advertise the keyboard
  shortcut.
* It really doesn't matter if close is a document management function or not.
It is the opposite of whatever open does and therefore should be close to the
open menu item.   In the editor, it certainly is a document management function.

* For the moment we do still have a Quit menu item and users *don't* want to be
choosing quit accidently where they meant to be choosing close.    This is very
easy to do if they are close together and you don't have good mouse skills.
This is another reason not to group them.

If the quit menu item disappears, then it is more of an arbitary decision
whether close is put at the top or bottom of the menu.   There is certainly no
good reason I can think of why it should be put at the bottom.   If you think
about a user choosing the open menu item, and then wanting to close the window
with the close menu item.   It is a bit strange that for open they go to the top
of the menu, and then for close they have to travel down to the bottom.

* Motor task speed *is certainly* an issue here.   You and I may use the close
window widget when we want to close a window, but there are *many* users (I've
worked with some) who don't know about this and primarily use the menus.  For
these users, close should not be stuck down at the bottom.
Close isn't at all the opposite of Open.  "Open" means "I want to bring up a
dialog to let me search for a file or something and show it in this window".
"Close" means "I want to close this window, I'm done browsing but don't want to
kill off the mail window or other windows in the app" (or vice versa, or some
other combination).
Target Milestone: M13 → M15
I agree with Micheal it should be in proximity of Open. Both newer Mac and Win
based apps started using this convention a while ago. The other reason is to keep
Close more separate from Quit, which means leaving the environment, hence
grouping Close with document functions makes more sense. I rememeber anecdotical
evidence that close and exit caused confusion for end-users in 4.0, since they
were so close to each other and seemed to mean the same for them
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
This bug is also a duplicate of previous bugs that have already been closed:
13761, 14596, 17014. Marking as duplicate of 17014


*** This bug has been marked as a duplicate of 17014 ***
Wait a second....you've marked multiple bugs as a DUP of 17014. But 17014
is marked as WONTFIX ????
Status: RESOLVED → VERIFIED
verified in 1/11 build.
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.