Design Initiative: Core theme selection and development process

Agreed.

With the goal of ensuring that all new themes meet a minimal degree of compliance to WCAG 2.0, I found it frustrating to have to follow the race to determine which theme would be selected for core. Of course, I could have waited to provide any accessibility review until the theme was in core (thus negating the desire to have a review before it is accepted into core). I could have also provided reviews on all three themes (which isn't going to happen).

The long time period of not knowing left me uncommitted to any particular theme. I believe that this meant that I didn't really have the focus to provide any theme the review it deserved for core candidacy.

Yes to the idea of a design first, theme later approach; I think some feelings were hurt in the process of the new theme selection, and this could've been entirely avoided had we simply voted more or less on a design mockup first, then worked to build an extremely robust theme later.

I think this whole process highlights some of the growing pains Drupal is going through with themers/designers in particular. Much of the argument over whether or not a particular theme could be used had to do with the code and the underpinnings of the theme. However, designers in particular don't typically care about the inner workings of a theme. They want to make sure it looks great, and is usable. After that, implementation, refinement and performance tuning is done by the community with the designer being a sort of 'shepherd' :)

Subscribing. This will be important for D8 for sure!

Subscribing

Sounds like a sensible plan, a stricter timeline in itself would encourage more involvement.

A couple of suggestions, which I'll leave floating:

1) Design Phase/Selection

Currently, designers are scarce on the landscape, hopefully this will change during the D7 lifecycle, but it could be good advertising to have the design phase as a competition - to encourage designers that wouldn't normally get involved in a code-centric environment to enter the fray.

This would a) increase visibility of Drupal & b) ensure that great designers have an avenue to get involved

I could imagine that several non-winning entries would also be built out as contrib themes.

2) Theme Build

I like the idea of a core theming team, but selection would have to be mega transparent, or face the wrath of thousands of potential community potentials. Maybe the involvement of the Drupal Association at this stage who could take submissions/applications from interested people, then sift this down and match with how much community involvement (good of course) has been seen. The last thing you want for essentially a community project is to have a great but non-contributing person to jump on board purely for the kudos of it being a core project.

I would say it's too early to start finalising a structure... but then again...

Ooh... the 'Theme Team' - I like it!

Something I've seen mentioned a few times by the community especially about the D.O. redesign is that is was too closed a process, and that they didn't have an opportunity to contribute as much as they would have liked.

When I say "competition" the emphasis is on reaching out to wider circles, rather than being some kind of spec work. It could be a straight up, submit a design and the community decides a shortlist of say 5 designs... leading to a top down decision based on what serves the purpose best. The launch of D7 is going to elevate some individuals status and D8 will have a greater effect, recognition is a great pull in the design community which is why I think this angle could work.

As was stated in the original post, a big problem with the D7 selection was that it wasn't on equal footing ... ie. sharper design wise not having strong enough coder backing. It would seem to me that a similar thing could happen if the decision was left just to a small core of people, they would select based on "which translates better" rather than "this design kicks ass, let's make the bugger work".

@dreamleaf, you make good points, and you are absolutely right that it would help if we could figure out how to get broader participation. Have you by chance read the Theming Contest thread from a year or two ago in the Theme Development group?

If not, you might want to familiarize yourself with this earlier discussion. It covers a number of important points to consider before we decide the best way to proceed.

Thanks Cliff... just spent a very long time reading that thread, and for fear of assassination, I will remove my +1 for a competition (damn I said the word!).

It kinda shocks me though that the conversation had lots of merited discussion, yet over a year later it appears the landscape hasn't changed all that much.

One angle that occured to me after reading though is that maybe the design talent IS already here, maybe not in large numbers but just stifled by lack of appropriate methods of collaborating. We see examples every day of great looking Drupal sites, all designed by "someone", and mostly involving companies/shops that ARE contributing to the community, on a code level. So I guess it's a matter of finding out which rock everyone is hiding under, and convincing them that they can make a contribution - and making the tools available to allow that to happen.

* Choose the next theme based on the design.
- Must conform to WCAG 2.0 AA (or be close enough to tweak into place)

* This should start early in the D8 cycle.
* We have a Theme team - a small group of highly experienced Drupal themers.
- One of whom who has proven accessibility skills, or an external non-themer with accessibility skills is included.

* Have a public submission and review phase - probably on g.d.o since it has vote up down.
- Fix vote up / down on GDO to make it accessible :) Or use another platform which is accessible.

