Inconsistent: Quit without saving Firefox, Gedit, OpenOffice

Bug #389876 reported by grofaty on 2009-06-20
68
This bug affects 12 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
Undecided
Unassigned
gedit (Ubuntu)
Wishlist
Unassigned
gtk+2.0 (Ubuntu)
Wishlist
Unassigned
openoffice.org (Ubuntu)
Wishlist
Unassigned

Bug Description

Quit without saving (buttons and order from left to right):
- Firefox: Quit, Cancel, Save & Quit
- OpenOffice Writer: Save, Discard, Cancel
- Gedit: Close without Saving, Cancel, Save
- Evolution (during create message): Discard changes, Cancel, Save message
- Thunderbird: Don't save, Cancel, Save
- GIMP: Don't save, Cancel, Save
- KDE application: Save, Discard, Cancel

Make the same order and options in all programs.

The standard order/labels is:
Don't Save .......... Cancel . Save
<http://library.gnome.org/devel/hig-book/stable/windows-alert.html.en#save-confirmation-alerts>

More on this type of bugs: http://brainstorm.ubuntu.com/idea/17763/

Dolfy (adolf-szabo) wrote :

I second to this. Not only make it consistent, but simplify it as well.

I was a Windows developer a few years ago. There is a standard YesNoCancel MessageBox for such. This way each program writer does not have to create a new form for the message box, but use that built-in one. Simple, consistent, and development is also simpler. So maybe you should add this to Gnome API...

http://msdn.microsoft.com/en-us/library/ms645505(VS.85).aspx

If you want to conquer the enemy, learn its tactics.

Regards. Dolfy

Rich Jones (richwjones) wrote :

X-Posted:

Absolutely not!

This is a _bad_ thing to implement and this is the sort of bug which should _not_ be blindly added in!

Yes, the buttons should be rephrased and reordered to

Save / Don't Save / Cancel

but they should NOT be Yes / No / Cancel. Button labels should always be verbs! This is a basic idea of modern UI design.

Rich Jones (richwjones) wrote :

In fact, having just repeated the bug procedure, I'd say that it's already fine the way it is. Please don't change this!

Changed in hundredpapercuts:
status: New → Confirmed
grofaty (grofaty) wrote :

Hi,
I also very hate Yes/No/Cancel principle from Windows - very bad design. It does speed up development process of application but it harms user experience.

It would be nice that the same word for potentially destructive operation (like closing without saving) is standard way.
Regards

Dolfy (adolf-szabo) wrote :

"This is a basic idea of modern UI design."

Rich, please show me where you see that as a basic idea?

Anyway: if Windows has >98% share of market even if it is not free, that should explain who has right in case of usability on GUI. I hope those set up that basic idea do not belong to the <2%...

Always remember: end users decide on usability, not a committee.

Dolfy

pranith (bobby-prani) wrote :

Dolfry,

Please refrain from arguing for features just because they are present in a majority OS. We are NOT trying to emulate or copy them. We have our own goals and can be as different as we like.

But, yes, I do agree that GNOME as a whole should present a consistent picture instead of the current "each app can create UI as it feels comfortable" idea. The consistency is important from both an aesthetic and usability POV.

Changed in gnome-desktop (Ubuntu):
status: New → Confirmed
pranith (bobby-prani) wrote :

Rich,

If Yes/No is a bad idea, then we can use Save/Don't Save. The point here I think is consistency across the entire applications in default GNOME installation.

Rich Jones (richwjones) wrote :

Oh, I certainly think consistency is a good idea, I just think it's _really_ important that the buttons correspond to actions, not answers to questions.

http://www.usabilitypost.com/2008/08/30/usability-tip-use-verbs-as-labels-on-buttons/

Dolfy (adolf-szabo) wrote :

We fully agree on consistency, and I also accept that you don't like the Yes/No/Cancel approach, still I favor it. Just a stylistic comment. If you are asked a question:

Save the current unsaved document?

Then the logical answer to this is Yes or No, and not 'Save' or 'Don't save'.

Regards, Dolfy

Ben M. (bmhm) wrote :

There is a Gnome Human interface guide line:
http://library.gnome.org/devel/hig-book/stable/

What you are actually looking for:
http://library.gnome.org/devel/hig-book/stable/windows-alert.html.en#save-confirmation-alerts

"Save confirmation alerts" - there is a rule for this window. It really makes sense and should be obeyed in all apps. I'd just recommend to put the red cross to "close without saving", because this is actually the most harmfull action.

Well, the pity is: Neither Firefox nor OO.o are gnome-apps.

grofaty (grofaty) wrote :

"Always remember: end users decide on usability, not a committee." ...and monopoly. :) But I don't want a flame here. Please make this bug report to something usefull.

"Save the current unsaved document? Then the logical answer to this is Yes or No, and not 'Save' or 'Don't save'." I agree. But I have also seen applicationa that are asking: "Do you really want to discard changes? Yes/No/Cancel"

grofaty (grofaty) wrote :

Dolfy, one more thing about Yes/No/Cancel buttons, I really hate to read all this kind of message text that are constantly appearing on screen. If I see "Save" button then I know that program is asking about saving if there is only Yes/No button, then I have to read the whole message displayed in message box - not user friendly it consumes my precious time. :)

Dolfy (adolf-szabo) wrote :

"Do you really want to discard changes? Yes/No/Cancel"

Yep, this is totally sad. That is why requested operation should be put on first:

"Save current document....?"

so that user does not have to read through the line(s) to make a decision.

About monopoly: yes it is. But users made it a monopoly, because they decided that the free alternative is not good/consistent/easy for them enough. Do not take it as a critique of your work, I just try to help Gnome gain a bigger market share. ;-)

Regards, Dolfy

Sebastien Bacher (seb128) wrote :

gnome-desktop is the about GNOME dialog and a library to work on desktop entries nothing to do with this bug

affects: gnome-desktop (Ubuntu) → ubuntu
Vish (vish) wrote :

Consistency Is a good idea... but i do NOT believe it is easily fixable , unless an industrial UI standard is agreed upon by all the different open source organizations.

Vish (vish) wrote :

@grofaty:
Pls mark[as Also affects Project] all the apps where , the close shows the 3 options in that bug. so that a standard could be disucssed & maintained through out.

Luke Faraone (lfaraone) on 2009-10-07
affects: ubuntu → firefox (Ubuntu)
Changed in firefox (Ubuntu):
importance: Undecided → Wishlist
Changed in gedit (Ubuntu):
status: New → Confirmed
importance: Undecided → Wishlist
Changed in openoffice.org (Ubuntu):
status: New → Confirmed
importance: Undecided → Wishlist
John Vivirito (gnomefreak) wrote :

This is not a package problem but more of a gtk or gnome bug since by the looks of it affects alot of GTK apps that are unreleated

affects: firefox (Ubuntu) → gtk+2.0 (Ubuntu)
Changed in gedit (Ubuntu):
status: Confirmed → Won't Fix
Changed in openoffice.org (Ubuntu):
status: Confirmed → Won't Fix
description: updated
description: updated
description: updated
description: updated
description: updated
Matthew Paul Thomas (mpt) wrote :

It is annoying that the KDE standard layout is inconsistent with the Gnome standard layout, but KDE has their own guidelines for this <http://developer.kde.org/documentation/standards/kde/style/dialogs/simple.html#yesno> just like Gnome does.

The only application listed here which is doing the wrong thing is OpenOffice.org, which is marked as Won't Fix.

description: updated

Since this is not an easy thing to fix (as has been pointed out in earlier comments) it does not qualify as a paper cut.

Changed in hundredpapercuts:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers