Alex King has recently suggested that we have an about:config for WordPress. When I first thought this I thought “great!” because we’ve had this for several versions now: if you browse to options.php directly you can edit any option in the database, even those that have no UI because they’re from plugins or just something we don’t expose.
However after several comments pointed this out Alex began clarifying his request, some of it isn’t entirely clear to me (I would never want to go back to storing configuration in files, that was a nightmare we eliminated in 1.0), but the main gist is not merely exposing an interface to the options we have, but rather adding many more options to the code to allow for more than one way for some core parts of WordPress to work.
With that clarification, I think it’s pretty safe to say that something like that will probably never be incorporated.
Options have several costs, which is why we avoid them fairly religiously in WordPress. The most obvious cost is UI clutter — everyone wants their 15 pixels of fame and configuration screens quickly devolve into pages of utterly confusing junk no one understands or cares about.
A very closely related problem is user frustration. With WordPress we’re trying to make publishing to the web as effortless as humanly possible, and one part of this is taking care of a thousand little details that really shouldn’t ever cross your mind — if we’re doing our job right. One common reason for the proliferation of options in open source software is that (news flash) people often disagree about how things should be done, often violently and vocally in threads that can drag on for weeks on development mailing lists. (It is frustrating for many people that these option flame wars draw more discussion than useful topics or questions.) Few like fighting about things, and project leaders pull the proverbial car to the side of the road and declare “Screw it! We’ll do both!” To satisfy a handful of developers a burden is put on countless users.
I try to build everything imagining I have a million users. (Someday!) Small things add up — if there is an option in the interface that people have to think about for only 2 seconds (which is probably low) across a million users that’s 23 days (555 hours) of time lost to the world! (Call centers track efficiency per second because of similar constraints. Small things add up.)
Alex’s hidden options don’t trigger either of these by definition. However there is a third hidden cost: as the number of options increases it becomes difficult (or even impossible) to test for all possible combinations of how the options may interact in different enviroments. This also makes support a real bear. Costs go up, bugs increase.
This is why we say no by default to pretty much every suggested option, and we do our best to remove the ones that have built up over the years. (I just axed a whole panel earlier tonight.)
All that said, hard-core developers often need flexibility in the system to expand WordPress to things we’ve never even imagined, and that’s where our plugin system comes in. While we often say no to new options, we rarely ever shoot down a suggested extension to our plugin API. The beauty of this is it allows for near-infinite flexibility in how you interact with the program (there are some amazing plugins out there) while still keeping the core light, clean, stable, and fast. It also makes support relatively painless: “Does it work when you deactivate the plugin?” When someone says they want to do X and it should be core because it can’t be a plugin, 9 times out of 10 I see that as a plugin API bug, not a core bug.
In summation: Don’t waste your users’ time like I just wasted yours with this essay and be mindful of hidden costs. If I had a few extra hours I would edit and cut most of it out. (Good thing I don’t have a million readers.)
Hey Matt, that’s a damn good post, and timely to for us — we were hashing out the details of blogging firefox extension last night and were discussing just how to make it as customizable and extensible as possible without confusing users!
Thanks, and i like the tip about options.php – never knew that and am about to do a WP install 🙂
“Costs go up” True – send me coffee 🙂
How if you make an advanced button within the Options tab? That way, it won’t confuse average users but will ease the work of a seasoned blogger.
Oskar: That still doesn’t solve the problem of debugging different combinations of options/configurations. I’m with Matt on this… keep the core as lean as possible; expose as much as possible to the extension API.
Oskar,
By putting an advance tab, i afraid you will start seeing some average users playing with it (even though you can put heading like “DONT MESS WITH THE CONFIG IN THE ADVANCE MENU!” thus posts like ‘ i enter this in my advance option panel but…..’ will start popping up in the support forum and bug tracking list in no time.
The idea here is not to limit the choices/options wordpress users can have, but to move that freedom/flexibility of WP from the core to plugin sections.
That way, WP can stay clean and light while at the same time flexible enough for hardcore dev to play with it.
Nice post, definitely agree with your philosophy of keep it as lean and simple as possible.
I totally agree with clearing away the clutter and simplifying the interface. But at the same time, it would really be nice to be able to change certain options that are accessible only through the DB. Maybe an about:config would be a good idea if it came with the caveat: “tinker at your own risk.”
Bravo, Matt! Take it from a NON-developer (but big WordPress fan), I don’t need “15 pixels of fame”, and the further you keep me from playing with options that I neither need nor understand the better. Plugin architecture is great.
How about making the minutiae part of an optional ‘extended’ interface – so we don’t clutter the interface for those who just want to blog (although they would probably use wordpress.com rather than hosting WordPress themselves) but those who want more configuration without going database diving can get it.
Ara and David, re-read the part about the cost of hidden options.
I disagree with some of the points.
The first is about UI clutter. The about:config page in gecko browsers (Firefox, Mozilla, and recent versions of netscape) is not linked from the default UI. It also provides no help about the options; it mearly lists them and their values. If Alex’s idea was to follow that, then these additional options would not be presented in normal interfaces — they’d be a backend you hear about in IRC or similar.
Secondly, about the bit on testing, let me refer to a (theoretical) disclaimer: “Changing these options may bork your installation, cause nasty things to appear, open security holes, …. USE AT YOUR OWN RISK.” I sincerly doubt that Mozilla.org tests under every permutation of the available options.
If it’s possible to break your tool using only the options you give to your users, I would say that’s broken.
That’s a hell of a post. Those are some minutes of my life I won’t get back. Technically, nobody can stop a plugin developer to do UI things the way he wants to. You can only persuede (sp?) someone, but there is a limit some developers will go to. Cross that limit for every plugin developer, and I’ll be impressed. Otherwise, good luck.
Bravo, Matt. Posts like this remind me why this blog is on my Bloglines account.
S.
Hmm… just throwing an idea out here: what if someone out there developed an about:config plugin? Would that even be possible?
I kindof like the about:config idea, but, being a developer myself, I can easily see where it would be a error-prone, time-consuming, project that most likely wouldn’t ever really get of the ground.
JBChris: well, the issue is not so much about exposing config options as making them in the first place. An about:config plugin would mainly just be a bunch of plugins with a bad ui on top of ’em. Might as well go à la carte and pick the plugins you want.
I see that most people in favor of having more options rely heavily on the “just add a disclaimer” argument. But the disclaimer won’t solve anything. While some people may pay attention to it and educate themselves before tinkering with the “extra options”, the problem remains that most people will just go ahead and tinker away. Your “just add a disclaimer” argument suggests that when these users mess something up, they’ll remember the disclaimer and think “oh, well… I messed up… that was my bad… I’ll just reinstall everything… or solve it on my own”. But they won’t. They’ll go straight to the support forums and bug trackers. They’ll try as hard as they can to get someone to help them out to get their software to work with the changes they made to the software in the “extra options.” Then the support forums and bug trackers get flooded with problems, each of which may arise from an (almost) infinite number of “extra option” combinations. And then people start whining that the support system is inefficient. And then people resent the developers for not being able to provide adequate support for a set of “extra options” that they made available in the first place.
I understand what Matt is trying to say here. He’s isolating most problems to just one area of the software. To make his and the other WP developers’ lives a bit less chaotic, to give better support so that you don’t have to wait and wait and wait for very complicated “extra options”-related problems to finally be sorted out (if ever).
Kudos to Matt for keeping it simple.
What might work would be a grand ‘reset’ button, or even better a toggle button allowing these options to be turned on and off en masse. This would make troubleshooting ‘hidden option’ problems as painless as turning off a plugin. The disclaimer would be near useless. Disclaimers have been used until we are numb to them, and they were never effective on the people who need them most. Use a “Not supported by anyone, turn back now’ sign instead.
Another musing; might this sort of thing be handled by an overblown plugin? Sort of a TweakWP sort of thingy? If it had an official blessing, a wiki of its’ own to absorb the curious and lost, and some informal hooks into the code to let it work it’s magic, the toggle button could be a vanilla plugin disabling. Support gets easy again, and people only spend their brainpower if they have it to spare…
The KISS principle is one of the reasons why I like WordPress – I can be up and running in a matter of minutes. At the same time, WordPress is exceptionally flexible. I think that the UNIX philosophy works best for making quality software – don’t have one monolithic tool, but a whole bunch of small, simple ones that can integrate together in a host of different ways.
For instance, a family friend of mine is an 85 year-old retired priest who uses WordPress on his blog. For what he does, WordPress is simple enough that he has no problem creating an updating entries. The “grandma test” is a good way of knowing if you’ve made your software simple enough – if grandma can use it, then you’ve made it simple and intuitive. Plus, if you’ve made it flexible enough, you can extend that framework to do things it never was meant to do.
Adding an ‘about:config’ screen may not be such a bad idea, but on the other hand, if someone really wants to alter the deep-level functions of the program, chances are there’s a plugin to do so and the system is totally open to such changes. It’s the fact that WordPress is so completely open that makes it so powerful – but at the same time, the core functionality should be as simple as possible.
FWIW, I don’t think Alex has such a bad idea. Firefox really just parses the prefs file to generate the about:config. Exposing all known configs.
As long as there are defaults, and they aren’t in the regular UI… a pref doesn’t really hurt anyone. In fact, most people don’t notice them. If you want to get really technical, any variable in the code is a pref. You just don’t let the user edit it.
about:config definately serves power users well. There are things in there that people like to tweek. Some for fun, some for work (developer options are very helpful). I can’t imagine firefox without it.
I’m personally for the feature. The only UI bloat it adds is 1 button or link in the prefs to the advanced config (if even that, you could leave it so you have to navigate to the url yourself).
I personally consider the bloat factor to be a non issue. The question is should users have access to so much of the internals with such ease. IMHO yes, but with clear warnings, and provided there’s a good example of a postive change that could be made by adjusting that value. Setting create_security_vulnerability to true, is bogus. Setting a timeout, or some other obscure config, may be very helpful in some places.
I’d say the rule is to have a set of rules for what becomes a config. Must meet certain criteria:
– Danger limit (somewhat objective)
– Has a minimum of 1 reason why the user may want to change the value.
– Should not be able to create security issues regardless of setting (very rare exceptions allowed).
And have a giant warning at the top of the page.
Another option to reset to defaults would also be wise.
I thought this would be interesting to relate, lead dev on firefox (Ben Goodger) criticises the use of about:config for pet geeky features (says it adds code bloat and testing overhead).
Pretty nice site, wants to see much more on it! 🙂
[url=http://sas.juztalk.com/anche-pour-saxophone.html] anche pour saxophone[/url]