Note: Content might be outdated!
Tom McFarlin has published a piece I found more than worth reading today: We’re Ignoring the WordPress Philosophy: Decisions, Not Options. Instead of spamming Tom’s comment section with a double-digit number of paragraphs, I thought I’d share my thoughts on the topic in a quick post myself.
“Decisions, wtf?”
So where does “Decisions, not options” even come from? Quick context:
The line “Decisions, not options” is part of the WordPress Philosophy, and thereby part of what people who make WordPress presumably have in mind when they are working on making WordPress better. Whether it makes sense to you or not, it might be worth reading and spending a bit of thinking on.
What does it actually say? As Tom excellently puts it (regarding themes here, but his article applies to plugins as well):
It means that we consider the average user, what they hope to achieve using the particular theme they’ve purchased, and we make decisions that help solve those problems without the user needing the interfere.
Tom McFarlin
“Where’s the .exe??”
My friend Robert has told me lately, a couple of years ago that question “Where’s the .exe?”—asked via e-mail by a person he didn’t know—was the moment he realized WordPress had gotten really big.
Because from that question on it hasn’t been about the fine club of tech-savvy users and developers anymore who are so used to edit code all the time and OOP the heck out of you.
WordPress has reached the screens of (so to speak) “normal” computer users. Windows — need to install anything? Look for an .exe!
That’s where we’re at today. That’s the pair of moccasins we’ve got to put on if we’re going to walk with the average users and create products for them—themes or plugins or services, whatever niche, whatever market.
Make it simple, not stupid.
For my part, I am absolutely convinced there is no way to simplify a hammer, or a screwdriver. Those are basic tools. Yet people need help and teaching and guidance when they’re going to use those tools for the first time.
That’s why in my world, making a good WordPress product doesn’t end with making decisions instead of options. Yes, it is key to make decisions, and make them good. Yet there’s always going to be the teaching part.
Product support will not go anywhere just because we make better products. It is always going to be a requirement. But guess what?
Once we’ve made good decisions for our product to be exactly the tool our users need, once we’ve created a hammer and a screwdriver—not a screw-driving hammer with a big moustache and lametta on each ends!—our product support might become very easy.
So, instead of trying to get non-techie users to open files and rip apart what we had built for them:
Let’s all make more hammers!
Because we might end up showing people how to really nail what they need to achieve with the tools we’ve built for them.
P.S.: While you’re at it, why not go reading Tom’s other post on “Design for the Majority”? I sure will!
Having the “normal” user in mind might not be the worst thing. Probably it helps making things not so techie and still keeping it useful for pro users, too. You just need to decide if that’s the way you want to work. Or if this is the product your users want.
I think I’m getting your point, so let’s just say for the record that decision —whether a user wants a specific product— is up to the user.
Which leaves most of the users (in other markets we’d say: consumers) in a dilemma, because they are required to make decisions while they lack knowledge of principle for making those decisions. (“Principle” in this particular context i.e. meaning the knowledge of how to distinguish a well coded theme from a spaghetti-coded nightmare, and do so without having to become a developer.)
Teaching users good principles to make decisions for good products then again might be a responsibility of those who build products. Which imo we could fulfill —at least partly— building and praising simple to understand products.
Thanks for the Links. I have never found the WordPress Philosophy, yet. Very, very good read.
I think, that both of you, Tom McFarlin and you are right: I don’t read the Philosophy as a clean and strong Coding Guideline, but more as a guide. WordPress it self has lot’s of Options and I habe experienced both types of users: Those, who just need a login and never ask a question again and thos who need constant guidance.
The important thing about the WordPress Philosophy gets visibel, when comparing the State of WordPress to the State of Drupal: Speaking vom the WP-Philosophies point of View Drupal totally is the opposite of “Descicions, not Options”, and also the Opposite of other Parts of the Philosophy. It’s Options, not Descions. And although it made Drupal extremly powerfull, it has put Drupal in an extremely dangerous Situation, for both, Users and Developers.
You don’t have to follow the WP Philosophy in everything you do for WP strictly. I think, it’s totally enough to keep it in Mind, as a Mindset, and even stray away from it from time to time. But generally Value of the Ideas of the WordPress Philosophy can’t be overestimated. It protects the Core and the Community from unvisible Mistakes, like Drupal made it.
So … thanks again, for the Links!
Ah. And by the way: Many of the Philosophy, reminds me strongly of 37signals “Getting Real“, which might be a reason, why I like it so much. :]
Very good point! I believe we’re working towards a WordPress that can be tailored to specific use cases. WordPress’s extendability already has become a measurement for core development where new features are developed as plugins first. Reducing core to key features/APIs and making i.e. the choice of post types totally optional has been a feature dream that often comes up in discussions on WordPress’s core structure. (Should provide an example here, will search.)
O-oh.
Reducing the core to the max and making most of the other stuff optional/plugin looks like a good idea in the first place. That’s why everyone in the Drupal-Community was so enthusatic about it. But for Drupal it ended in a major fuckup. Just two examples to describe it:
1. A common Drupal-Setup has about 60 – 120 Modules (Plugins) up and running. A common Drupal-Prover is “There’s a Module for that”. If these things don’t frightend you in the first place, then you will soon realize that the Maintenance of a 60+ Module Setup is kind of Hell.
2. You can’t deploy Options professionally. The more options you have, the more problems you get, when working with the classical Dev-Stage-Prod-Setup. Drupal has developed a Solution for that, which is called “Features”, whichs allows you to export Options/Sitebuilding into PHP-Code, add that to your Repo an deploy it. But it’s a constant pain in the A**.
I especially value WordPress for it’s “oldschool” but clean separation of Plugins, Theme and Content.
Very interesting insights, thanks.