Ambiguous wording in confirmation alert box

Bug #349336 reported by Murat Gunes on 2009-03-27
This bug affects 2 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
computer-janitor (Ubuntu)

Bug Description

Binary package hint: computer-janitor

After choosing one or more of the packages Computer Janitor offers me for removal, I'm shown a confirmation alert box where it suggests that this action "may break my system, if I need them".

Users who know the packages they don't need can be assumed to be able to clean them up themselves, without having to rely on Computer Janitor's judgment. For users who don't, the sentence "This may break your system, if you need them" will only create fear and confusion: if the packages may still be needed, why did the software offer to remove them in the first place? Can its judgment of what is needed and what isn't not be relied on? And if not, how is the non-technical user supposed to know whether the action will "break her system"?

Possible replacement (I haven't yet given much thought to this; it can probably be improved):

Title: Are you sure you want to remove these packages?

Body: You are about to remove [n] software packages. Please verify that they are no longer needed on your computer. Do you want to continue?

Changed in computer-janitor:
status: New → Confirmed
to be removed (liw) wrote :

The judgement of computers cannot ever be fully relied on...

I'm not sure which wording would be better. I would like it if people who don't know what they do would not accidentally remove packages by mistake, and thus I chose a fairly severe wording.

I'll be happy to reconsider the wording for karmic. For jaunty, we're past the string freeze, so any changes to it would require a freeze exception, and I'm not currently sure it's worth it. I'm happy to be convinced otherwise by enough people telling me they really hate the current wording.

Markus Korn (thekorn) on 2009-03-27
Changed in computer-janitor (Ubuntu):
status: Confirmed → Triaged
Mat Tomaszewski (mat.t.) on 2009-06-12
Changed in hundredpapercuts:
importance: Undecided → Low
status: New → Confirmed
Ivanka Majic (ivanka) on 2009-06-17
Changed in hundredpapercuts:
status: Confirmed → Triaged
Mat Tomaszewski (mat.t.) wrote :

This one is waiting to be fixed, do we like the initial proposal, or does the message need to articulate the warning more strongly?

Changed in hundredpapercuts:
milestone: none → round-2
Åskar (olskar) wrote :

I'm not sure the "Are you sure you want to remove these packages?" will help either, but then again, I would call the entire janitor a papercut. A user seeing that message will probably be afraid too and close the janitor. That is a lot more likely than the user starting to googling every package to check if it's safe to remove. I have said so before, and say it again; the computer janitor should not even offer to remove packages the user needs! How do we know what the user needs? He probably wants to keep the manually installed packages at least..?

Laura Cowen (lauracowen) wrote :

I agree with Åskar. I raised the dupe of this bug - my main problem with Janitor is that either it needs to take responsibility and just remove the packages with confidence, or it should provide all the info that the user needs (in a form the user understands) to make the decision. Saying 'Are you sure?' is pointless.

to be removed (liw) wrote :

Very well, let's remove janitor. I am not ever confident enough to say that specific packages are always safe to remove.

shafin (mahdee-jameel) wrote :

I think Janitor should remain, but there needs to be a way to differentiate between user created cruft (manual packages) and system created cruft.

Andy Clayton (q3aiml) wrote :

Perhaps having a history of changes would help (with the ability to rollback/reinstall). Then users could be more confident knowing that, should things go wrong, they can always come back and click undo. This somewhat relies on the assumption that users who don't know what they are doing would stick to software from repos, which could easily be reinstalled, but if less technical users are being forced to manually install debs then that sounds like another paper cut.

Design suggestion:
  * See attached mockup.

Design suggestion (revised):
  * See attached mockup.

Mockup reflects change in wording (in labels and on buttons) only.

I'll take a look at it. If not heard from me in a day I didn't have the time.

to be removed (liw) wrote :

I am still convinced that until there is a reliable way to detect packages that are safe to remove (and solve the halting problem), toning down the wording such that people will (again) remove packages they want to keep and thereby break their systems is a bad idea. I don't wish that to happen.

So, should I change the text?

I don't think we've "toned down" the text. We give the user fair warning that removing packages can cause errors, and we ask for an administrator's password. In lieu of solving the halting problem, Marcus, please proceed.

After running the application I'm not sure if we should call it "remove packages" as it's not only packages that will be removed. As in my attached screenshot - it also shows a file that will be removed.

However, I've created a patch with the new text.

Please review the patch as I'm not that sure of the correct way to set buttons text/icon.
Also if no packages is selected - the message is just: "Do you want to continue?"

Cody Russell (bratsche) wrote :

If I'm reading the patch correctly, it seems that you're changing the response types in the buttons but not in the actual dialog response handling.

dialog = self.gtk.MessageDialog(parent=self.window_main,
- buttons=self.gtk.BUTTONS_YES_NO,
+ buttons=self.gtk.BUTTONS_NONE,

The response types were GTK_RESPONSE_YES and GTK_RESPONSE_NO before..

+ dialog.add_button(self.gtk.STOCK_CANCEL, self.gtk.RESPONSE_CLOSE)
+ remove = dialog.add_button(self.gtk.STOCK_OK,self.gtk.RESPONSE_YES)

And here the buttons added use GTK_RESPONSE_YES and GTK_RESPONSE_CLOSE.

If I'm not missing anything here, the cancel response code is not important.

The rest of the code goes on with this;

        response =
        if response != self.gtk.RESPONSE_YES:

        cleaner = Cleaner(self, crufts,

Cody Russell (bratsche) wrote :

Okay cool, I didn't look at the full code only the patch. I'm at Guadec and the network isn't responding very well, so I never got to respond to your actual question.. so here is my only other thought on the patch.

+ #FIXME: is there a better way to set the title AND have a stock icon?
+ remove.get_children()[0].get_children()[0].get_children()[1].set_label(_("_Remove Packages"))

There's not really a way to change the text in a more direct way without messing up the icon (because conceptually, stocks are really "icon + text" combinations so using button_new_from_stock is really just a convenience function), but if you want to do something a little less cryptic looking (although maybe with a bit more code) you could do something to the effect of:

void set_button_text_and_icon (GtkButton *button, gchar *stock_id, gchar *label)
   gint image_spacing;

   gtk_widget_style_get (GTK_WIDGET (button),
                           "image-spacing", &image_spacing,
   hbox = gtk_hbox_new (FALSE, image_spacing);

   image = gtk_image_new_from_stock (GTK_STOCK_CANCEL);
   gtk_box_pack_start (hbox, image, FALSE, FALSE, 0);

   label = gtk_label_new (_("_Remove Packages"));
   gtk_box_pack_start (hbox, label, FALSE, FALSE, 0);

   gtk_widget_show_all (hbox);
   gtk_container_add (GTK_CONTAINER (button), hbox);

Sorry, I'm not familar with pygtk so this is the best I can offer. It's up to you, this is just a suggestion that I think makes the code a little bit more obvious in my opinion.

Changed in hundredpapercuts:
status: Triaged → In Progress
Matt (mjz) wrote :

I personally would prefer to do something like this:

button = gtk.Button(_("_Remove Packages"))
image = gtk.image_new_from_stock(gtk.STOCK_CANCEL, gtk.ICON_SIZE_BUTTON)
dialog.add_action_widget(button, gtk.RESPONSE_CANCEL)

Just my personal preference though.

Thanks Matt, that looks much better. I'll change my patch later.

l-x-l (labouie) wrote :

As a snew Ubuntu user (non-programmer), I like David Siegel's mock-up on post #10 best.

Matt, I tried your code but the button gets higher than the cancel button, see attached screenshot. Why?

Matt (mjz) wrote :

Hmm, I just tried it and the buttons were the same size for me. Maybe something like this will work better?

button = dialog.add_button(_("Remove Packages"), self.gtk.RESPONSE_YES)
image = self.gtk.image_new_from_stock(self.gtk.STOCK_OK, self.gtk.ICON_SIZE_BUTTON)

I have no idea why the size would be different; I'd never heard of either method changing the button size.

Thanks, that worked! :-)
Updated patch.

to be removed (liw) wrote :

Replacing the text "Really clean up" with "Are you sure you want to remove these packages?" is wrong. The janitor does not just remove packages.

Note also that I'm replacing the entire UI with a new design and implementation, see the lp:~systemcleaner-hackers/systemcleaner/new-ui branch.

Lars, will your updated UI land in Karmic?

to be removed (liw) wrote :

David, yup, once I polish it some more and get back home.

to be removed (liw) wrote :

I've uploaded the new UI with a hopefully acceptable new dialog to my PPA

The upload is still processing as I'm writing this, the version of interest has ppa5 at the end.

The issue is more complicated than the mockups that have been posted in this bug allow for. CJ does not only remove packages, it does other kinds of things as well. That's why all wording specific to package removal needs to be adjusted if there's other stuff happening as well.

However, I'm capitulating and accepting the toned down wording. I expect this will cause a few people removing stuff they shouldn't, but I don't expect to have to deal with the bugs after karmic so I don't have the energy to stand my ground on this issue, either.

Changed in computer-janitor (Ubuntu):
status: Triaged → Fix Committed
Vish (vish) on 2009-08-19
Changed in hundredpapercuts:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package computer-janitor - 1.13.2-0ubuntu1

computer-janitor (1.13.2-0ubuntu1) karmic; urgency=low

  * New upstream version. Closes bugs in Launchpad:
    - System cleaner removes explicitly installed third-party packages
      (LP: #285746)
    - I do not want to remove '/' (LP: #337241)
    - computer-janitor incomplete error description (LP: #365325)
    - computer-janitor commandline interface not pipe-friendly (LP: #375094)
    - Python 2.6 DeprecationWarning: Accessed deprecated property
      Package.candidateDownloadable (LP: #407127)
    - Should use GtkBuilder rather than libglade (LP: #403537)
    - Ambiguous wording in confirmation alert box (LP: #349336)
    - computer-janitor-gtk crashed with UnicodeDecodeError in
      get_description() (LP: #352461)
    - Can't deselect fixes with space in computer-janitor (LP: #355535)
    - relatime tweak will not be necessary in karmic (LP: #369151)
    - computer janitor needs filesize column (LP: #396522)
  * Packaging now uses dh from debhelper 7.

 -- Lars Wirzenius <email address hidden> Fri, 21 Aug 2009 15:48:12 +0300

Changed in computer-janitor (Ubuntu):
status: Fix Committed → Fix Released
Andrew (and471) on 2009-09-02
Changed in hundredpapercuts:
status: Fix Committed → Fix Released
antistress (antistress) wrote :

I'm perplexed by this bug.

To sum up things, a user with a perfectly working system may ask Computer Janitor to do some cleanup. Then Computer Janitor will suggest to remove some packages. If the user decides to follow this advice, Computer Janitor will then warn him : "Hey ! Don't play fool you may break everything"

It's unfair that Computer Janitor gives non-reliable advices and ask user to assume all responsibility.
I don't think that replacing a warning (« This may break your system, if you need them. ») by another (« Removing packages that are still needed can cause errors. ») can be called a bugfix

Computer Janitor should be secured or removed

Vish (vish) wrote :

This bug report is about the ambiguous wording in the app. Hence that was fixed...
What you mention is the subject for a separate bug report. Kindly open a separate bug report.

antistress (antistress) wrote :

ok, that's bu#482647

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