* The top 3 to 5 designs are chosen as the candidates. We should allow for a wild card entry - maybe a late submission that's just too good to not consider.
* The D8 Theme team in conjunction with the D8 maintainers make the final decision.

Also, long descriptions (textual alternatives) of each candidate theme must be provided by designers to ensure that all community members are included in the decision process.

* Have a public submission and review phase - probably on g.d.o since it has vote up down.
- Fix vote up / down on GDO to make it accessible :) Or use another platform which is accessible.

Maybe a subdomain could be set up to accomodate, like the drupalCons get (http://cph2010.drupal.org/) ? Would make it more appealing to new-comers to the community. Providing relevant pointers to resources/groups that can help within the d.o sphere.

Awesome! Jeff strikes again ;) Woot!!!

I agree the process was not fun to say the least, but I'm happy to see an effort to stop it from happening again. I just hope that these two documents are merged together:

http://drupal.org/node/769692
http://groups.drupal.org/node/94164

@Jeff cool, sounds good :)

Sub

Great Idea, Jeff.
This would be a place where designers could chime in - they would not have to do much worrying about the code of a theme but just do the design.
What made the entire theme process so hard was of course that it started very late - long after the official code freeze. This gave little chance to healthy processes. So +1 for starting early and not fearing competition.

One thing has to be thought about, though: There are things that look great in mockups that do not work at all in reality. (Which also becomes clear about the bluecheese theme for the d.o. redesign now) So before a theme can be voted upon, at least a basic implementation must be done to see it live. This does not need to comply to any coding standards, but rather give a glimpse to how it looks with some live pages, comments, with and without images and some more basic everyday drupal stuff.

To make themes shine out of the box, we should also work hard to improve the situation of some sample content or more preconfiguration being able to be built in. These were very hard edges all the themes hit: Bartik could not include its nice extra regions, Busy very much needed one sidebar block to be of a different color but not the others, and so on.

Good thing we have gotten into it at all, though ;)

I agree with Jeff here. Let the designers submit designs. Those evaluating the designs will have the implementation experience to know if something simply cannot work.

design = usability + accessibility + style.

So, when I commented that designs need to be WCAG 2.0 AA compliant, designers shouldn't be worrying about form field labels, but more about color pallet and contrast, resizability, etc.

Well, O.K. A good designer is probably able to adapt the theme in the process if something just does not work out as expected.
The entire thing should be an iterative process: Having attended quite some sessions in CPH about this topic, I believe Design and implemenation should not be completly seperate in timeslots.

Design, implement, design some more, implement some more... No question the initial design vision must be strong. My comping idea was not implying the designer should do that, but rather the implementation team.

We have a Theme team - a small group of highly experienced Drupal themers

Why should the team be small?

Well if there are too many people, sure they can spoil the soup. But this asks rather for a well-organized and collaborative team. To get things done the team cannot be big enough, though. In the end it is always a small core team doing 80% of the work. But in any way limiting participation - I do not have good experience with this in Drupal.

I'd be interested in submitting a design for the selection process as I had started a thread in the Design for Drupal group about a contrib theme asking what the community would like to see that currently isn't on offer or if people felt there was a particular gap in the contrib themes.

I've read all of the above so from my understanding the "spec" is completely open at the moment and features will get considered second? Also would it be preferencial to design the most flexible layout possible, I was thinking of possibly color module intergration if the theme swapping idea was to come into fruition as a possible update to Garland.

I'd be interested to get this rolling as I'm sure other designers would that will be producing a submission.

There will be a D8 accessibility BoF at Drupalcon today 11am (CST) and I will be joining via Skype. Discussion of the D8 a11y gate will likely take place. My goal is for the a11y team to present a unanimous recommendation to Dries and the D8 co-maintainer(s).

With the suggestion of a typographical and colorable driven theme could CSS3 be an option to throw in the mix? This would be a good way of getting a theme in core that was utilising new styling technology and would be nice for the designers to have a bit more of a challenge.

If HTML5 is being backed for D8 why not get some CSS3 goodness in there as well?

One other suggestion: A theme that is designed for mobile first, but changes to accommodate larger screen sizes. Some good food for thought: http://www.lukew.com/ff/entry.asp?1117

