I’m heading down to San Diego / La Jolla for the day to install some load balancers for WordPress.com and also to buy “Mr Fancy CTO” Jason a celebratory taco for their Joyent thing. If you’re in the area drop me a note. Update: La Jolla is beautiful, but servers happen. Trying to do things over a serial console is so 1988. (As Jason said.)
Web 2.0 bingo, play it on your next conference call.
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.)
Auto-imported from old gallery:
A funny comic about WordPress 2.0 in Spanish. 2.0 means “all new bugs”! 😉
Auto-imported from old gallery:
Bjorn wrote in that the Minneapolis Star Tribune has a couple of cool WordPress blogs including Old News which digs back into their archives.
Just landed in Houston, it’s chilly here. The opening up of WordPress.com got a nice write-up in Red Herring earlier today. Just to clarify two things from the article quickly: I’m working on WP.com with Andy, Donncha, and Ryan and I do think our distributed database architecture (which I’ll write more about later, it’s nothing too fancy) will help us scale cheaply but I’m also a strong believer in big things from small teams, much in the spirit of 37signals.
Just a tip for people traveling this week: get there early! I got there when I normally would (45-60 minutes before) and didn’t make it, thanks mostly to standing in the wrong line twice. Airports are in need of a usability designer far more than any software I’ve used in the past year. I generally fly a few times a month, so I’m not exactly a novice, but this is the first time I’ve been in the middle of the Thanksgiving rush.
I’ve seen a lot of people suggest with Google Base they’re competing with Craig’s List and eBay, but I see it much more as a play against Wikipedia. When I chatted with Jimmy Wales he said one of their biggest problems was for things that are relatively structured like the wiki dictionary or quotes having hte data in a totally unstructured wiki format makes it hard to work with. He suggested they would go the direction of mediawiki templates and microformats, which is great to hear. Google has come at it from the other direction, giving you a free-form DB to pour your heart into. I guess the question is, will people become as passionate about distribution (what Google promises) rather than working for the greater good of humanity through the Wikipedia.
We’ve decided to open up WordPress.com for signups without invites for a bit. The service has been scaling very well since we got the problems from the move worked out. With that done and WordPress 2.0 in its final stages, there is a lot more time to focus on some cool features and common requests for WP.com now. (The design there has been updated, but is still just a placeholder.)
Game-like elicitation methods: A new approach to user research. I like the sound of this and it looks like Mindcanvas is using WordPress to power their entire site.
Filezilla is a great little free and open source FTP for Windows. Not-terrible UI and SFTP are all I really need.
Two things I’m going to blog publicly to get myself to finish them faster: First off, I really need to finish up the Automattic site so you guys can see some of the cool stuff we’re doing there. Second, I’ve been playing with some cool gadgets lately and developing some pretty strong opinions about them which I’d like to start posting and sharing.
I only made it to the IP4IT conference on Tuesday and flew back that night but it was actually quite well-done so next time I’m going to try and make more of it. My panel in particular was great fun, with Jimmy Wales (who blogged it! I can die happy now.), Peter Saint-Andre, and Christopher Dean. The conversation at lunch was just as interesting, straying toward identity systems and dealing with web spam. The Wikipedia has fairly sophisticated ways to deal with spam, it sounded like there could be some interesting ways to work with Akismet as well. On the trade show floor I met some guys from Coyote Point Systems, which has a terrible website but their products sound very interesting and are a third to a quarter the price of similar offerings from F5 or Alteon. Anyone have experience with them?