Should an application have File >> Exit?

[Aristos Queue]

Newer applications on MS Windows have removed "Exit" from their menus. They either rely upon the user using the [x] on the application window or on someone right-clicking on the MS Windows task bar and choosing "Close Window" as their signal to exit.

 

LabVIEW has a plethera of windows open and no "master window" to close them all, so we still need a File >> Exit, but most applications that I've seen written *with* LabVIEW are single window applications (or single master window with floating supports, which amounts to the same). So, I'm curious... when you folks are writing your applications, have you started leaving out File >> Exit? What are your thoughts on that trend?

[hooovahh]

I realize that you shouldn't really give a user too many ways of doing the same operation.  Otherwise you get a fragmented experience between users.  But I think this case is common enough that maybe some percentage of users prefer File >> Exit (for whatever reason) over another method of exit.  

 

Do I use File >> Exit?  Nope, but it's in my programs.  If I was using a program and found File >> Exit was missing I wouldn't care, but in the back of my mind I would think the developer forgot to put it in, rather then deciding to leave it out.

 

Oh and I just check Word 2010 and File exit is still there.  Has it been remove in newer versions?  Now that I'm looking at it I notice they moved the help to be under File, which I also don't like.

[Jordan Kuehn]

It usually depends on the customer for me.  Some customers get no menu bar.  Other customers really miss a menu bar so I'll make them a custom menu which has some minimal functions.  Then some applications really just need a real menu with lots of functionality in it.  In the latter two cases I'll include a File>>Exit.

[Gribo]

File exit keyboard shortcut is Alt + F, and X usually. Without a menu option, it is Alt +F4 (Windows and some linux distros) which is a bit harder to press with the left hand. This can be either good or bad, depending on the application.

[drjdpowell]

 So, I'm curious... when you folks are writing your applications, have you started leaving out File >> Exit? What are your thoughts on that trend?

I’ve obviously not properly thought about, as I had to check my latest app and found I’ve left File>>Exit in but not trapped it to shutdown properly.  Opps!  I always trap "panel close” as a shutdown command.

[Mads]

Microsoft has been messing a lot with the GUI lately. I think this article sums it up quite nicely: http://www.nngroup.com/articles/windows-8-disappointing-usability/

 

Most programs I make have multiple windows, but they also have a main window, which is the one that is shown after startup (once the splash screen has disappeared). The main window then has File>>Exit (Ctrl+Q).

 

If I had an application with multiple windows that could all be perceived as "main" (meaning for example that it makes sense to have the app running with just one of them open), I would add the exit option to each window. It should be possible to shut-down the whole app without having to close each window individually, and the File>>Exit option is a well established and hence intuitive way to to that...

[dsavir]

If the program has a File menu, it should have a File>>Exit. Most users expect this, even if it's possible to close the X in the right corner. Also as Mads said, if there is an application with multiple windows it becomes mandatory so that users don't have to close every window individually.

 

If it's a small program or doesn't have a File menu, the X in the upper right is sufficient, I think.

[Neil Pate]

I always put File-->Exit on every application that has a menu-bar, however my personal preference (as others have also said) these days is to handle the Panel close event so I put in both.

 

To me the only no-no is a big fat Exit button on the GUI.

[mje]

Yeah, the Windows user experience on a desktop or workstation environment is a hot mess of inconsistencies at this point and hardly something to model after in my opinion. Especially since Microsoft has a track record of doing a complete about-face with regards to their guidelines (nevermind APIs), I don't exactly expect the current way of doing things to be around that long. Windows 8 is irrelevant to me: it interferes with pretty much every workflow I have, LabVIEW or otherwise. Maybe Microsoft will get something cohesive for the next iteration, or perhaps they'll fade from relevance, I don't really care which happens but I expect change.

 

That said, if I have a main window with a menu containing a file item or equivalent, I'll throw a file exit command in there. My applications usually behave such that supplementary windows simply close if the system close button or keystroke is used, but the main window will interpret the close command as an exit signal, which will tear down any supplemental windows that may be open. Supplemental windows with menus never have a File > Close command.