I was thinking along the lines of more interactive CSS3 techniques, not overdoing it just bringing in subtle differences using the transform and transition effects as examples of what can be achieved. The coding is a no brainer and to quote Dan Cederholm's phrase it would be "harmless degradation for browsers that don't support it" and I personally like to support new technologies where I can.

By the time D8 is out these will be mainstream techniques so it's just a bit of forward planning as I see it.

subscribing

hai. subscribe.

It would really help spec the design brief for this by defining things that this theme will *not* do.

subscribe

@Jeff
design selection before start theming is the way to go for sure as every body do practice the same stuff day-in-day out.

But the part missing here are the design objective. I personally fear that creating a generic core theme will create another theme monster like Garland.

If we really think of a theme, at looking to which people (read designers) gets attracted to explore DRUPAL we need to really think of few modules to be included in CORE. Other wise I do not think we could really come up with a theme which will be able to compete with other platforms like WP, Joomla etc as core theme.

My suggestion will be lets have objective to package a theme as a usable marketable one which will out-compete other platform (CMS) by design, UX, usability standards, technology.

Subscribe.

I suppose this is a question that will be answered by a proper Design Brief, but I have to ask: is the goal of this initiative to provide a theme that will be a great start for Drupal themers, a great out-of-the-box theme for website developers, or a best-in-class solution for the Drupal administrative interface? Personally, I think the latter is the best approach. It would improve the Drupal UX; it represents a concrete design problem (as opposed to some abstract "design me a site with two sidebars" problem); and it could be the best way to get more people interested in using Drupal.

My take on this is that the theme should be a flagship theme that attracts users primarily and showcases that Drupal can stand with head held high among other more classically design led CMS. Of course administrative functions are important but not necessarily within this project, such as D7 shipping with Seven for administrative use, and Bartik as the core theme.

I also think the idea of a contest, or even something that remotely feels like a contest, is not going to attract any good design talent (for reasons that have already been explored in great length elsewhere). I think one very good way would be to first gauge what kind of interest there is for a specific problem (and have a clearly articulated brief so people know what the project really is). From that pool of interested people pick (based on talent and ability to commit to the project) a smaller group of designers who will work together to build a new theme design for D8. Limit those who participate in the project to a talented, committed group but open up the discussion of a candidate design to a wider audience for review and comment.

This approach would make sure that you have the right people for the job; that they are solving a clearly articulated problem; and that there isn't some "Theme team" that has to sift through a mountain of submitted designs, narrowing it down to a few to be voted upon.

Also, the "Theme team" should not be just front-end developers or Drupal themers. Get some designers. Call Jeff Zeldman. Have a true design/ux evaluation team that includes the core maintainers, knowledgeable designers, and theme developers.

One final thought: you wouldn't treat core code development like an open contest, would you? You get a few talented, committed folks and give them the ability to commit code. Everyone else gets to review and comment, but without having the keys to the kingdom. Why not treat the design of a core theme the same way?

Then perhaps there ought to be a few core showcase themes that represent popular use cases. For example, a showcase newspaper website theme, or a showcase online portfolio theme, or a showcase online community theme. It's not likely that one theme is going to be a good or "flagship" theme in every case. Maybe that's why I don't think any of the 'popular' Drupal themes (including, sadly, Bartik) are compelling from a design perspective. They may be coded well, but that's about it.

I see where you are coming from but I think your missing the fact that Drupal is a huge beast of a framework. A 'core' theme should be one that showcases the 'core' functionality out of the box. So that largely depends on what the core functionality of Drupal 8 will ship with. If D8 ships with views, context, features and a few other cool modules then anything is possible. However, at this stage we are basing opinions based on what we "see or know", in which case the core features are 'page, article, forum, poll, book, blog etc".

As mentioned in one of the threads, the Snowman project is working to see what specific use cases can be met out of the box, but to be honest we know that to leverage the true power of Drupal, contrib is essential. And you can't base a core theme on "certain contrib modules".

A flagship theme does not need to meet several specific use cases, it needs to showcase what is possible, and just using core modules you can demonstrate a lot of uses. Maybe there should be a secondary initiative to create a features server, whereby we can all build feature sets of functionality that (if really committed) could be "contrib features to the core theme". Of course that's off topic, but basically a solution to the use case scenario.

From dreamleaf

A 'core' theme should be one that showcases the 'core' functionality out of the box.

That's a useful way to narrow the scope of the project, and I can support that. I think it's still very important to consider ux for the administrative interface. Perhaps that's a separate project.

