WordPress 3.3 is on the horizon, and already there’s a minor kerfluffle over the flyout menus. Regardless of if you agree with the change or not (I do, Otto does not, for example), it brings to mind the reality that every time there’s a new change to the Admin UI, someone demands to know ‘Who’ requested the change. One time, the answer was ‘Matt.’
While WP is open source, and that means it’s community driven, that’s only to a degree. Remember, at the end of the day the folks with commit access are the ones who decide what they want to support and have in their app. Theirs. WordPress isn’t a Democracy, it’s at best a parlimented monarchy, but really more of a benevolent dictatorship. This is neither good nor bad, when you put it in perspective, and I’m afraid that with products, especially free and/or open-source products, we as a user base consistently lack that perspective.
The company I work for recently switched to Office 2007. Yes, I want you all to take a moment to reflect on the fact that we didn’t move to Office 2007 until it was 2010 (and didn’t finish until summer 2011), it’s important. The reason we didn’t switch sooner wasn’t for anything technical. In fact, we really wanted to switch so we could upgrade SharePoint and have functional integration. No, there were no app conflicts or weird database issues preventing the upgrade. It ran on our operating systems without issues. But why didn’t we upgrade? Because some of the people in “very important positions” had trouble with it, and we were concerned that the UI change, which was rather dramatic, would overwhelm our help desk.
To put this in perspective even more, there are about 20k employees at my company (give or take, I’m not counting consultants here, or non-computer-using people). Of those, about an eighth are what I’d call techies. That is, maybe 2500 of us are really nerdy people who use foam swords or even know who Stallman is. Another 2500 of us are technically inclined, and capable of trouble shooting the basics. Another 2500 are smart enough to know how to explain their problem to the techs. That means over half the company are ‘real users,’ you know, the ones we make fun of for deleting DLLs that are taking up space, or who reboot their monitor. Every time we make a change to software used across the entire company, we have to put that 50% clear in our minds. How will this affect them? What training to we need to provide? We’ve pretty much accepted that no change will be universally accepted, and at a certain point we have to agree that this is ‘good enough’ for people, and deal with the fall out.
Coming back to Open Source, when a project like WordPress or Drupal makes a major change someone’s going to hate it. This is just the way of the world, and even if you love the change, you need to work to make sure your replies to these people aren’t ‘haters gonna hate!’ or ‘you suck!’ Neither of these are productive. Part of the problem here is that people get passionate and sulky, like a nine year old who viscerally dislikes something, but lacks the language to fully explain it. This is not to say people are incapable of explaining themselves, but that part of their problem is the ephemeral ‘feeling.’ The other major part of the problem is that no two people hold a hammer the exact same way. And of course that people who are complaining at the ‘beta’ stage of the product are in too late.
Understanding how these designs get made goes a long way into making people accept changes they don’t agree with. It doesn’t make them like the changes, but understanding how and why they happened can get you to the ‘agree to disagree’ point. John O’Nolan (who currently is living on the road by choice) wrote an amazingly informative post about how he got involved in WordPress UI back in the 3.0 days. He lays out how you can get involved more, if you’re inclined. There’s a great Make WordPress UI P2 blog, and of course WordPress Development blog that you can follow along to see what’s going on and there’s always looking at the tickets in Trac flagged for Needs User Experience/UI Feedback, but I’ve found the first way you should get involved is to start using WordPress trunk: the live latest and greatest, but not ready for prime time players, version.
That seems like a departure from theme, but it’s not. We all start out as basic WordPress users. We use the product, we know how to add/edit/remove posts, we move on to using plugins, and eventually we hit a wall. Either we start to adapt and become power users, who understand how to tweak things in wp-config.php, play with SSH/FTP, and make a quick child theme, or we resign ourselves to using WordPress as it is presented. Neither use-case is better or worse than the other. If you’re a ‘hard core’ WordPress user, though, you will find yourself wishing for small fixes, and you’ll make a plugin for yourself. Then you share it, and then you start to suggest things in the forums, or report bugs in trac. Now we’re cooking with fire, and it’s not long before you start tossing out code or css ideas for trac.
The point of this is that if you start ‘testing’ the new versions of WordPress at the beta or release candidate iteration, you are too late in the game to make a UI comment. The Beta and RC releases aren’t for making drastic changes, but for making the changes that are in there work correctly. Like how the ‘close’ button on the admin bar pointed isn’t working on IE 7 or 8. That’s a bug. But not liking the admin sidebar menu flyout and disagreeing with it entirely isn’t a bug. Did you know the head of the UI team didn’t like the Admin Bar back when it came about?
You don’t have to like everything about a product to use it, and sometimes changes mean you need to rethink how you use it. Also, WordPress has a policy similar to Apple and Amazon: Release, then iterate. That’s why in the last three releases of WordPress, we’ve had one major change and two noticeable tweaks to the whole admin UI. The 3.0 release was a huge overhaul, and in both 3.1 and 3.2 (and now 3.3) we’ve had significant variations on a theme. They feel big, but compare it to the 2.9 to 3.0 jump and it’s really pretty small.
If you want to guide WordPress’s UI, get in on it earlier than beta. If you want to iron out bugs, join at Beta, but take the time to learn the difference between ‘I don’t like…’ and ‘this is broken….’ If you want to get new features early, join at RC. If you want to wait till we’re ready to go, wait for the final release. If you just use WordPress and trust that most everything will work, use the final releases. If you’re annoyed that little bugs get missed, use RC. If you know you’re using a fringe case, or setup that uses normal WordPress but on an obscure server or configuration, RC or Beta is where we need you. Remember, not everything can be tested, but you can help test more. However. If WordPress is your life, if you live and die by WordPress and support people who use it or need to be testing it in your corporate environment, then you need to step up and start using SVN. Make a second install and set up a job to update every few hours, pay attention to release dates, and don’t treat this like ‘traditional’ software and wait for a release to be notified as to what’s going on.
But that is another post all together.
Perhaps the best thing about a cooperative design, like in an open source app, is that if you don’t like the changes, most of the time you can find someone else who doesn’t, and who wrote a plugin/extension to change it. When you compare that to, say, Microsoft Word, and remember that you, as a user, have very little say in things unless you luck into their market studies or beta tests, and even then, the locked down systems don’t always permit changes, well, you’ve actually got a lot of freedom. And if you’re not a techie, well, make friends with one or hire one. I hear a lot of them like beer.