Windows File menu reads Quit but should read Exit

VERIFIED FIXED in M18

Status

P4
trivial
VERIFIED FIXED
20 years ago
14 years ago

People

(Reporter: cpratt, Assigned: german)

Tracking

({platform-parity})

Trunk
x86
Windows 98
platform-parity

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

20 years ago
using apprunner on windows, the command to quit the application in the file menu
reads quit - but it should say exit instead (to conform to windows UI
guidelines).

Updated

20 years ago
Assignee: shuang → don
(Reporter)

Updated

20 years ago
OS: other → Windows 98

Updated

20 years ago
Assignee: don → saari

Updated

20 years ago
Target Milestone: M9

Comment 1

20 years ago
Actually, it should say whatever german specifies. targetting m9
(Reporter)

Comment 2

20 years ago
According to German's spec at http://gooey/client/5.0/specs/menu_framework/,
"Sea-Monkey will be the first application to have a platform independent look
and feel. To this end, there will be one set of menus
for both Macintosh and Windows. Exit will become Quit."

So... I'm wrong on this one. However, I find it strange that we're going with
the Mac OS standard when most Navigator users (I assume) use Windows. German,
would you please reconsider going with lowest-common-denominator menu wordings?
Both Linux and Windows use "Exit" and not "Quit".
QA Contact: 4137

Comment 3

20 years ago
Bzzzt! Wrong Answer!

Platform specific XUL fragments, or we will be lynched.

I've already got bugs that MacOS menus need to diverge, and they ARE diverging.
Or do you want an Apple menu on Windows?

You can make a fully XP UI, its just that no one will like it.
(Assignee)

Comment 4

20 years ago
I find Quit a lot more suitable as an XP standard as most newer apps, even on
windows, use ctrl-Q as the keyboard shortcut. Several apps on Windows also
started now using Quit as a menu item. I foresee no usability problems, so I'd
really like to avoid the balkanization of the UI , if the only compelling reason
for it is because it's a 'Microsoft standard'. I agree we need divergence on
some isolated cases but this is not one of them.
- Look what happened to borderless buttons: we had them planned for a while for
4.0 and everybody said 'but it's not a MS standard - we can't do that', as soon
as IE3 and Office 97 had them, verybody felt we should do it too.
- Look what happended to keyboard shortcuts for windows between 3.0 and 3.1 for
Cut, Copy and Paste: MS themselves changed them to adopt the Mac standard,
whereas before they had the really hard to remmeber shortcuts.
Don't be surprised if MS changes things around again.
(Reporter)

Comment 5

20 years ago
Although Microsoft may have changed keyboard shortcuts between 3.0 and 3.1,
this bug specifically has to do with the File | Exit menu item. As far back as
1989, when Microsoft published the UI spec for Windows 3.0, it was Exit. My
1990 Microsoft Windows 3.0 User's Guide specifies Exit as what you select to
quit a program (page 63). Exit is also what you type to exit out of a DOS
window or command prompt. In short, it's the Windows standard, and it has been
for nearly ten years. That's why I believe we should stick with it.

As far as third-party apps using 'Quit' on Windows, well, that's a bug. That
definitely does NOT conform to MS UI guidelines. Well-written Windows
applications do not even have Ctrl-Q as a keyboard shortcut - the correct
shortcut after all is Alt-F4 (again according to MS UI guidelines).

In short, I agree with saari: it's very poor form for us to impose Mac
standards on Windows users.

Comment 6

19 years ago
there's a big difference between borderless buttons and what's standard on a
menu. Either quit or exit or close can refer to the app or the window. It's the
standard that tells us that 'close' refers to the window and 'exit' refers to
the app because on their own all 3 words mean basically the same thing.

(btwI should also point out that in windows, preferences are called options  and
they are in the View menu)

Updated

19 years ago
Assignee: saari → german

Comment 7

19 years ago
Reassigning to german

Updated

19 years ago
Target Milestone: M9 → M10

Comment 8

