Closed Bug 4908 Opened 25 years ago Closed 24 years ago

Windows File menu reads Quit but should read Exit

Categories

(SeaMonkey :: General, defect, P4)

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: cpratt, Assigned: german)

Details

(Keywords: platform-parity)

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).
Assignee: shuang → don
OS: other → Windows 98
Assignee: don → saari
Target Milestone: M9
Actually, it should say whatever german specifies. targetting m9
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
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.
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.
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.
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)
Assignee: saari → german
Reassigning to german
Target Milestone: M9 → M10
Moving to M10 - some discussion still underway per German.
Summary: windows file menu reads quit but should read exit → [PP]windows file menu reads quit but should read exit
Setting on [PP] radar.
Status: NEW → ASSIGNED
Priority: P3 → P4
Target Milestone: M10 → M18
Changed mileston for later UI polishment. For now, please follow the spec.
I agree that on Windows the menu item should be called Exit.
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.
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.]
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
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.
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.
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
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
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.)
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
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.
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.
sorry for spam

s/more UI/more than one UI
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'.
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
Closed: 25 years ago24 years ago
Resolution: --- → FIXED
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. 
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.
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. 
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. . .
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.