Open Bug 851698 (checkboxes-that-kill) Opened 11 years ago Updated 2 years ago

[meta] Get rid of options that kill our product

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect

Tracking

()

People

(Reporter: limi, Unassigned)

References

(Depends on 1 open bug,
URL
)

Details

(Keywords: meta) 

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.
Depends on: 851701
Depends on: 851702
Depends on: 851704
Depends on: 851706
Depends on: 851707
Depends on: 733632
No longer depends on: 851706
Depends on: 469260
Can't you just move these preferences to an extra tab/category with a "here be dragons" warning instead? I've personally regularly used the "load images" "javascript" and most certainly the certificate manager (essential access!). And I assume there are plenty of other users who need these options as well on occasion.

Users are going to shoot themselves in the foot regardless, because they will touch settings they don't understand. You can't hope to prevent misconfiguration of the browser, no amount of hiding controls will make this better - it just causes inconvenience for the people who DO need them.
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.
Most of these options highlight website issues, not browser issues. Google uses an image to show the searchbox, some sites foolishly use javascript to render the page. 

These are not broken, nor do they "break" the browser. 

Disabling TLS or SSL does seem a bit strange, though.
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.
I read the article and wonder what kind of madness is that, is the "users are confused by functionality" from the gnome interface nazis contagious ?

first I should say that I'm a power user with over 50+ tabs open at anytime in my browsers and have added 4GB of RAM just to be able to do this comfortably.

The point about loading images automatically shows google chose to over optimize to the point of breaking under certain circumstances, but this only show a broken website not a broken browser. 

One of the main reason I switched from firefox to opera as my main browser is that it is way faster and convenient to disable/enable javascript in Opera (press F12 and click). I do this multiple times a day and if there's something wrong with this option in firefox it is that it is buried down and with no option to make it readily accessible (shortcut or button).

Turning off navigation is something vital for using firefox as a kiosk browser, not something I do every day, but still something vital once in while. Though here again Opera offers a far superior kiosk mode.

I can't think of a case where I had to disable ssl/tls in recent years, but it was useful when needed and I could not care less about google services being broken without ssl. If anything it's the error message that need to be fixed not the option to be removed.

Removing the certificate manager would mean that firefox would be useless for a significant part of my daily web usage as firefox fails to provide the certificates I need by default

What if I don't want firefox to write anything to disk for security reasons or because the computer doesn't have a disk ? from the top of my head I can think of a couple usage scenario I encounter weekly where it is critical for me to disable caching for a limited period of time.

Then the reasoning about removing options not used by 2% of user is really stupid, when you have removed 50 options used by 2% of users, you have effectively alienated 100% of the user base. Then again among these 2% might be the early adopters and power users that make your product what it is.

In short don't think the browser is broken because some prominent websites have made choices relevant to them that break their site under a certain set of circumstances, you can safely assume that removing freedom of choice is bad, always. If you really have to go with this madness of alienating users, at the very least just move the options where the general user will not easily find them instead of removing them.

But if possible IMHO it is better to make them useful than to remove them or move them away.
(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.
Restrict Comments: true
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)
Depends on: 864065
Depends on: 870545
No longer depends on: 851704
Depends on: 581647
Summary: Get rid of options that kill our product → [meta] Get rid of options that kill our product
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.