[yellowapple]

The vast majority of the described problems would be solved if Firefox provided more/better documentation and help text alongside such options. Or better yet, they could be solved by Firefox displaying warnings if pages appear to rely on certain settings.

Javascript disabled and a site relies on it? "Hey, this site would probably work better if you enabled Javascript, but you have it disabled. Would you like to enable Javascript again? Or perhaps just for this page?"

SSL/TLS disabled? "Hey, so TLS is disabled, but I need it in order to show you this web page. You want me to enable it for you?"

The overarching theme here is not that there are too many options, but that there are too many poorly documented options with poorly documented consequences. Fixing that problem would give users the best of both worlds: flexibility and ease-of-use.

[m45t3r]

This wouldn't work, the majority of users don't read so they would blame Firefox either way. And showing message box every damn time one site has Javascript/SSL (and considering that almost every site nowadays has one or another) would infuriate the users that really want to use this feature. It's a lose-lose option.

I think it's fine to have these options as extensions or even inside about:config, where the user would never disable by accident.

[yellowapple]

> This wouldn't work, the majority of users don't read

If they don't read, then they wouldn't be using Firefox, since all web pages (barring a few exceptions) would be gibberish to them :)

> And showing message box every damn time one site has Javascript/SSL

That's not what I'm advocating in that particular recommendation. I'm more advocating for some sort of heuristic analysis when Javascript is disabled. There are lots of sites that do silly things like rely entirely on Javascript for rendering text (for example); those should be easy-to-detect as scenarios where a warning would appear.

Also, most similar warnings presented by Firefox already (usually about outdated plugins and such) have a way to permanently dismiss, or to remember a setting for a particular website, or some other way to mitigate the understandable annoyance of always throwing warnings. A "don't ask me again" would immediately resolve the problem you identified.

> I think it's fine to have these options as extensions or even inside about:config, where the user would never disable by accident.

I think that's fine, too. My comment was more about identifying the correct cause of various effects - i.e. that the harmfulness of the checkboxes being criticized is due to their non-obviousness rather than their existence.

[JonathonW]

> If they don't read, then they wouldn't be using Firefox, since all web pages (barring a few exceptions) would be gibberish to them :)

Not can't read; don't read. See http://blog.codinghorror.com/teaching-users-to-read/, http://www.joelonsoftware.com/uibook/chapters/fog0000000062....

Users don't read material that's put in front of them. Modal dialogs get dismissed without reading, non-modal dialogs (Firefox's doorhangers, Chrome/IE's notification bars) get ignored completely or dismissed.

[derefr]

In this case, though, the resulting page without Javascript would probably be entirely empty. Maybe Firefox could detect that and throw up a full-page-error kind of thing (like e.g. an SSL cert-failure error page) rather than a dialog. "There's nothing here. We detect <script> tags on the page, so you probably need to [enable Javascript]. Don't do this if you don't trust the site, though—you disabled Javascript for a reason!"

Basically, a heuristic browser-chrome view in place of what used to be a site-author's <noscript> view.

[x0x0]

This comment makes me strongly believe you don't speak to end users.

You can't get them to read prompts at all, let alone text on a page.

[yellowapple]

My comment actually comes from lots of speaking to end users. I cut my teeth on help desk and desktop support roles; understanding end-user needs is baked pretty damn hard into my blood.

And from those discussions, and from my observations of those users, 99% of the problems discussed would be resolved if it was clear what options actually did. Users don't know or care what "Javascript" or "TLS" are, but you can bet your ass that if the relevant checkboxes had at least a basic explanation of why they should be checked (i.e. "Don't uncheck this box unless you know what you are doing; doing so will cause a lot of websites to break"), the vast majority of end-users will happily leave that box unchecked until they ask someone more knowledgable about it.

[dblohm7]

or somebody on a reddit thread tells them to do it.

[xg15]

That's what sensible defaults are for.

But in this case, we're dealing with users who somehow managed to disable JS, but are still surprised by the effects and don't read prompts.

I'm pretty sure such users exist, however instead of directly basing your UI descisions on this scenario, why not trying to investigate where such behavior comes from and how frequent it is?

[derefr]

Imagine a user whose internet isn't working. They go into their web browser's Preferences and start fiddling with things at random "until it works again" (for entirely unrelated reasons.) Then they leave things however they just made them.

[cwyers]

Documentation only makes software easier to use if it is read. People don't read it.

[yellowapple]

By "documentation" I mean actually making the checkboxes better explained in their visible descriptions, or accompanying those descriptions with "a lot of websites rely on this box being checked" or somesuch. By no means am I calling for more things to be buried away in never-read manuals.

[pgeorgi]

And you think people read those descriptions when they follow the latest tutorial (in the syle of http://www.tech-recipes.com/rx/2710/firefox_disable_the_down...) to make their firefox 25000% faster?

[cwyers]

Won't read it:

http://www.joelonsoftware.com/uibook/chapters/fog0000000062....