[hooovahh]

To me the only no-no is a big fat Exit button on the GUI.

You mean a giant red boolean labeled "STOP".  Because to a user using an application stop obviously means exit or close right? Stop the execution of the program isn't what I think when I am trying to close file explorer, or chrome.

[ohiofudu]

I use File->Exit when I have menu in my GUI.Most of my Apps are used in production lines.STOP(red) Button are most appropriate for the Operators.

[Tim_S]

It depend on the intent of the interface. Configuration, applications with multiple windows, etc., get a File->Exit in the menu. My applications that run as services have a icon in the system tray that can be right-clicked to exit the application, but any pop-ups have a close only. One application that is intended to fill the window and does not have a title bar or menu does have a "computer power" icon in the lower corner that is used to shut down.

[hooovahh]

Most of my Apps are used in production lines.STOP(red) Button are most appropriate for the Operators.

What I was referring to is developers who use a big red stop button to stop a while loop from running. Leaving their programs in limbo where the program isn't running, but the run-time engine is still open.  Stopping an operation or function means something to a operator.  Stopping the program might not be what they are thinking about.

[JackDunaway]

If you're thinking about dropping this into the "Resetting VI..." dialog, I'd gladly take a "File >> Exit" ... a [X] button ... a big red [sTOP] button... 

 

In all seriousness, I've not even considered removing this menu option.

 

(... beyond, using the OS X and more sane standard of placing "Quit/Exit" under the main application menu rather than "File", which I guess causes less theoretical cognitive dissonance, if not actually moving the needle on actual UX for those of us with years of Windows experience. For what it's worth, my #1 UX consultant -- my 2.5yr daughter -- tends to naturally swipe at screens as if shooing away -- to exit applications. This is how iOS works after tap-tapping the Home button. Though having once been a touch screen designer, let's agree arm movements and fat fingers will not and can not displace a mouse from 8:00-5:00 for ergonomic health reasons, and Win8/touch/mobile trends that bank on this will likewise not win out.)

[GregFreeman]

If my application has a File menu, it is my gut instinct that the exit should be there. That is my expectation because that is what I am accustom to. That doesn't mean I, or anyone else actually uses it, but I still feel it's expected. Whether or not that is the right place for an exit menu item is obviously debatable, but Microsoft has dictated that in the past and I feel consistency with the environment that a user is familiar with is most important. However, environments are changing. What is familiar to me is fading (can I just have a tools->options.. menu in Word, please?). But, if the ribbon is all one knows, which is most likely the case with the youth of today, then a tools menu to them may be what the ribbon is to me (confusing). File -> Exit may still be expected for those of us who went through the past few decades, but in that case are we the right people to ask this question to? Who knows what will come next. Will those expectations remain? For how long will they remain? What platform we are on dictates these sorts of things as well. Notice, you can change configuration settings on your phone, but there is no need to press save. Does that mean we should remove a save button from MS Word? Probably not (although auto save seems to be common in many applications now).

 

So, I haven't given you a clear answer, per se, but I am just vomiting out all my words through my fingers and hoping they provide some insight.

Edited April 25, 2014 by GregFreeman

[Val Brown]

It's interesting to believe that 10 or more years old keyboard and mouse based (not even trackpad) UI is going to remain the prevalent benchmark.  I strongly suspect that touch interfaces and other gesturing (perhaps some kind of "Leap" process) will supplant physical keyboards and mice like they supplanted punch cards and magnetic tape.

 

MS doesn't have a great track record in developing, let alone inventing, UIs so I also strongly suspect that it will an iOS style user experience that will continue to "lead the way" (as what the US Army Rangers do).  It's intuitive -- unless you have years of physical keyboard, mice and File>> kinds of meaning -- and that is what users want.  It really is that simple, esp now that XP is going to whither on its own vine.