At Drupalcon Szeged, I had some discussions with the documentation team and the usability team regarding workflow for getting their feedback injected early into the core development process. I'd like to start a similar discussion here with you folks.
Drupal 7 with its code freeze date of "When it's ready" represents a great opportunity for us all to collectively "kick it up a notch." Key to this is involving many more people in the core development process than we normally have. There are always several relatively minor core patches that affect themers in the queue at any given time, such as add $node_classes to node templates, as well as huge, over-arching efforts such as administration theme in core.
But unfortunately, a lot of these patches stagnate and die, because designers have not traditionally been a group of people that we've served particularly well. I'd like to see that changed.
I'd love to brainstorm ideas on:
1. How can we facilitate a core group of designers ("design team") working together to tackle of these larger issues to make Drupal 7 beautiful and more approachable for themers/designers?
2. How best to funnel down "patches that affect themers" so that you can offer your thoughts on them?
3. How to setup some "Design Sanity Check" guidelines that developers need to adhere to just as they do coding standards and automated test requirements?
4. How we compile a list of your "itches" that are barriers to new designers getting involved, and attract developers to work on these issues?
5. Other thoughts you have on this or any related topic.
So let's hear it. What can I as a core co-maintainer do to help you all make Drupal 7 kick the design and theming crap out of any other Drupal release to date? :)
Comments
How about expanding the
How about expanding the "patch spotlight" to include one patch from Features, Usability, Pretty, Performance, ...
I think that's an excellent
I think that's an excellent idea!
Knowing where to look; making it easier to find issues that need attention would help a great deal in engaging designers/themers in core patch reviews.
Do people click the patch spotlight?
Curious to know, does it actually help getting patches in the spotlight, reviewed, worked on?
Great little idea we should def. try if it does!
Not really. In general,
Not really. In general, people don't review patches at all. However if it's design/feature stuff, it might generate more interest from different people compared to the API patches that usually go in there.
And we want to avoid adding
And we want to avoid adding even more mindless "+1, subcribe" posts. We need some advice on how to go about this from people like you! (http://groups.drupal.org/node/14755#comment-49341 discusses same)
Patch Sandbox sites idea
Designers will not do patch testing, but what if we had a set of sandbox sites to test different stuff (mixed with the random bingo thing).
Imagine a sandbox site - patch01010101.drupaltests.org and it had core + patch(es) installed with a large persistent message at the top of each [sandbox] demo/test site stating what the goal is and which modules/patches their trying on the site. Folks can click around and click on some easy form/widget to report comments & errors at any time.
Additionally there would be error_log files filling up with code malfunctions and warnings that could be looked at or reported back to maintainers.
Chris Charlton, Author & Drupal Community Leader, Enterprise Level Consultant
I teach you how to build Drupal Themes http://tinyurl.com/theme-drupal and provide add-on software at http://xtnd.us
We have testing.drupal.org
We have testing.drupal.org which handles some failures. It would be very cool to be able to request a 'demo' site for particular patches from there which'd remain installed and could be linked from the issue. This would only be necessary for big patches, in other cases images and screencasts should work.
One thing that's worth mentioning - if you ask, developers will often provide screenshots which can make it a lot easier to review a patch. If you don't ask, you don't get :)
I'm no core but I know designers
I have an additional idea that I can help with or just spark. My digital life has been liaison between design and development teams for tons of places and while I'm not a core contributor I do know that designers feel left out in the the Drupal cold when it comes to "stuff for them," which to some of us sounds absurd if they all read the manuals (over and over again).
When I taught my Basic Drupal course a few weeks back I handed out a Drupal installation checklist with all the MUST-Do's and MUST-Know's everyone would need to remember/know when they walk away. The class helped me tweak the list to make it better, since we used it in class one whole day, and at the end I sent them all the revised PDF. I'm a big fan of lists because I think people see their progress while completing a list, and maybe if there's easy-to-pass bullets (of links or instructions, or both), then some designers will maybe say, "hey, I can do this."
This idea seems fine for info and more direct "do/try this XXXX."
Chris Charlton, Author & Drupal Community Leader, Enterprise Level Consultant
I teach you how to build Drupal Themes http://tinyurl.com/theme-drupal and provide add-on software at http://xtnd.us
Documentation
I just wanted to chime in since ccharlton mentions reading the manuals. I recognize that there's a documentation team that's working on all the Drupal docs, and their work is much appreciated. However, even though I'm really experienced in Drupal, I find myself lost in some of the documentation.
I'm wondering what the balance is of developers vs. themers vs. user experience folks on the documentation team? In my experience, developers write great documentation for other developers...but it's Greek to everyone else. What about a push to getting some people assisting on documentation who don't know a lick about development. Then, they could review the docs and say "hey, half of this makes no sense to normal people :)", thereby improving the clarity of the documentation.
Just my 2 cents (which you'll no doubt see alot of on this thread since it's one of my passions)
Why don't they join?
This makes me wonder why more themers/designers don't join the documentation team. The details are at http://drupal.org/node/23367 which is a link I got to from the contribute link in the drupal.org main nav. It's not one of the hard to find things on drupal.org.
Any thoughts out there from themers/designers?
Matt Farina
www.innovatingtomorrow.net
www.geeksandgod.com
www.superaveragepodcast.com
www.mattfarina.com
Code is Gold...but so is perspective.
Drupal is a powerful CMS because it has SUCH a strong development community. As we all know, "Code is Gold" rules here. I think, related to this, there's a couple abstract issues that could help designers and user experience folks get involved easier. (hopefully this won't sound like a rant...it's not intended to, so if you take offense to something, know it wasn't intended that way) They are:
I think, just recognizing this expectation that's put on themers (to be more than designers) just needs to be recognized and made clear. I think the definition of "what it means to be a themer" needs to be said loud and clear...then (when the answer is that you also have to be a developer of some sort), a role for traditional designers (photoshop/html/css folks) and pure user experience people needs to be created. Where can THEY get in on the process?
Personally, I can't build a custom module. However, I build with Drupal day in and day out and that gives me the experience and the perspective to understand why parts of it are unusable, ideas on how they could work better, and thoughts on how to improve the system's usability as a whole. So, what's the problem? My experience has been that just "talking" about these issues and giving ideas to developers who can actually implement them is frowned upon...again the feeling I get from developers is "I have enough to think about...don't tell me your great ideas if you can't help me built them".
So, I think it could be amazing to figure out a way to hook user experience folks up with developers who will LISTEN and setup a situation where code isn't the only gold...but suggestions on how to make a better Drupal are valued and heard as well, even if the speaker can't actually make them happen.
Ok, that was long....but thanks for asking, @webchick. In my experience as a Drupal themer/designer, these two philosophical changes would go a LONG way to improving Drupal as a system that people other than developers can contribute to.
Die-hard programmers (you
Die-hard programmers (you know, people who are great at math, lock themselves up in their room all day and who can write code that's so damn efficient but hardly usable for the average user, blah blah) are often great at efficiency, at performance tuning, at solving complicated problems, but only code-wise. They're often not good at usability and listening to the actual user IMO. This is quite logical, since programming and usability are two very different things, but it's something to keep in mind. These are the kind of people that think about flexibility and expandability in the form of "Our baby can do ANYTHING", while, in fact, it doesn't even have to do half that, simply because the end user doesn't require it to. Of course this picture is greatly exaggerated, but I assume you get my point: programmers mostly have other skills than knowledge of usability. This is where the average user comes in. He must make clear what he would like Drupal to do and how he wants Drupal to do it. Simply shouting "Hey, I'd like Drupal to be able to serve RSS feeds" isn't enough. Programmers need information about how users want to configure and access those feeds, for instance. In short: both parties need to listen to eachother and explain their wishes carefully.
Also, if you take a look at the issue queue of any module that's being used much or at core's, you'll notice that there are a lot of bugs and feature requests still unanswered. Often there's not enough manpower to take care of all issues. I believe this is another reason why some developers don't listen to users. They simply don't have the time to attend to every issue. It would definitely help if users would get together and brainstorm about what they would like to see, instead of simply subscribe themselves to the issue with a "+1, I'd very much like to see this in core!". Again, both developers and users need to listen and explain what they want.
Themers and end users, please join us in the issue queue and tell us what you want! :-D
By the way: this is no rant on users or developers. I was just trying to share my point of view as a developer/end user :-)
One of the things I am
One of the things I am thinking of is that I dedicate maybe 1-2 hours per week participating in the patch review/patch spotlight, I estimate that my learning about programming for Drupal/familiarity with Drupal will increase quite a bit (so long as learners do not get on the nerves of people more versed in what is going on which I could see happening in reality)
So, I am going to try and make this my thing for the next few months, since I have so much Drupal work going on right now anyway....
Sam Rose
Social Synergy
Open Source Ecology
P2P Foundation
Sam Rose
Hollymead Capital Partners
P2P Foundation
Social Media Classroom
bravo webchick
I applaud your outreach and effort to get "the others" involved, and agree there is definitely a need for designers/themers to be part of the family (and the family's plans :) ). I would be willing to also dedicate some time each week/month and outreach to the local DUG's in my area as part of this effort.