As a followup to yesterday's article about the new UI, this is a call for contributors.

Specifically:

1. We could use someone versed in CSS to help make the new UI look acceptable in Bartik and additionally it'd be nice if the 'base' version was at least usable in Stark. We're using a system where we can bring in stylesheets for specific things, so what we really want to do is provide some kind of basis for theme developers so that they can help tune the Views UI to their theme if they expect people to do administration in it.
   

Today, I merged the working branch for the Views 3 UX project into the 7.x-3.x branch of Views. This means that, as of midnight, GMT, everyone now has access to the completely retooled UI for Views, that was spearheaded by Acquia and specifically led by Jeff Noyes and Chris Brookins.

Note: To have access to this, please use the latest CTools -dev or latest CTools release. Some things in CTools had to be updated to support Views' use of export.inc.

Amazon (and presumably the rest of the book-selling world) now has Drupal's Building Blocks on sale!

To celebrate managing to actually get this book to press, I'll be giving away four signed copies.

The book ended up being long overdue because, mostly, I couldn't manage to prioritize it up enough to get it done.

It took Emma Jane Hogbin to step in and finish a few bits and polish it a little to get this book to actually go to press. It should be printed right before Christmas and will spend a couple of weeks in transit. Amazon says Jan 10, which is probably about right.

Last week, esmerel and I wrote up the handbook for the Views' Bug Squad, and we did a bit of a soft launch, only immediately telling people on IRC. This turned out to be a good thing, because a bug on drupal.org prevented us from actually getting it going, and all of the drupal.org maintainers who could fix the bug were, unsurprisingly, busy on the redesign.

Heather James pointed me at drupal.org instructions on performing triage in various queues. Naturally, that article focuses on the Views queue, because it is one of the 5 most difficult queues to manage on drupal.org. (To my surprise, GMap ended up being in that list as well.) The things it focuses on are relatively easy tasks, with some suggestions.

The last few weeks have seen an intense flurry of work on the Panels suite of modules. Today I've rolled releases of the Panels 3.7, CTools 1.7, Panels Everywhere 1.1 and a tiny bugfix release for Tinsel 1.1. This has created a massive chunk of new features that we're hoping will push Panels even more into the mainstream by seriously extending the power available to site builders, particularly in terms of giving site administrators better options for doing their jobs without having to worry about details they've taken care of.

I'm pretty impressed at all the excitement coming out of the whole design4drupal initiative. Lots of people are talking, and the chatter is everywhere. Unfortunately, from my perspective, it's looking like it may actually turn out to be one of the most damaging things that can happen to Drupal, and this one is bothering me at a very deep level. And perhaps this is something that's been building up, because I have definitely noticed my enthusiasm waning over the last year, and things like this are really putting a bullet into the heart of it.

I've spent a lot of my 'between' time thinking about what I want to see for the next major revisions of Views, and I've finally decided to sit down and actually create a road map. Views 3 isn't like Views 2 in the sense that there will be a rewrite. On the contrary, I'm really happy with the foundation of Views 2 and I believe that we have a solid system for building on. What I'm unhappy with are features that got left out, or that I didn't even know we would need.

I'd like to compile a list of modules that use Views heavily (examples: Flag, Views Bulk Operations, Views Attach, Views Reference) with a blurb about each of them. The blurb would contain a neutral description of what they do, and then a non-neutral comment on the quality and maintenance level of the modules. Obviously the latter is a judgment call and I don't expect it to be completely dead on, but I would like to note projects that are well known to rarely get bugs fixed. Another comment might be known usage levels, some of which can be gleaned from the shiny new usage statistics.