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)

Tracking

(Not tracked)

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 ago25 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.