As people experimented with ways to make money with WordPress, design changes were underway in the interface. Between 2005 and 2006, the WordPress community organized the “Shuttle” project to overhaul WordPress’ admin screens. Their aim: to create a coherent, distinct look for WordPress by redesigning wp-admin, which had inherited its design from b2.
The group’s aesthetic refresh reimagined and modernized wp-admin, iterating on the design without re-architecting the interface or adding new features. They started work in the wake of WordPress 1.5, which came out with a set of admin screens ripe for improvement:
Just as dealing with spam revealed tensions in the development process, Shuttle’s work highlighted a pressure point: squaring coherent design and free software development. Design decisions, which are usually highly subjective, seem not to lend themselves to a public process. To work effectively, Shuttle felt they needed to tweak their methods.
Linus’s Law, outlined by Eric Raymond, says that “given enough eyeballs, all bugs are shallow.” If there’s a bug in the software, make the code available to many people; someone will see the solution. For an issue with a defined answer, this can speed progress considerably. With design so subjective in nature, however, Shuttle designers worried that an open process would lead to too many cooks in the kitchen, and that competing opinions would lead to stalemates.
Unlike WordPress’ core developers, the Shuttle group communicated via private mailing list, wp-design. This list was open, but list archives weren’t public. To be involved, a contributor had to be added to the group, and the group had to agree to add the new member. Discussions among members indicate that they deliberately tried to keep the group limited. “An open mailing list would become so much noise and so little signal so quickly that there would be no way we could move forward,” recalls Chris Davis.
The group remained small, with three main designers — Michael, Joen, and Khaled — supported by coders responsible for realizing the design vision. The group sent designs around among themselves, offered feedback on one another’s work, and iterated on the design. They focused on specific elements, mainly the Post screen (
post.php). Over the course of the project, twenty-eight versions circulated among this group.
As the design process continued, elements of Shuttle were implemented in WordPress. One of the earliest Shuttle designs increased the size of the title field in the
post.php edit screen.
Another iteration of the
post.php screen collapsed elements like post status, categories, and author.
When WordPress 2.0 shipped with Shuttle-inspired changes, the feedback wasn’t entirely positive. Molly Holzschlag wrote that “what WP2.0 has gained in interface appeal it’s lost in some practicality too.” Piecemeal implementation of their vision kept the Shuttle group from creating a single, cohesive redesign.
The project was beset by other problems. Despite the closed mailing list, progress stalled without a clear leader charged with the project’s overall vision. When one skims the mailing list’s archives today, it reads like a design-focused discussion forum rather than the communications of a focused team with a clear task. As the Shuttle team discovered, a group of independent designers, each with their own ideas, can trip up design work as surely as a mailing list full of hackers.
It took the group a long time to complete work. They discussed minor design elements like rounded corners and gradients for lengthy periods, rather than examining the fundamental needs and wants of WordPress users. “I don’t know if we were cooperating enough on getting a unified feel and a unified understanding of everything before we tried to actually apply our ideas to the problem,” says Michael. Besides that, the contributors had jobs that absorbed their time, so work happened in fits and starts. While the original plan was to complete the admin redesign within three months, by mid-April 2005, this slid to September. The team eventually missed the deadline for WordPress 2.0 in late 2005. The next deadline (for inclusion in WordPress 2.1, which itself never materialized) was the end of January, though it was March 2006 before a complete set of mockups arrived.
It was then that Khaled sent out a comprehensive set of screenshots with his vision for the new WordPress admin:
The rest of the group loved the designs, and the developers began coding. Still, development dragged on. In mid-April, Michael Heilemann withdrew from the project, saying that he had to prioritize other commitments. The same month, Khaled asked whether Matt or Ryan would ever get around to implementing the design. The response placed the redesign as a medium priority. Changes would be iterative.
On May 14 2006, Khaled posted a complete set of designs to his blog, bringing the Shuttle project to a close. He was still under the impression that the mockups would be implemented in due course. They never were. Khaled and other members of the group felt disenfranchised, and drifted away from the community. Chris Davis and Michael Heilemann made the switch from WordPress to the Habari project.
The biggest failure of the Shuttle project wasn’t the designs or implementation, but the process itself. To avoid getting bogged down with too many opinions, the group closed itself off from the community — which created a new set of problems. Isolated from the larger community, they lost touch with the development process. The project’s closed nature limited opportunities for other enthusiastic designers to step in and move the work forward. For each person excited to see a spectacular WordPress redesign, there was another person resentful that a blessed group of designers was working privately on something the whole community had a stake in.
In one of the final emails on the wp-design mailing list, Matt outlined some of the things that he learned about design-oriented free software projects:
- Work should not be done in private
- Design by committee doesn’t work, better to break up tasks and let individual people focus on one section
- Focus on lots of incremental changes, rather than giant redesigns (you end up in the same place, and probably sooner)
- Document the process and decisions along the way
- Code concurrently with the designs (and iterate)
- Don’t hype it, expectations get out of control
- Avoid scope creep of features into designs
- Set a deadline and stick to it
These tenets influenced the relationship between WordPress design and development, helping future design projects avoid the difficulties faced by the Shuttle group.