19 years ago
Moving to M10 - some discussion still underway per German.

Updated

19 years ago
Summary: windows file menu reads quit but should read exit → [PP]windows file menu reads quit but should read exit

Comment 9

19 years ago
Setting on [PP] radar.

Updated

19 years ago
Status: NEW → ASSIGNED
Priority: P3 → P4
Target Milestone: M10 → M18

Comment 10

19 years ago
Changed mileston for later UI polishment. For now, please follow the spec.

Comment 11

19 years ago
I agree that on Windows the menu item should be called Exit.
(Assignee)

Comment 12

19 years ago
Please stick with the specification for now, which specifies Quit across
platforms. Should we encounter usability probelms, we will re-visit this issue.
No, cpratt, it's not just `third-party' apps using Ctrl+Q for Quit. It's
Microsoft itself. Take a test-drive of almost any recent version of Word, Excel,
PowerPoint, IE, etc. Ctrl+Q quits the app, and Ctrl+W closes the currrent
window. Just like the Mac. And *no other* keyboard shortcut is shown next to the
relevant menu items. (Yes, Alt+F4 works, but it's not advertised on the menu.)
Quit is, as far as I can see, becoming the de facto standard -- first with the
keyboard shortcut, then with the menu item.
(Reporter)

Comment 14

19 years ago
Hm. I'll look at Office 2000 later if it's important, but this is what I find
using Office 97 (SR-2) on Windows NT:
Word: File menu says Exit. No shortcut listed. Accelerator is X. Ctrl+Q does
nothing. Alt+F4 exits.
Excel: File menu says Exit. No shortcut listed. Accelerator is X. Ctrl+Q does
nothing. Alt+F4 exits.
Outlook 98: File menu says Exit. No shortcut listed. Accelerator is X. Ctrl+Q
does nothing. Alt+F4 exits.
IE: File menu only says Close (remember, IE is not a separate app any longer,
but part of the OS). Ctrl+Q does nothing. Alt+F4 closes the window.
PowerPoint: File menu says Exit. No shortcut listed. Accelerator is X. Ctrl+Q
exits the app. Alt+F4 does too.

Based on this, I don't see Quit 'becoming the de facto standard' - it's not in
any menu item, and Ctrl+Q only works in one of the apps.

OTOH I don't have Office 2000 handy, so I'll have to check again with that later
on. What version of Office were you using?

[BTW, the reason why I care about this: I tend to use keyboard accelerators
heavily. If it isn't Exit, Alt+F+X no longer works and I get very frustrated.]
(Reporter)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WONTFIX
(Reporter)

Updated

19 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 15

19 years ago
OK, here's the Office 2000 story: Everything is exactly the same as Office 97
SR-2. I also tried Access, and it behaves the same as Word, Excel, and Outlook.
PowerPoint is the odd man out with its (possibly undocumented) Ctrl+Q shortcut.
As things stand, I don't really buy your arguments.

On the other hand, this really is kind of a silly discussion. I'm tired of all
of this cross-platform bickering. I'm going go with trudelle's original comment
and agree that this should say whatever german wants it to stay. I'm going to
mark this bug WONTFIX.
(Assignee)

Comment 16

19 years ago
And in turn, I commit to changing/reopening this the very minute we see a
usability problem with this cross-platform approach to the File menu. We'll get
better data once we enter the usability testing phase. Again this is inexpensive
to change but we'll go in with a cross-platform approach.

Comment 17

19 years ago
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

Comment 18

18 years ago
adding self to cc

I know this is an old bug, but if I may inject my comments...I, too, agree that 
the menu item needs to read Exit on win32.  And I, too, don't buy the argument 
that it's becoming the 'de facto standard.'  I verified all of Chris's 
observations about Office 2K (namely, that it doesn't use "Quit" anywhere, and 
only powerpoint uses Ctrl+Q).  I also do not have a single application on my 
computer [and believe me, I have plenty] that uses File | Quit (*yes*, I 
actually checked).

I have seen no proof that Quit is emerging as the standard, and I don't buy 
german's "look how MS has conformed to Mac in the past" argument as the reason 
for doing this...the look and feel of Windows is still _very_ distinct from 
Mac, and you simply named two examples of where Windows followed mac's 
example.  You also said that many new windows apps are using Quit, but I'm not 
seeing (m)any (can you name some, please?)

I disagree with the resolution of this bug as wontfix simply because the debate 
was getting a little repetitive or silly...that, to me, is not a valid reason 
to close a bug.  Nor is "because that's what the spec says."  I'm not going to 
reopen this because of german's resolution to reopen if usability testing 
reveals problems (although, I don't want this bug to get lost), but I think the 
main purpose of open source is the ability to debate certain aspects of the 
client, rather than closing bugs up because of excessive discussion.

I know this issue has been done to death in the past, but I'm not convinced 
that there's a new, clearly defined standard emerging to use Quit, nor do I see 
a good reason to change.  Were problems reported with "Exit" in nav4's 
usability testing?  

Reasons to use Exit on Windows:

- The majority of win32 apps use it.
- Backwards compatibility [with nav4]
- No usability issues (afaik)

Reasons not to use it:

- To hopefully become part of some supposed trend emerging in the future

If, in fact, Quit did become the standard in the coming years, we could always 
change it to Quit.  I realize some of you would say "it's not smart to change 
the menu item after users are used to it," but that's exactly what we're doing 
now anyways with Exit->Quit.  I also think it's smarter to keep Exit, since 
(despite what is supposedly coming in the future), that IS the standard on 
win32 right now...then, later, if Quit does become more popular, we can change 
to Quit.  At least that way if Quit turns out not to become popular, we can 
keep Exit (otherwise, if we go with Quit now and no 'trend' emerges so we 
decide to switch back, we'll be really playing with the user's head -- Exit -> 
Quit -> Exit)

I realize some of you think it's silly to debate about such a 'trivial' aspect 
of the UI, but I don't feel that it is.  Many parts of the UI don't have a 
native look and feel, and it's out of our control (i.e. we're simply not going 
to use native widgets, and that's that).  This is one thing that's easy to 
change and would make win32 users feel more at home with an app that already 
attempts to alienate them from what they're used to.  I just don't see why 
we're abandoning it.
Keywords: pp
Summary: [PP]windows file menu reads quit but should read exit → Windows File menu reads Quit but should read Exit

Comment 19

18 years ago
I agree with Blake. Surely a large proportion of Windows users instinctively 
close applications with Alt+F+X, if only because it is easier to get at than
Alt+F4. Using `Quit' instead of `Exit' breaks this mnemonic. And I'd much rather 
go with standard menu text pending usability data, than go with non-standard menu 
text pending usability data.

As Christopher Pratt noted in his thorough correction of my earlier comment, even 
where Windows apps use Alt+F4 to exit, it's usually not shown in the File menu -- 
no shortcut is shown at all. So we could easily have
|
|  E_xit          Ctrl+Q
|
while supporting Alt+F4 as well as Ctrl+Q. That way, if Microsoft doesn't change 
their standard to Quit/Ctrl+Q, we will support Alt+F+X and Alt+F4 as we should. 
And if Microsoft does change their standard to Quit/Ctrl+Q, we will have Ctrl+Q 
there ready to be used. (We needn't worry about Alt+F+Q -- nobody will use that 
when they can use the quicker Ctrl+Q instead.)

Updated

18 years ago
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---

Comment 20

18 years ago
I'm reopening this for some concrete reasons on why we're sticking with 
Quit.  "Silly discussion" is not a reason to close a bug WONTFIX.  Valid 
discussion, proof of emerging trends, usability statistics, and 
comments/complaints from the public are.

I'm afraid that we're using the idea of XP-ness as a panacea.  Cross platform 
should not be a reason to *do* something, it should be an added benefit.  Sure, 
it's great if we happen to work out a cross platform UI, but it's the weakest 
form of bond -- a bond between a user's app and a user's OS is much, much 
greater.  I'd think that far more users would notice a contrast between the 
appearance of an app and the appearance of their OS than they would a 
difference between the app across three different platforms.  Not everyone has 
three systems side by side to compare an app's cross-platformness, but people 
WILL notice when the "Exit" menu item that they use all day long in other apps 
isn't in ours.

Yeah, it'll be a bit more work to have different items on different platforms.  
But I think it's worth it for an item that has the potential to be used every 
time the user runs the app.

Comment 21

18 years ago
I hear that one reason we're not doing this is because we don't want to write 
more UI.

So let me get this straight.

We're going to ignore the standard on the world's dominating operating system 
(90%+) because of a silly desire to have our app be the same on three different 
platforms (or just laziness?)

If our strategy is to sacrifice years of UI standard and what users have gotten 
accustomed to, all in the name of having a UI that looks the same on three 
different platforms, than we really need to rethink our strategy.

Comment 22

18 years ago
sorry for spam

s/more UI/more than one UI

Comment 23

18 years ago
Blake, just make a patch (which applies only to Windows) and attach it. This 
would hardly be `writing more than one UI', any more than having `About Mozilla' 
in the Apple menu (which applies only to Mac OS) is `writing more than one UI'.

Comment 24

18 years ago
I was told one of the reasons we weren't doing this is the desire to 'avoid 
writing more than one UI'

And, as you know, I can't very well create a patch right now...although, I 
don't see a purpose to.  The problem here isn't that no one's creating the 
simple patch, it's that no one's giving the "go ahead"   I can't just check it 
in.
OK. The symptom of this bug pissed me off (an entrenched Windows user), I did a 
bugzilla search and found ye olde 4908. I've checked in a fix.

Note that the duplicate UI claim was a sham. There've been duplicate overlay 
files in mac and win subfolders in xpfe/global/resources/ for quite some time 
now, with XUL and text for menuitems. It just so happened that the individual 
Mac and Windows dtd files both read "Quit" ;) My checkin changes Quit->Exit, 
changes the accesskey to x. I left in the command key for backward 4.x 
compatibility (which, strangely enough on windows uses Ctrl+Q, I guess since 
Alt+F4 closes the active window rather than the whole app)
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago18 years ago
Resolution: --- → FIXED

Comment 26

18 years ago
I bow and humbly submit my soul to ben, god of the UI and all things Mozilla.  
And yes, I will bring you donuts at the developer's meeting.

(thank you!)
I dont mean to be annoying but why are we fixing non nsbeta2+ trivial bugs when 
we've collectively agreed to first ship beta2? You start taking little trivial 
fixes indiscriminately and pretty soon we'll slip the goal of shipping this 
beta. 
(Reporter)

Comment 28

18 years ago
Vishy, were we supposed to wait another one year and three months for someone 
to fix this bug? In all seriousness, this was a frustrating usability problem 
for many of us Win32 users, and it made Mozilla look especially idiosyncratic 
on Win32. If you're going to take the time to make this kind of non-
constructive criticism in a bug, perhaps your time would be better spent fixing 
those beta 2 bugs to which you refer.

Comment 29

18 years ago
is now File | Exit on 072408 mozilla win32, NT.   Still File | Quit on Mac and 
Linux.  vrfy fixed.
Status: RESOLVED → VERIFIED
Like I said, I did not mean to be annoying. However we are attempting to ship 
beta and if everyone decides to pull in their own directions, the collective 
ship will not pull in the right direction. If you really feel that the nsbeta2 
process is sham, you should tell jar about it. 

my criticism is not non-constructive. I appreciate that the bug is a polish 
problem and someone needs to fix it. however we've agreed to first ship nsbeta2. 

Comment 31

18 years ago
This bug has been verified fixed, and I don't think everyone on the cc list 
needs (or wants) to hear this conversation.  It sounds like a candidate for 
email. . .

Updated

16 years ago
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.