> Shouldn’t you be able to restrict how much disk space is being used? It turns out, we know that you are low on disk space, and will reduce our usage accordingly. It’s pretty likely that Firefox keeps better track of this than humans do.
No. Here's a case where Firefox will definitely not do a better job: an NFS-based computer lab environment where users have individual quotas - the statfs() syscall (i.e. what the `df` command uses) returns you the amount of disk space available to everyone, which is enormous. Firefox then attempts to use that space, and quickly exhausts the user's quota. This is a real-life scenario and the current solution among users is to set the cache size to 0 - the Internet connection is damn fast anyways and they'd rather use their space to store actual files.
For the love of god, what is wrong with having an Advanced options panel? The author's stated goal is "to design software that can be used by everyone " but when you remove options like this, you make your product not usable by some people unless they do additional research to find the hidden about:config option or install some add-on.
The bug for this is https://bugzilla.mozilla.org/show_bug.cgi?id=851698 - if you think this is a bad idea I encourage you to leave a comment there (but be nice). Mozilla may otherwise not realize that this is such a bad, unpopular idea.
I think you're dragging the article to a conclusion it didn't try to make. For the love of god, he didn't say that software can't have "Advanced" options panels. He pointed out a series of specific options that were either ill-advised, overly accessible, or so unusable as to be hardly better than a properties file.
Firefox really does have an easily-reached config panel with "Use SSL 3.0" and "Use TLS 1.0" on it. What is the situation in which any user at your lab would know which of those options is sensible? Neither of them are the current version of TLS. Both of them have cryptographic flaws. And both are extremely widespread.
Firefox really does have a top-level config panel with a checkbox that disables automatic image loading. It's not even an "advanced" option.
I don't think your comment really engages with the article. What should the top-level options for a browser be?
Several of the options (cache, TLS, certificate manager) he cited are already in the advanced panel and he wants to kill them.
And in several places he explicitly says that these killed options (whether they're currently in the advanced panel or not) should be replaced by add-ons, not by an advanced option or even by about:config.
So I don't think I dragged the article to a conclusion it didn't try to make. The article is clearly about killing options which I contend people need, and I think should be placed in an advanced section rather than killed.
But he does want to kill plenty of these options. Thats why he constantly remarks about Addons, as if a Firefox addon should be able to globally disable JavaScript. It's the fault of this article: he constantly implicates that because something is an overly niche option, it should be done away with completely, instead of just removing it from the UI.
The certificate management interfaces of every mainstream browser are so bad that they actually harm Internet security. They all need to be replaced. Add-on cert management interfaces sound peachy to me.
The point here being that you should not delegate cert management to an addon. Addons have no business being exposed to any of that, they need to be sandboxed in and restricted.
And yes, they are so bad to the point they are harmful, but the only reason they are in there is because Firefox has it's own certificate store, more of a portability quirk than anything.
Okay, but he didn't comment on the possibility of putting it in a hidden preference screen available by URL only. He hasn't explicitly commented on the middle ground between preference screens available from the menu and add-ons, so it's not fair to say that he's claiming it should be done away with completely.
His point was, and I agree with it, that a mass browser does not need to expose cert management in a way that the 99.9% can access it because it's likely to cause more harm than good for anyone who is not capable of jumping through a few extra hoops to get to it.
I'm sorry, but the answer isn't to remove options that often make sense. You don't want to be like the Gnome guys, who in the guise of making things "user friendly" removed often extremely useful functionality.
Like removing the certificates manager. Or cache control. Or the ability to restrict cookies. Or JavaScript. Or the ability to turn off menubars, should you so desire to do so (kiosk mode). All of these things are used by people. Just because he doesn't like it, doesn't mean others don't want it.
File a bug in Bugzilla in the Evangelism component asking Mozilla to chat with the VMWare folks, and file another bug against the browser requesting a fix for whatever autodetection prevents it from falling back to some other protocol.
I think people get nervous about talk like this because the "make everything muppet-proof" movement has gotten so much traction in the wake of Android and iOS.
UI designers are empowered, and "power" technical and business users suffer for it. My iPad is easy for my two-year old to use... But it is horrific for more many types of tasks that computer users do every day.
Firefox definitely carries a lot of config legacy... But going too far the other way is dangerous too.
The setting is vitally important for an extremely small number of people.
That sounds to me like it should be moved into an add-on. The users affected still can get the capability while the rest of the world is spared another setting that clutters the UI.
What's wrong with clutter in an advanced tab? The only clutter exposed to the "rest of the world" is a tab that says "advanced" which is not really clutter at all.
If you remove options from your product that are vitally important to even a small number of users your product can no longer "be used by anyone."
The problem here isn't that the unusual options exist in a hidden away tab. The problem is that the options to revert to the defaults are in the same hidden away tab.
Users with images turned off by someone else wouldn't be confused if there was a yellow stripe across the top of the screen with a "you're viewing this website with images turned off [turn images on]" type message. Same goes for a "this page may display better with javascript enabled. [turn javascript on] if you trust this site" message for those browsing with javascript turned off.
Similarly, as the original post points out, the big issue with SSL is that you get a scary (and inaccurate and incomplete) message telling them to email the website owners because their site is broken, and not a simple message they'll need to "click here to turn SSL secure access back on" to view the web page.
But for a user that legitimately wants to turn off images or javascript (why?), they won't want to see that message on every page. If the message only shows once then the problem the message was trying to avoid returns. If the message shows on every page legitimate users of the option are inconvenienced. Of course you could create yet another setting saying "Warn when I have obscure settings enabled"...
If the developers/designers of Firefox don't have a reasonably answer as to why a large enough amount of users would disable these settings, then they should be removed (or to avoid upsetting existing power user moved to about:config).
One problem is that browser vendors don't do a good job of sorting features into "Advanced" tabs and "important" options, so that some options that would be valuable to lots of people are buried alongside options that are valuable mostly to lab admins.
If I recall, there are some Chrome options that you can't modify from Chrome itself, but which you can configure using Group Policy Objects. That (or whatever the equivalent is on *nix--files in /etc?) should be where the settings for "lab admins" go.
Isn't the logical conclusion of this kind of reasoning that everyone should become a programmer and browsers should be supplied in source form only, so everyone can customise any tiny detail they want to? That's not exactly a realistic prospect for most non-geeks.
User interface development for mainstream software is invariably a balance between presenting something accessible to novice/occasional users and presenting something powerful to expert/frequent users. You can go a long way to helping both groups with a thoughtful design, but there's always going to be someone who wants something slightly (or completely) different.
For mainstream software, trying to please everyone all the time is a fool's game. That's what bespoke development is for.
But where do you draw the line? What constitutes an "advanced option" worthy of dedicated UI rather than a customised build? What proportion or minimum number of users have to find it valuable for the effort and lost simplicity to be justified? When there are too many advanced options to manage sensibly, do we move to "advanced", "really advanced" and "actually quite scary you even thought of this" options?
Love to know how numbers of users affected is measured. One of the arguments is that with a large enough number of users (millions) an option can cause significant numbers of people grief if they misuse it.
Same argument can be said for removing a feature 2% of the population of users rely on. 2% of 450 million users is 9 million users. Not what I'd call a tiny number of users.
I'll claim it's more likely users affected will not see any way to prevent it, not find the add-on, write off Firefox as bloated, and use something else.
The geekier side of the affected users may find the add-on, sure. But they're not the only ones affected.
Small number of people overall does not take into account where those users are concentrated. A lot of the options he uses as examples are extremely useful in third world countries where Firefox actually dominates the competition precisely because of how easy it is to configure it to be a low bandwidth browser. Africa probably being the best example of where Firefox dominates. So while it may be 2% overall, it could be something huge like 50% of the userbase in specific demographics/regions.
In UIs, it imposes cognitive load for little or no benefit.
I'm immensely grateful that I did some tech support in college. It taught me how much seemingly trivial, ignorable UI clutter caused real problems for people who aren't programmers. That is, the vast bulk of the population. Cognitive loads that are small for me can be giant for others. Letting me design a UI based on my own preferences is like letting NBA basketball players decide how to organize my kitchen cupboards.
about:config is a great place for this kind of tweak. In fact, most of these check boxes the author talked about would fit in right at home in about:config.
Even more so if about:config included a one-liner explaining what the option is for. Sprinkle search/hierarchization on top of the about:config and suddenly the rule can be "if 99% of the users don't need the option, it goes into about:config only".
The about:config window has a giant search box right at the top of it. It's not hierarchical, but its sorted alphabetically, so, for instance, all accessibility.* options are grouped together.
about:config is horrible because it's not hierarchically organized. A big fat list of items is much more difficult to use than multiple tabs or pages of related options with widgets appropriate to their data types. "Advanced" shouldn't automatically mean "difficult by design."
But how many people just browse the about:config window looking for settings to change? I go in there looking for a specific setting because I've searched google first, and found a website that explains what setting I need to change. Use the search bar and it filters the list for you.
You shouldn't have to search Google first. If you know what you want to do, the setting to do it should be discoverable through a well-crafted hierarchy of settings. Searchable configuration lists are a symptom of the UI designer outsourcing his or her job to the end user.
You're right. In a well designed program, the user should have to search Google. Like user sergiosgc said, a well-written one line explanation plus better organization would go far in improving the about:config screen.
And you're right that just because something is deep in advanced settings doesn't mean that the design has to be shit. But in this case, and in other browsers, 99.99% of users don't even know it exists, so Mozilla likely feels justified in leaving it as is.
The reason I get worked up about discoverability in user interfaces is because that is how I learned nearly everything I know about computers up until I was in highschool. I was lightyears ahead of my parents, relatives, and most adults I came into contact with ever since I bought my parents' old IBM PC-XT for $75 when I was around eight years old. The only way I could keep learning was by exploring and discovering (and library books).
No, don't solicit spam for the bug that wants to remove the options; instead, go file a bug saying that Firefox should check the user's quota in addition to statfs. Easily added, and then Firefox becomes that much more automatic.
> No, don't solicit spam for the bug that wants to remove the options
It's not spam to discuss the merits of implementing a feature request.
> instead, go file a bug saying that Firefox should check the user's quota in addition to statfs. Easily added, and then Firefox becomes that much more automatic.
Not possible - the quota information is not made available in any standard way, but rather by a non-standard dot file in the user's home directory. I know the quota information should be exported by rquotad but things aren't always that neat in the real world.
Even if it were possible users may still prefer not to sacrifice any of their quota-limited home directory to Firefox cache. Who's Mozilla to presume they know what users want?
> It's not spam to discuss the merits of implementing a feature request.
First of all, note that the tracking bug you linked to doesn't even track or discuss any bug about removing the cache options, making it pointless to bring up there.
It wouldn't be spam for you file a bug requesting a fix for quota handling. It also wouldn't be spam for you to post a note to the bug about removing the cache options to point at the quota bug, and to make sure it'll stick around as an about:config option. However, canvassing for other people to go post to a bugzilla tracking bug just leads to noise like the current pile of comments in bug 851698; the vast majority of the comments in that bug, especially the ones by users labeled "(New to Bugzilla)", do indeed constitute spam, and those same comments show up in just about every bug trying to clean up the UI.
> Not possible - the quota information is not made available in any standard way, but rather by a non-standard dot file in the user's home directory. I know the quota information should be exported by rquotad but things aren't always that neat in the real world.
So, we've started from "bug only seen by people running Firefox over NFS", already a very small fraction of users, and then shrunk the audience further to people who don't even use the standard quota mechanisms. An option to serve that vanishingly small fraction of users seems like precisely the domain of about:config.
> Even if it were possible users may still prefer not to sacrifice any of their quota-limited home directory to Firefox cache.
And those users can go tweak the setting in about:config, or you could tweak it for them by changing the system-wide default. That doesn't make it appropriate to put in the main configuration UI; not enough people use it, and its very existence in the UI hurts more people than it helps.
> Who's Mozilla to presume they know what users want?
Makers of a browser used by hundreds of millions of users, with extensive data from actual user testing, tons of statistical data telling them which settings and UI options people actually touch, and most importantly an understanding that just because an option has users doesn't mean it should continue to exist, and that the noisiest people on Bugzilla frequently don't represent a significant fraction of users.
about:config exists to satisfy use cases like yours. Tone down the rhetoric and understand that when your software has hundreds of millions of users, every single change represents a tradeoff between who it might help and who it might hurt. This one seems far easier than most.
They're not the same, really. The advanced preferences tab is an easily-accessible pane in the preferences GUI, right next to things like setting-the-homepage, syncing-your-bookmarks, and other features that are broadly useful. about:config is a page that almost no one knows about, except people who really know what they're doing.
Edit: and the about:config page shows a giant warning that "This might void your warranty" before allowing you to proceed. It's pretty different from a generic "Advanced" tab in a preferences window.
> Who's Mozilla to presume they know what users want?
The developer and designers of the product.
They might not always be right, but they need to be able to make decisions for users in order to move forward. Apps need a champion to lead them and guide them, and sometimes even to upset some users to improve the product for other users.
> For the love of god, what is wrong with having an Advanced options panel?
The OP seems to think about the average user and decides that a lot of stuff is not needed in Firefox options. But the average user does NOT click on Advances Options in any case. To be fare, the average user do not click on Preferences at all.
Is not bad idea to have some of this options as plugins, though. But we must remember that if the "average user" clicks on "Full screen" button (or even worse, F11), he/she'll probably have to reboot the computer in order to "fix" de computer.
The "average user" is also not a real user. There aren't actual average users - they're a conceptual aggregate of a broad-range of users who may use entirely different sets of features, which share only a few common overlaps.
You can not damage the "average user" at all, but manage to break the workflow of most of your real users but eliminating parts of the set of features they depend on.
i.e. remove 100 different features only used by 1% of your users, and it's actually quite likely you've removed features 100% of your users use.
However the workflow issues you break are sometimes something like this: http://xkcd.com/1172/ -- that may be a problem with software you paid $1 for 3 years ago and expected forever to work exactly as you need it.
How did you mentally go from "expected forever to work exactly as you need it." to "Why shouldn't one expect to have one's purchased goods remain available indefinitely"?
There's a huge difference between being available and not ever changing. You're arguing against a point never made.
> i.e. remove 100 different features only used by 1% of your users, and it's actually quite likely you've removed features 100% of your users use.
Perhaps true, but your estimates are off by many orders of magnitude. Wikipedia puts the Firefox userbase at 450 million. How many people do you think need to turn off SSL? Hundreds? Thousands? That's about 0.0002%. How many need to turn off or manually tweak the size of disk cache? Over 9000? That's still only 0.002%. And oddly enough, it'll overlap heavily with the last 0.002%, and the next 0.002%.
People really disliked being treated as numbers, they'd rather be treated as human beings.
It gives the impression that it's about finding a justification to an arbitrary already made decision.
IMHO a more sensible way to tackle the issue is to make usage cases and find a way to address what ever arise from this scenario wisely.
From the nfs case exposed earlier, a "I'm on nfs with quota" checkbox would make more sense than forcing cache manually to 0.
Instead of removing features and hiding options, wouldn't it be preferable to provide options that make sense and make them usable ?
Right, the developers and the early adopters deserve deference; I'm saying that it's easy for an early adopter to believe that the other 450mil users do not. After all, they're using it anyway despite it being friendly to the early adopters.
If a product manages to be better than all the alternatives, it's hard to argue it's not a good product. At the very least it had to be better than "whatever everyone was using before" and "not using anything."
For the first few years, there were lots of sites that were designed for IE that broke in Firefox. Thus, at first, it was actually worse for many people. Yet, because the early adopters kept pushing it on everyone of their malware-ridden friends and relatives, it grew in usage anyway, allowing Mozilla to afford to make it better.
I was one of those folks who contributed to the Firefox announcement ads, but I don't really believe that it succeeded because folks pushed it rather than it simply being a better product. Yes, some sites at the time worked better in IE, but on the whole, the experience on Firefox was better and that's why folks supported it, not because they disliked Microsoft or something. (And yes, because we support proper web standards.)
Firefox was a spinoff of Mozilla and was a pretty good browser from v1, and within a year of release was considered the best browser available.
The problem here is the lack of communication. How hard is it to show a brief popup telling the user what is happening and how to reverse it? At lot of applications with a fullscreen mode already do this. For example, Parallels and VMWare Workstation do it[1]. Options that can be confusing or dangerous should come with warnings instead of just taking them away.
[1]I think there is a way to stop showing the message, though.
They don't need to remove the ability to override - they just need to remove it from the preference panel. As long as it is still available as a configuration change though an about:config screen or equivalent - admins in specialized environments can set it appropriately. In fact - they are more likely to set it through a registry setting or a domain policy and would never go to the preference panel at all.
I made an account to try and leave a comment but seems like I don't have permission to do so. If you can, I'd be grateful if you left this comment for me:
> Before moving forward with this suggestion, please do a usage analysis for each of these options (or any future suggested options) based on regions in the world. Several of these options (images - which doesn't break Google for me, javascript, cache) are all things that appear on the surface to be very useful in third world countries where bandwidth & hardware is very limited. The ease of finding and configuring these options might be precisely why Firefox has a healthy lead over competing browser in Africa. So while the overall percent of users is 2%, this number possibly shoots up to a majority of the user base when looking at specific regions or demographics.
Specifically, image & javascript would help with bandwidth. Cache override/disable would be useful on devices like the Raspberry Pi that run off of flash media (or for use cases like running Firefox off a flash drive ala PortableApps); the type of hardware I would expect to be more widely used in 3rd world countries.
Also, because no one uses SSDs and those definitely don't have a limited number of writes. That said, they could make it smarter ("We see that you're using an SSD but you have some free space on this other disk. Should we use that for cache instead? Click here to read more about SSD write cycles...") or just cache in RAM only.
Even with a page file on an SSD I haven't had a problem over years of operation. Granted, this is anecdotal, but wear levelling wouldn't exist if it made no discernable difference. Windows disables defragmenting on SSDs, but from what I gathered that's not so much because of write cycles but rather because it makes no performance difference and thus is time unnecessarily spent.
That being said, making the algorithms smarter should probably help, e.g. only caching in memory if there is an SSD and just store frequently-used sites' resources on disk which might be a viable compromise.
This was a problem at my university too, not a massive one though. Certainly an add-on could fix it rather than an option (really what would be ideal would be better group policy-style management of FireFox across workstations).
In this instance I have to wonder if FireFox couldn't look for a quota - it can be detected.
No. Here's a case where Firefox will definitely not do a better job: an NFS-based computer lab environment where users have individual quotas - the statfs() syscall (i.e. what the `df` command uses) returns you the amount of disk space available to everyone, which is enormous. Firefox then attempts to use that space, and quickly exhausts the user's quota. This is a real-life scenario and the current solution among users is to set the cache size to 0 - the Internet connection is damn fast anyways and they'd rather use their space to store actual files.
For the love of god, what is wrong with having an Advanced options panel? The author's stated goal is "to design software that can be used by everyone " but when you remove options like this, you make your product not usable by some people unless they do additional research to find the hidden about:config option or install some add-on.
The bug for this is https://bugzilla.mozilla.org/show_bug.cgi?id=851698 - if you think this is a bad idea I encourage you to leave a comment there (but be nice). Mozilla may otherwise not realize that this is such a bad, unpopular idea.