Unfortunately, the option of how to save changes, explicit vs. implicit save, and our choice of command names has already been dictated. With a few specialized exceptions, we as Windows developers are expected to adhere to the GUI standards which Microsoft has laid down for us.

I'm somewhat divided about the benefits of an explicit edit vs an implicit one, and an explicit save vs. implicit. However, Microsoft has already spoken on this one.
You select your Word or Excel document from a file list, much as a user selects a record from a search list. When the document is selected, it is opened in edit mode, ready to go. Therefore, when the user selects a record, it should be presented in edit mode, ready for the user to make changes.
When a user has finished modifying their Word or Excel doucment, they must click the Save icon or celect the Save or Save AS option from the menu. If they exit the application without first saving their changes, the application warns them and gives them the option. Following this standard, we should require an explicit save, and prompt the user to save their changes when they exit the form or application.

Every Microsoft application has the standard menu options on the File, Edit, and Window menu. Through repetition, the user has been taught that if they click the File menu, they can expect to find several options which are common to all Microsoft applications, including the Save As option. If we were to unilaterally decide to change the Save As option to Copy File, the new user would be lost in an instant, and even the experienced user would wonder at the deviation from standards. Likewise, when I highlight some text and press Ctrl-X, I expect the text to be removed from my document, and I should be able to return it with CTRL-V. If I changed the cut keys to CTRL-S (for Snip) and the paste keys to CTRL-P (for Paste), all sorts of problems would ensue, since both of these key combinations are used for something else in all other Windows applications.

The use of the mouse is another thorny issue. Without getting into the inevitable debate of mouse-vs-keyboard, let me simply state this: anything, and I do mean ANYTHING, that can be done with the mouse MUST have a keyboard equivalent. This is especially crucial when dealing with heads-down data entry clerks who may only use the mouse to select the application, then never touch it again. ALT-F4 is still the preferred way to end the application, and it should behave no different from clicking the Close button on the title bar.
In the same heads-down manner, any dialogs which appear MUST have some sort of audio indicator, and if possible, should NOT have single-stroke hotkeys. Many is the time when I'll be typing away at something, a dialog from another application will appear silently, I won't realize it, and suddenly I've gone from a FoxPro code window to an Outlook e-mail message or a Novell print administrator window becuase the dialog's command buttons had Y or N defined as hotkeys. Removing the hotkeys from the command buttons requires the user to read it, tab or mouse to the desired button and click it. I would also recommend the use of combination keys, such as CTRL-Y, but this is a dicey decision that should only be implemented when there are more than two or three options, and the key combinations do not conflict with any exisitng Windows key combinations. This is a blatant violation of the GUI standard, and should not be taken lightly.

Remember the days of DOS, when the word processors of choice were WordStar, WordPerfect, and your friendly neighborhood text editor? No consistency of interface, no portability of knowledge from one application to another. As much as we may slam on Microsoft, they did the user community a great service by creating the standard Windows interface, and enforcing the interface standard with the "Windows compatible" logo. There are a lot worse decisions we could make than to follow their lead. When the next great paradigm shift occurs to the user interface, then we'll have room to be creative.

Bill Yater