aaronpinero: admin ux is another important but yes, separate project.

Is this issue projected to remain open for the duration of the D8 development cycle?

If not, what else remains to be decided here, since it seems, Jeff, that you are now pointing people to #1087784: Add new theme to Drupal 8.1.x or another minor version?

I am in agreement that there should be a (preliminary at least) design phase distinct from the development phase, and that the development phase should be conducted by a small subset of people. This is somewhat similar to what Moodle did for their 2.0 release - except they actually contracted a single person to design their themes.

It sounds like the idea of a competition has some serious drawbacks; however, we do want to have an open process at the beginning for people to submit comps. I'm not sure what is the best way to encourage participation - I think the issue queue is definitely intimidating for non-developers, and also its linear format makes it an inefficient interface for evaluating designs.

As I stated in #737136: Put together a list of must-have features for new core themes and set a final deadline for implementing them, I don't think adding fancy custom theme settings, JS frameworks specific to a theme, or Flash will fly in core. I think the idea of having a fairly minimalist theme is better.

It seems to me that once everyone is in agreement with the proposal outlined in this issue, it should be marked "fixed", and the information added to a core initiatives page on Drupal.org that would take the content from the wiki page on g.d.o (if that is also finalized), and would link to the theme requirements page.

I agree with the comment on the wiki page, and the similar comments here, though, that a design brief requires more detail than simply the mandatory requirements. In themselves those are not an inspiration for designers.

I like the idea of focusing on a minimalist theme (but not a base theme, or a demonstration theme, like Stark, nor an admin theme, since we already have one). I think we'll have to wait until the use cases for core are more solidified before we can describe a specific use case for the theme though.

Where's the right place to say something about this? Is it here (in this issue), or here (the Wiki page for ..)?

I'll make my comment here for now. I suggest there are two things you should have as part of your process:

1. Real usability tests. If "design" is going to be the first criteria you use for selection (vs. theme code), then the design should have some real-life usability testing done before it is selected. I know we have some usability folks in the community that could / should want to help with this. I think it's probably too much to ask each candidate design to furnish usability tests; but maybe once you come down to a couple (2-3) finalist candidates, you can do some A/B testing to see which one has better usability. I know we at Acquia have started to usability test all kinds of things, and have the process down pretty well. I'm sure our team would be willing - nee, interested - in helping make this be a regular process used in the community.
2. Multi-device (or at least multi-screen) rendering alternatives. Though I'm not sure I can point at d.o discussions about it now, I know Jessee Beach and others have been talking about Responsive Web Design. Where in your theme selection process would this come up? During the design (selection) phase, or during the theme implementation phase? It seems to me that it likely overlaps both.

There's also another possible missing element here: Mobile (or even the larger set of "devices", e.g. tablets). This may relate to the Responsive Web Design aspect above, but even if sites that really want to have a good mobile interface should really have a mobile theme, it seems to me that the default D8 theme should at least be something that renders reasonably well on a non-desktop display. Where would this fit in your evaluation / selection process?

Finally, there's yet one more thing: Javascript / jQuery / Ajax. Drupal will (hopefully) be doing more and more things via more dynamic interfaces. The front end display should encourage this, and make it easy to increasingly use this UX approach - lest Drupal get stuck in the page-oriented web. Where does this play in your selection process? Does it..? If not, should it (or not)?

"In the past the very concept of a core theme have anything but basic features of Drupal (toggle settings, color module support etc) has been somewhat frowned upon"

To be clear, what was frowned upon was wildly inconsistent settings among core themes (this one has a "show sample content" checkbox, vs. that one has settings for what the header image should be), in favour of instead making any theme features worth having "global" so they're available to all themes, core and contrib both. However, adding new theme features to core wasn't possible at the time the D7 theme initiative was in full swing because it was months after code freeze, and so themes were asked to pare down on the whiz-bang stuff.

Not that this isn't a reason to change the status quo if that's seen as valuable and strategic by the design team (though as a novice-level theme developer, I'd much rather have a set of rich theme features I can simply turn on and off in my .info file as opposed to having to copy/paste a bunch of code into my theme to get the same functionality...), but I wanted to correct what the rationale was.

I noticed today that the Design Initiative is listed in the 'previous/inactive' initiatives and we have new themes in code. Therefor, I am closing it as outdated.