There has been some recent requests on the WordPress hackers mailing list to change the syntax of certain functions in the desire to make it easier for people to change things on their blog if they want to. This is a really tricky subject and I’ve got some thoughts from my experiences that I wanted to put into the discussion. These are my opinions and should not be misconstrued as an official WordPress position.
The Request
Editing PHP tags is too hard for less technical users, we should try to simplify the stuff they need to edit so it isn’t as hard for them. Certainly, no one will argue that making things easier for users is a bad idea, but it isn’t quite as clear cut as it sounds.
Two types of users
WordPress has users with a wide range of technical and programming skill, however for the purposes of designing the software, they can be broken up into two simple buckets:
- Those who are willing to edit code (hackers).
- Those who are not willing to edit code (users).
What they want
The hackers want nice clean code that is readable and easily modified through options that are passed to the PHP functions. The users want be able to make their blog work like they want it to by going into the Options screens and making adjustments in the provided interface.
Cutting both ways
Unfortunately, these two are somewhat at odds with each other. To make the blog behavior change when a setting is adjusted the Options, there must be code added to act on those options. This is often frustrating to hackers who then have to work around large pieces of existing code that they don’t want to use.
Platform vs. Application and Features/Configurability vs. Bloat
Hackers are generally more interested in a platform. They want to use the pieces to create their own vision of a blog. On the flip side, users will often say they aren’t programmers and don’t want to be programmers, they just want a blog that works for them – with an idea of specifically how they want it to work. Both perspectives are completely valid.
When abstraction is just more code
The proposed changes on the mailing list generally focus on syntax changes and adding layers of abstraction with the stated goal of making things easier for the user. Unfortunately, this is normally an exercise in futility. Users don’t want to touch code, period; and hackers (remember, defined as anyone willing to touch code) will use whatever syntax is required by following examples.
Abstraction has additional problems as well. Whenever more code is added in the software, it adds to the mass of code that needs to be tested and maintained. It makes it harder to add new features to the software because there are more moving parts that all need to interact with each other.
There are certainly times when syntax can be improved, but WordPress has few serious problems in this area and also has to consider backward compatibility for upgrades.
Software has limitations, so do people
All software has strengths and limitations. It’s important to understand them and choose the right software for you. I would say that WordPress, in it’s current release, is at the same time a wonderful tool for hackers and a good option for some users, but a poor option for other users. Here I’m breaking the group of users up into two additional camps:
- Those whose main goal is to put their content out on the web (publishers)
- Those who care just as much or more about the presentation of that content and the way their visitors interact with it (webmasters)
Webmasters who are not hackers will not be entirely happy with WordPress at this time because it isn’t (yet) designed for them. There is no way to automatically download new themes or choose a new theme in the Options, no way to switch to a 3 column layout or make comments open in pop-up windows in the Options, no way to use different layouts for different categories or for single post vs. multiple post pages in the Options, etc.1
Solutions
These are not impossible problems. Smart programmers temper the potential problems by creating modular code and avoiding as many potential problem areas as possible. In effect, a platform (used by hackers) is built and an application (used by users and webmasters) is built on top of the platform. As the number of must-have new features is reduced, more time is devoted to the polish of existing features and exposing them through options for webmasters. A future WordPress may well have two entirely different versions of the index.php file, one with everything built in to respond to settings in the Options, and one as a bare bones skeleton to be filled in and used in component form by hackers.2
1While it’s not quite there yet, the Plugins interface is already moving towards what the webmasters would want.
2In fact, this kind of split has been part of WordPress since it’s evolution from b2. Take a look at index.php and wp.php (formerly b2.php).