[wp-design] Re: Shuttle Way Forward

[Matt Mullenweg]

Joen Asmussen wrote:
> If these mockups do not become part of the official Wordpress release at 
> some point (no matter when, 2.5, 3), then what the hell has this 
> year-and-a-half of work been good for? This is FREE work by people who 
> do it for the love of it! Is it being scrapped, or picked at like some 
> cold christmas dinner?

I'm sorry if I miscommunicated: I wasn't saying it won't be 
incorporated, but rather that it'll take time, just as getting to this 
point has taken time. Historically I've been the one coding admin 
improvements for WP, and I know it'll take me a bit to get to 
everything, that's all. If I had to guess, I'd say 2-4 months for things 
to really start looking like the mockups.

If the changes were purely aesthetic, it'd still be a big task, but 
there are fundamental changes like the new sidebars and changes to the 
ways some of the tables are displayed. The changes will touch almost 
every file in the admin, inevitably introduce bugs, and really 
constitute a release and testing cycle all by themselves.

The mockups are really just a starting point for work that's going to 
take months. Shuttle isn't done, it's just getting started. ;)

And even when it's "done" there'll still be things that need fixing:

http://photomatt.backpackit.com/page/394123

(BTW, Michael's notes above are ultra-useful and would be great broken 
up to individual issues on Trac, if any of you guys want to contribute 
similar things in the future.)

If you guys prefer, I could hold off any changes until everything is 
completely finished, but honestly breaking it up into a bunch of small 
tasks is infinitely more likely to get done.

For future attempts like this, I've learned the following things from 
Shuttle:

* 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

I'd be curious to hear other folks thoughts on how a design-oriented 
project in Open Source could be done better as well, or things you 
learned from Shuttle. Be harsh if necessary!

-- 
Matt Mullenweg
  http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com