how to go about user interface design changes

I've just discovered that a team I've been working with produces a Windows app that has what seems to me to be a strikingly bad close dialog, it reads:

"Changes have been made that have not been saved to a file. Do you still want to exit the application?" The options are Yes/No and Yes is the default.

Contrast this to the Microsoft Word close dialog:

"Do you want to save the changes made to document1?" The options are Yes/No/Cancel and Yes is the default.

Note that on our app Yes is the default and will dump your changes into the abyss whereas the Microsoft (and hundreds of other apps) way Yes saves your data. To me this is a poor design, a barrier to learning and a trap to fall into. However it's been like that for years and a number of users are now trained to do it this way.

Am I just being picky? Is this worth changing? How would you inform users of this change? If it was accompanied with enough other chang开发者_JAVA百科es would that cue the user into the fact that the app has been significantly changed?

update: The app is distributed as part of a wider solution but it is the only pc app in the solution.

Yes. The text isn't as important as the default button. The default button should ALWAYS be defaulted to the non-destructive option.

If your application is "document centric", this is plain out wrong.

Generally, I can't imagine an application where unsaved data is so unimportant that it may be thrown away most of the time BUT is worth interrupting the user. (Such an app might exist, but I doubt it).

It's not just a question of style or taste, and it's definitely not nitpicky. Consistency with the OS and common apps is important, defaulting to the safe option is vital - "safe" meaning no loss of data here.

Problem: changing it might make it worse for existing users, they might actually start losing data.

The simple fix is to change the default. It's still irritating, but prevents the worst.

Moving to a standard phrasing safely is harder.

For a safe transition I'd use a non-standard dialog with non-standard button labels. E.g. if this is a Win32 MessageBox with buttons at the bottom, use a custom dialog with buttons to the right, labeled "Save" and discard".

This will give you a horribly nonstandard dialog, but user data is more important than looks. You can revert to a standard phrasing (sanely defaulted) after a few update cycles that you estimate have hit "most" of your users, or the general look of your app has changed (that might be a year or a few).

This dialog sucks, anyway. It's one of the more complicated interactions: what if the user choses "Save", have never named the file, and clicks "Cancel" in the save dialog? Do you cancel the Save, or the Save and the Exit? Most programs opt for the latter, which sends some users into an "want to exit but can't" loop.

Some ideas for alternative handling:
If your app is single-instance and the data is neither hundreds of megabytes nor likely sensitive, you could preserve the last (unsaved) document to be availabel when the app is run again. Similary, you might allwo to recover the last (or last N) unsaved files.

yes it is worth changing, Users usually click on the default button without reading the dialog text.

I would think the best option would be to save changes automatically and implement a revision system that allows you to revert or something. That way you don't have to bug the user at all. Otherwise, you're correct, defaulting to exiting without saving is silly.

It sounds like it may be worth changing, but I would be VERY diligent in making sure that change was obvious. What you are seeing is bad UX, but so is changing expected behavior in an application.