Open Bug 851698 (checkboxes-that-kill) Opened 9 years ago Updated 3 years ago
[meta] Get rid of options that kill our product
In the article http://limi.net/checkboxes-that-kill, we talk about the options and checkboxes we include as standard in Firefox that makes it possible to shoot yourself in the foot and get Firefox into a state where it is (to most individuals using it) effectively broken. This is a meta bug to track these issues, feel free to suggest additional checkboxes and functionality that I've missed.
It's not really an option, but "work offline" should also go away.
(In reply to Mark Straver from comment #1) > Users are going to shoot themselves in the foot regardless, because they > will touch settings they don't understand. That doesn't mean we shouldn't try to help them - indeed, that's our job. > You can't hope to prevent > misconfiguration of the browser, no amount of hiding controls will make this > better I disagree.
I suggest doing something to stop people from entering Caret Browsing (f7) bug 194937, bug 374292, or bug 454520.
Very bad idea! Either move those options to the advanced tab or make about:config more usable but removing the options is just going to annoy users. I used several of these options myself in the last week! I shouldn't have to download plugins, and I will not.
I'm agree, that sometimes showing all options in one long list isn't good and may confuse some low-experienced users, but I'm twice, no, _thrice_ agree with those, who would like to see them in "Advanced" tab/section rather than do not see at all. Please, remember, that the more users the product has, the more variety of working conditions they have got and thus the more configuration abilities they may need. Did you ever use Firefox in situation when you are on a very slow and unstable channel with extremely expensive traffic ("Work Offline mode" and "Disable images" are killer features in this case)? Did you ever use Firefox in a situation, when your sweet-sweet government tries to cut you off from some internet sites that you shouldn't see (as they consider it) and you have to "dance with a tambourine" to figure out what's going on (that's why all that SSL/TLS options may need, for example; you may say, that extensions can be used for that, but it's impossible, if addons.mozilla.org is already blocked; luckily, it's a rare situation, but now no one can give you a warranty that it will never happen, as soon as the Russian internet access becomes more and more severe within every year)? In any way there are many reasons for not throwing all these options out, at least as long as they do not break the browser code, however I would vote for an "Advanced Settings" options set, which I personally consider the best compromise between both advanced and none-advanced users requirements. And if you still thing I'm wrong, just remember the classics: "It is impossible to make anything foolproof, because fools are so ingenious", "Those who try to build idiot-proof systems always underestimate the persistence and ingenuity of idiots", "You can make something foolproof, but not damnfoolproof", "If you create a system that any idiot can use, then only idiots will find it useful" and so on (some more quotes here: http://c2.com/cgi/wiki?IdiotProofProcess and here: https://plus.google.com/117373186752666867801/posts/YRXKqrJqcqe). Please, do not continue **** off the advanced users! There's really no need to fix what has never been broken.
"Use about:config" is a fine answer for testing and power users. Should you get the scary warning every time? I agree, no -- but that's a different bug (note bug 797722 where Firefox for Android "here be dragons" warning was nixed). /be
This discussion is interesting and important, but I feel bugzilla isn't the right place for this. Is there a UX mailing-list? (I haven't been able to find one) A crucially important point in Alex Limi's post is: "[When an advanced pref has been changed by mistake] For the general population, Firefox will appear broken.". Firefox reputation has suffered from problem which aren't directly due to Firefox (add-ons for perf-related problems is one example). We do not need more of this. Given the huge user population of Firefox, "my kid played around with advanced prefs" is a use case to be seriously taken into account. This is my interpretation of this bug: removing footguns and improving mitigation mechanisms so that it's harder (not impossible, but harder) for regular users to do something stupid. Now, advanced prefs are important for advanced users. As an advanced user myself, playing with about:config is acceptable for what I do. The advanced option tab is already very populated and it's easy to access to kids while you really have to mean it when you type "about:config". Are there specific use cases for which about:config would be inappropriate? If so, what would be an equivalent mechanism to about:config (in the sense that you need to mean it to access it)
(In reply to David Bruant from comment #9) > If so, what would be an equivalent mechanism to about:config (in the sense > that you need to mean it to access it), but less annoying/more usable? (sorry for double post)
The problem with about:config is that it lacks discoverability. I'd rather see an "Advanced Mode" option dialog than further rely on the undocumented about:config.
(In reply to David Bruant from comment #9) > Are there specific use cases for which about:config would be inappropriate? Try disabling images or whichever option you want (and never changed in about:config before) without an internet connection to Google for the appropriate preference name. Maybe a tree-like presentation would help, but it's nowhere near usable right now. I won't extend further since you're right this is not the place to discuss.
(In reply to David Bruant from comment #9) > This discussion is interesting and important, but I feel bugzilla isn't the > right place for this. Is there a UX mailing-list? (I haven't been able to > find one) I've found a usability mailing-list. I'll give my position to the most recent comments there: https://groups.google.com/d/msg/mozilla.dev.usability/sVP6sCzsWdo/DvZan3NX2LgJ
(In reply to Timothy Warren from comment #11) (In reply to elkaoD from comment #12) (In reply to i4csgqja from comment #13) Answers posted on the thread https://groups.google.com/d/msg/mozilla.dev.usability/sVP6sCzsWdo/DvZan3NX2LgJ
(In reply to i4csgqja from comment #13) > What if I don't want firefox to write anything to disk for security reasons You can turn on permanent Private Browsing Mode in the privacy options. That's what it's for.
Should we also remove the ability to remove page styles from the menu (View | Page Style | No Style)
The dev.usability newsgroup isn't really followed by most developers or UX designers, due to the historically poor signal-to-noise ration. If you have constructive comments, the firefox-dev mailing list would probably be a better choice; see https://wiki.mozilla.org/Firefox/firefox-dev.
One question related to implementation that may already be answered, when we do push these changes, will we be leaving the existing prefs as is, or will we reset them? For example, if a user has unknowingly unchecked "show images" and in the process of trying to fix their problem, they update to a version of Firefox that doesn't have that checkbox, the chances of finding that option are slim, leaving them with a broken Firefox forever (unless they Reset). Should we reset these prefs as we remove their checkboxes, and then, if the user really wants them, they have to go back to about:config to turn them back on? This may irritate some users.
Resetting the options that are removed makes sense if we're assuming that there are lots of people that have shot themselves in the foot with them. If that is the decision made, one idea might be to show a first run page just to those that the pref(s) are reset explaining the situation and pointing them in the general direction of how to put it back or to better alternatives. (some article put up on SUMO, maybe)
Summary: Get rid of options that kill our product → [meta] Get rid of options that kill our product
You need to log in before you can comment on or make changes to this bug.