By 2013, WordPress’ admin had seen little change since the Crazyhorse redesign in 2008. Change happened in 2013, though it didn’t only result in a new look for WordPress. WordPress feature development changed, introducing a new approach in which feature design, feedback, and iteration used a plugin that was eventually merged with core.
In January 2013, Ben Dunkle proposed new, flat icons. The WordPress admin was outdated, particularly on retina displays where the icons pixelated. Flat icons would scale properly and also allow designers to color icons using CSS. Andrew Ozz checked in the changes.
The changes kicked off huge discussions about icons, a new trac ticket, and a long discussion on the UI P2. People were divided on the icons. Some liked them, but felt that they didn’t fit WordPress’ admin design; modern icons only emphasized how dated the rest of the admin had become. Consensus didn’t materialize. Mark, who was release lead at the time, decided not to put the changes in WordPress 3.6. Instead, designers interested in redesigning the admin could iterate on the design in a plugin called MP6.
Matt Miklic (MT), the designer who had put the original coat of paint on Crazyhorse, helmed MP6. Via Skype, Matt asked MT and Ben Dunkle to reimagine WordPress’ admin, consider how a redesign could work, and set parameters. MT believed that they ought to respect the research that informed Crazyhorse’s UI. Instead of iterating the layout and functionality, they focused on an aesthetic refresh.
Both Matt and MT were keenly aware of the issues and challenges in each major WordPress admin redesign. They wanted MP6 to be different.
Shuttle, for example, had been cut off from the rest of the community, designed by a cloistered group of designers trading comps and slowly losing touch with “the client.” No one person was responsible for Shuttle’s overall vision; there was no accountability.
By contrast, the Happy Cog team looked at WordPress with a fresh set of eyes. Their distance allowed them to treat WordPress as a piece of software, not as an object of devotion. They stayed in touch with their client — Matt — but were removed from the community’s thoughts and opinions. MP6 solicited feedback from all of the people with a stake in the project. That brought its own challenges — whose feedback was the most legitimate? What should be integrated? When was someone just complaining for the sake of it?
Crazyhorse emphasized the importance of in-depth user testing. With all the testing on Crazyhorse, MT knew that he didn’t want to carry out a structural overhaul, conduct extensive tests, and gather the data needed to prove improvement.
The MP6 project took a different approach. Like Shuttle, a group of designers worked alongside the free software project. Instead of a mailing list, they had a Skype channel so that they could talk in private, but anyone was allowed to join in. “Even though the group worked in private,” says MT, “the door into the group we were working on was open, so if anyone said they were interested they could just walk in.” This allowed people less comfortable with WordPress’ chaotic bazaar to participate. Designers traded ideas and feedback — without the danger of someone coming out of nowhere and tearing an idea down before it was even fully formed.
The MP6 project took advantage of WordPress’ plugin architecture; work took place on a plugin hosted on the WordPress plugin directory. Anyone could install the plugin and see the changes in their admin. Every week, the group shared a release and a report open to public feedback. This open process meant that community members could be involved on different levels. It also meant that the group could never steer too far off course. The core team was always aware of what was going on with MP6 and could provide feedback. More designers were involved than with Shuttle: the group grew to fifteen members. With MT as lead, they avoided the “too many cooks” problem. The designers and the community accepted that MT had the final say on the design.
The MP6 project was announced in March 2013. The design process began with MT playing around with the CSS. He started out with a unified, black, L-shaped bar around the top and the side of the admin screen: “the idea,” he said, “was that the black would feel like a background and the white would feel like the sheet of paper lying on top of it, so it would unify these disparate things.” Once MT assembled the basic visual, the contributors refined the design. These changes happened iteratively. The community saw a report and a new plugin release each week, on which they gave feedback.
Challenges arose. Google web fonts caused heated discussion. Web fonts are designed specifically for the web. They’re often hosted in a font repository. A designer uses a CSS declaration to connect to the repository and the font is delivered to a website or app. MP6 uses the Open Sans font, which means that the font in WordPress’ admin screens is hosted on Google’s servers. Whenever a user logs into their admin, Google serves the fonts. Some don’t want to connect to Google from their website; this also causes problems for people in countries where Google is blocked. Bundling the fonts with WordPress, however, requires a huge amount of specialized work to ensure that they work across platforms, browsers, and in different languages. In the end, they decided to use Google web fonts. A plugin was created to allow users to shut them off.
Despite minor hitches, the MP6 project went smoothly. Joen Asmussen, who’d been a part of the Shuttle project eight years earlier said, “I would say that MP6 did everything right that Shuttle did wrong.”
Over the eight years since the first attempt to redesign WordPress’ admin, WordPress had matured. When things are done behind closed doors, people feel disenfranchised, and yet the bazaar style model doesn’t suit every, single aspect of software development. It’s within this tension that a balance must be struck, with space for ideas to flourish.
The MP6 plugin merged with WordPress 3.8, released in December 2013, demonstrating that, while it may take a while to get there, harmonious design in a free software project is possible.
All of this happened as 3.6 rumbled on. Development continued on the core product, MP6 development happened separately; it wasn’t constrained by WordPress’ release timeline. MT and the designers iterated quickly; users installed the plugin to test it and offer feedback. This was a new process that hadn’t been possible before. To test new features in the past, a user would have to run trunk. By developing the feature as a plugin, a community member could focus by helping with the sole plugin that they were interested in.
MP6 was proving to be a success, and in the summer of 2013, it was decided, for the first time, to develop two versions of WordPress simultaneously — 3.7 and 3.8. WordPress 3.7 was a two-month, platform-focused, stability and security release lead by Andrew Nacin and John Cave. New features in 3.8 were developed as a plugin.
This “features as plugins” method* will allow teams to conceptualize, design, and fully develop features before landing them in core. This removes a lot of the risk of a particular feature introducing uncertainty into a release (see also 3.6, 3.5, 3.4 …) and provides ample room for experimentation, testing, and failure. As we’ve seen with MP6, the autonomy given to a feature team can also allow for more rapid development. And in a way, 3.7 provides a bit of a buffer while we get this new process off the ground.
While the project prepared to merge MP6 as a plugin in WordPress 3.8, an opportunity arose to do automatic updates — something that had been talked of within the project for years. Automatic updates had long been a goal, previously unachievable. Automatic updates needed the proper code structure to be in place on WordPress.org, as well as community trust. Community members needed to be okay with WordPress changing their site automatically.
WordPress has collected data since WordPress 2.3 that allows WordPress.org to create personalized automatic updates. WordPress uses the data to make sure that a site receives an update compatible with its PHP version and site settings. In the few failure cases, the user gets an error message with an email address that they can use to email the core developers who will fix their website. As of late 2014, automatic updates are for point releases only. So while major releases of WordPress are not automatic (3.7, 3.8, etc.) point releases are (3.7.1, 3.8.1, for example). This means that security updates and bug fixes can easily be pushed out to all WordPress users.
Within the space of just two short releases — 3.7 and 3.8 — big changes transformed the software and the development process. Automatic updates mean that WordPress users are safer than ever. WordPress 3.8 saw the first release in which a feature developed as a plugin merged with core. This finally decoupled core development from feature development. So many past delays and setbacks happened because a feature held up a release. It gave developers more scope for experimentation and created safe spaces for contributors to get involved with core development. While the MP6 admin redesign was the first plugin integrated under this model, since then, feature-plugins have brought in a widget customizer, a new theme experience, and widget functionality changes. Experiments are ongoing in image editing, front-end editing, user session management, and menus.
