The Design Initiatives main purpose is to build a new theme for Drupal 8 and as part of this initiative we are preparing a Design Brief. The brief will be part of a "Designers Toolkit" which also includes a set of wire-frames. The brief itself comprises of two parts - a set of documents outlining Drupal core output (to support and clarify the wire-frames) and a Use Case Brief. Its the last bit I want to talk about here and open up discussion on. In essence what should this use case be?
Before I get into this I want to make one thing very clear - this is not a discussion about implementation, code, semantics or starter themes and so on. This is about a discussion what the common use case is.
After some discussion and thought we basically narrowed down to two questions to help us frame the discussion - who typically uses a core theme and what types of sites do they build? I tend to think we can expand this a little bit and include contrib/free themes also because its pretty trivial to install a new theme.
There is very little data available to help us deduce any answers to these questions and everyone is likely to have their own ideas, I have my own perspective having been heavily involved in both core theme development and being a heavy contributor of contrib and other free themes for Drupal 6 and 7.
From my point of view the common use case that Jeff Eaton came up in the Snowman project has a lot going for it:
small groups that are doing something together together, telling the world about their project, and inviting others to join in
The emphasis for me is on "small", or even interchanging that with "start-up", basically meaning small groups who are more focused on the "doing" than being overly concerned with the actual theme, as long as it looks good and supports their required features/functionality.
I've come up with a bit of an overview of my thoughts so I'll share this here. I'm going to term this "Micro Community Social Networking".
Micro community social networking takes place at the neighborhood, club or group level. Such as a suburb or street, church group or local sports club. Typically they want to engage in discussions, post events and have a calendar and perhaps some documentation (such as club rules). They want to keep each other informed so they have a blog or news and want to post images in most content types and possibly even video.
From a use case like this we can see where we might want to place emphasis in terms of design. We'd want nice calendar and date styling, place emphasis on blog and book pages, and so on. We can probably make some assumptions about image styling and positioning. The designer can build up an idea of what might be important in the design and what the design problems might be.
What we don't want to do is build another very generic design like Bartik - we don't need two of these in core. We need to frame the requirements for designers in terms of both the output of Drupal core and provide a common use case to narrow the scope and provide real design problems.
The challenge I'd like to set here is for you to come with very short one or two sentence use cases. Keep it short and sweet and to the point - these are often more powerful than a lengthy exploration. These should provide many points for expansion and further discussion.
Of course our new theme must be gorgeous and as Dries coined it "a delightful experience". Stunning design is implicit to the goals of the initiative but does not exempt it from the functional requirements of core or a strong use case.
I'd love to hear feedback on my snowman inspired use case - I think it has a lot of merit and would like to hear your comments and discussion.
Comments
The new design should support
The new design should support and style image captions. This would go a long way in improving the out-of-box Drupal experience.
Off topic.
You need to make a feature request to Drupal core, I appreciate your comment but this has nothing to do with what we are discussing here I'm afraid.
Non Profit Organisation/Charity Portal
I think a use case like the following could be another to consider and could see some focus on the aesthetics of the core forums and blogs:
"Non Profit Organisation/Charity Portal"
A small NPO/charity would like to build a presence on the web as a way to advertise themselves to their local community and to be able to showcase their work when bidding on state/government contracts. Being able to schedule events and organise volunteers for weekend workshops and fundraisers would be important as well as building a community site for their "clients" to network with the charity, other clients and the local community. A forum would be one of the main features the NPO/charity would be looking to implement to "stay connected" with the public and also a members area for staff and volunteers.
...
Its a good use case because in raises similar issues to what Lewis is saying below. Personally speaking I have volunteered to build more small NGO site than I care to remember and almost all of them have strong branding, logos and other marketing type material they want to present in the site.
Perhaps including NGO's, NPO's and church groups is expanding our use case too far? Should we leave it more generic such as a "small local group". You're a designer - so if I say to you design me something that is good for small clubs, NPO's and church groups is that going to be more problematic, or even oxymoronic, than say "give me something that has broad use and appeal to small local groups".
Small Town Government/School Portal
Another use case might be a small town government or school that wants to improve its presence on the web.
Such a portal would have a community focus with images, events, document download, contact forms, forums, volunteers, and groups/departments/classes. It also would likely to have a public area and a secure area for getting grades or making payments for permits, fees and/or taxes (thinking need to support http: and https: from default theme).
Many of these entities will not want to develop their own theme (nor will they have the budget!!) and simply will change the CSS text, color, layout parameters to get an attractive web presence. It would be great if D8 made such websites an awesome visual presence by supporting both traditional displays and mobile devices from the same theme.
If we do go for a 'Snowman'
If we do go for a 'Snowman' use case we need to make sure that the final design is equally flexible to allow an organisation to reflect their own branding on it.
Is this something we worry about during this phase or during implementation?
...
I suspect this might be one of the key design problems - how do we make a splash in terms of design, yet provide a generic enough canvas for the sites branding to show through? Perhaps we can't, or at least this will be a very difficult design issue to solve. In some ways I think implementation does come into it - in terms of Color module support (we can't ignore the current requirements for all core themes, which includes Color module support as a requirement, although makes no demands on what parts of the theme should be re-colorable).
Or, are we looking at this wrong - does the strong branding of our design become the organizations branding? A lot of sites were built with Garland which as very strong design and branding, so I wonder if there's an element of truth in this?
How could the branding of
How could the branding of this design become the branding of thousands of other communities? What if this is an offline community already looking for a presence?
No designer in the real world can work with a brief that just has the words 'small community group' in it. We need to present a full fictional account of an actual group. This must include sections like branding, tone, site audience etc.
Maybe we should just construct the fictional group to share the same brand principles as Drupal without actually naming Drupal explicitly. The designer can then interpret this however they want.
I agree that brief is to thin
I agree that brief is to thin and we need more, I'm playing with ideas and questioning conventions, I trust you understand that.
Ok, lets go down this line of using Drupal branding principles, perhaps we can pull ideas out of the redesign docs: https://infrastructure.drupal.org/drupal.org-style-guide/brand.html
***
@jeff I don't think that would be problematic tbh providing color module support is something the design can lean on to take care of the genericity issue this use case could have. I think whatever use case is chosen if the D8DI theme is seen to be favoured over other core themes by a user they will end up re-engineering it to suit there use case which is where color module will help.
Out of interest why did you choose that use case?
...
I started with this use case because it appeals to me as a group who are likely to use a default theme. Another group might be newbie site builders knocking up their first site and to whom a heavily branded theme has strong appeal - an obvious use case and a definite group that does exist. Yet another group are wily old Drupal coders who have a blog and for whatever reason use Garland, perhaps out of loyalty to the brand.
So to answer your question more clearly, I choose this use case because it appeals to me as a strong group who are likely to actually use a core theme, and a group that is rapidly growing as technological barriers fall.
Could this be something we
Could this be something we should discuss further? I mean there are several use cases that won't use this theme for sure that either have the funding or will have the experience/skills to use a base or starter theme or make their own. Should we be thinking of the use case you started the discussion off with plus others that will use this theme because they will lack the resources to start at the bottom of the learning curve or want a quickfix with a polished theme? If thats the case then stronger branding like Garland would be possible but opens up some questions I think with regards to what features/theme settings should be included.
...
Hard for me to comment on this because atm we're heavily restricted in what we're allowed in terms of theme settings or bespoke features (as in we're not allowed ANY). I disagree with this restriction and think we should be able to use Drupal cores full capabilities and add at least some theme settings - its like sitting at the buffet table and being told you can't have the lobster, just because. Additionally I can't help being mindful of Web Services and Context Core Phase 4 - people need to understand the implications that could have on theme building, imagine if suddenly we can have plugins in themes (like layout plugins aka Panels). I'm not sure if that will happen in D8 or at all, but it should be taken as read that I am incredibly cagey about discussing core theme features at this stage in D8 - its just too unknown. In terms of color module features, well the sky is almost the limit, but is very much driven by the demands of the design - so we either dictate certain design requirements to match our super-colorable-theme aspirations or say very little and work with the designs during design phase one on one.
...
The biggest challenge in this kind of hypothetical use case building is getting the right focus on balance between the needs of the 'site builder' and the needs of the 'site owner'.
The practical side of small local groups (or even large groups looking to make a decent presence) is that the site builder is not usually the site owner - in fact the owner will most probably be a committee or a committee member delegated with task of getting it done.
One consideration I've always heard is that they want longevity, and are not thinking about a redesign or rebuild a year on. Being in a financial bracket where it's either got to come free or cheap (probably requesting voluteers), they want something that will meet their needs for the foreseeable future.
One switch I would make in the discussions this far is that it has been focussing on the "needs of the site owner", and this more often than not would refer to features rather than design. A site owner wants a good looking site that does x,y and z, whereas the real design challenge comes after that feature set is established in the question "How does this serve and encourage the users/members/prospectives?".
That may seem a bit off-topic, but it's more on than off. We already have the feature set - or projects like Snowman will inform us better what they could be. This is where the groups site-builder would be looking for a solution that can do the x,y,z but also not look like a 90's geocities site. The onus is then on the site builder to learn a bit about which CMS they want to use and find a suitable theme.
To use a broad assumption, I think something like.. http://demo.woothemes.com/?name=simplicity would get used a lot for this type of site builder, but it's not a visually "stunning" design, but that would be it's appeal.
Dreamleaf Media
...
Snowman doesn't actually do a good job of defining feature sets because its restrained by the core only requirement, which is good for Snowman but not true for us, really Snowman is about finding "gaps in core" for the common use case. What I have done is use, mainly by coincidence, a similar use case as a starting point to question who might actually use our core themes.
theme should lead site builder
Totally agree with dreamleaf here. The design should be clean, nice, modern and neutral enough, without those huge parts of contrast colored backgrounds as in Blumarine/Garland or even Bartik. This way it will fit majority of (at least beginner) applications, doesn't matter if it's NGO or a small local business.
Also, the theme should lead site builder to create visually appealing site but not "color module: my eyes hurt" designs which we all seen with Garland.
After all good design can make the average site better but average design may kill good site (content).
Cheers,
Andrey
Free and Premium Drupal Themes | Drupal Sites Showcase. Add yours! | My Blog
my eyes, my eyes!
LOL, yeah, we don't want to go there again... he he.
What I like about that theme is the attention to detail and the overall clean modern style, Bartik is kind of clunky by comparison. Of couse you can create a neutral color scheme in bartik with color module and it has some of the same page style concepts - 100% header, footer, features region sort of thing. So for me when we look at the woothemes simplicity design I notice attention to details which is certainly one thing I will be looking for.
One of the main things that
One of the main things that makes a theme successful is the ability for the site owner to tweak it without any industry knowledge. The success of tumblr is a good example of this. All themes are customisable.
A design doesn't have to strictly obey this principle but it should definitely be a consideration when we choose which theme should be included in core.
...
Indeed, but I guess the approach should be exactly opposite: introduce to relatively calm, neutral colors but then give a hint how one can spice it up if you wish with color module or whatever.
Talking about core theme: we could use (now) larger screenshot to fit there a few color variations (can't find sample, but many theme shops would do that). Other idea is to include a link in theme description to theme documentation page on d.o. with samples of what you can do. But this page should be there before release of course.
Do we have some ability to include local help in themes btw?
Cheers,
Andrey
Free and Premium Drupal Themes | Drupal Sites Showcase. Add yours! | My Blog
...
hook_help - I have tried this in D7 theme and couldn't get it to work so I assume this is limited to modules, which is interesting in that we should probably be able to declare it in themes. Great idea!
Its very hard to get some
Its very hard to get some decant info from designers who went creating own theme before learning the basics of Drupal.
What I noticed is that a) not so many people use core theme b) most of them are blogs from individuals. So my case would be:
Individuals starting with Drupal as a publishing platform. Instead of visual design they put the content in the first place. They mostly publish short posts (blog post) where most of the content is text based.
I don't see organized group as the site builders, I see them more like the client in the projects like it was pointed out before.
If we are talking about new themes for Drupal 8 I would definitely like to see different theme for each case - micro community, blog and brochure site (for companies or organization).
--
Drupal Themer & Web designer
site owners vs. site developers
I think the core theme needs to support users who are not developers. Developers will make their own themes. I think the focus here should be either on the newbie Drupal user or the person who may be familiar with managing a Drupal website but doesn't have the knowledge required to customize a theme. This approach could help bring people into the Drupal fold.
+1
+1 to this idea! Whatever use case we choose should assume that users have limited knowledge of Drupal.
@dcmouyard on Twitter
Just to note, you may want to
Just to note, you may want to cross-post this discussion to the Web Managers / Content Editors group.
Also, you may want to take a look at the Snowman project for Drupal 8.
...
I don't really see how content editors and web managers group bears much relevance here - this group is highly unlikely to have any decision making power with regards to the sites design or which theme it uses - in some specific instances they may be a stakeholder, however in that case they are likely wearing more than one hat and make those decisions as site owner/developer or other such role.
Snowman is discussed in the OP.
Content editors and web managers use the design
I'd say that content editors and web managers bear a lot of relevance. A smooth content editing experience could be a really important UI/UX goal, and there's plenty of good work out there (like workbench) that are addressing these issues.
For what it's worth, some of us know
I think Jeff's right, in that the discussion here isn't of sufficient interest to the Web Content Managers / Editors Group to make this a cross-post, but rest assured that some of us are at least following this thread.
That said, I think that group might make a good source of folks to test things with. It isn't just for folks who sit in the content-production workflow of a site. It's for people whose background in website development is from the content production side. So they know how to coordinate the content of and determine the features needed for a site, and some of them are producing one or more new sites in Drupal. Of course they want each site to have an interesting and attractive appearance, but their minimal backgrounds in design hold them back from achieving that goal.
And every site they create ends up looking like every other site they've created, but they would like to get out of that rut.
Jeff, isn't that one kind of person you're hoping to help?
Hard to make assumptions
Hi Cliff,
Just to make a point that assumptions are hard to make, I was hired/employed as Web & Design Manager, and am a designer (wanting to learn theming, however not a programmer/developer). So, I'm a web manager who is also a designer, though not developer.
I'm following these discussions, too. My question is whether the idea is to create one base theme? I would think that Bartik will continue into D8, so not reinventing the wheel, other structural choices would be worth exploring. I'd also take a look at what's being done with DrupalGardens, again structurally. There are several starter themes, with different regions, different takes on backgrounds, etc. Acquia designers might be willing to provide some insight into who uses/chooses which base theme. Might be worth asking their thoughts.
Best, Marilyn
Talking to Acquia is
Talking to Acquia is certainly on my todo list especially touching base with Jeff Noyes if possible, hes a busy guy! Right now we have solid thoughts on the actual features/code for the theme and are pretty focused on the design aspect, we expect the theme feature related discussions to heat up around July and start narrowing in what people want and what will be best for core.
Bartik will have some changes in D8 but not in style, more the underlying code assumptions will change since we need to think about mobile devices a lot more than we did in D7.
Design not theme layer featues
This might be interesting if this tread were about theming, but its actually about design. You seem to be struggling to separate these as discrete disciplines and in many of your other comments I see the same issue - try to separate the design aspect from the technical aspect - features we can deliver with code (by and large a trivial exercise in Drupal), the more complex issue here is where to focus the designers attention - to narrow the use case for them so they can clearly visualize the design problems and objectives.
Will they? You assume they know how, have the time or actually care. Sure some will, but not all.
Theming
Just spotted this thread.
My team has done a few hundred themes for customers over the past few years. Note that we're not designers - typically we're being handed either an Illustrator or PSD file (sometimes html - which we usually have to completely rebuild) - and we then turn that into a Drupal theme. The kinds of work my team is getting are cases where the final site cannot look (anything at all) like Garland. This is obviously a very different use case from somebody who just wants a blog, and will fiddle a bit with the colors and layout. Some of the themes we are building a very complex, with hundreds of tpl files, dynamically generated content etc.
We're typically using the Blueprint theme as a basis for our work, because otherwise there's just too much effort involved in ripping things out in order to complete the theme. This allows us (with a bunch of cutting and pasting) to generally use our own html (interspersed with Drupal "stuff") to build out the theme.
We often run into the following issues:
1) Too much default css that we need to overwrite
2) Too much html markup in the theme itself that doesn't match what we're trying to accomplish
3) Too much html markup hardcoded into modules (including occasional inline css)
4) Difficulty theming certain Drupal elements without useful selectors
In addition, there's a couple of performance and usability related issues that we run into, along the lines of css selector chains that are very long (i.e. see Google SpeedTest).
I think the general gist is that designers are really looking for a very simple base theme that has as few visual precursors as possible, so that it is easy to just drop in a bunch of html markup and css without hunting for oddball things that poke through from behind the curtain.
Just in response to the CSS
Just in response to the CSS issue, currently the only option is to unset the individual CSS files in your template.php file (or a custom module). The default CSS is definitely a bit overbearing and I think some people are hopeful that we can remove default CSS from core (except to place it in the core themes). Not sure how many people support this or not though.
*** sorry if this is a bit off topic, I don't want to hijack the thread ***
Use cases
I'm working on a project called Townsquare which intends to cover a couple of critical use cases for our organization, which might be interesting to this discussion.
I think the first three are fairly amenable to "general purpose" design. In particular, a community wiki and calendar is a very compelling use case -- imagine a community run, searchable database of all kinds of knowledge and events (the maturity of fields means you can add on all kinds of tagging, tracking, geotagging, etc, as you need). It also seems like these use cases can be handled without resorting to contributed modules, which could keep the scope in check and keep the process away from messy discussions about features and configuration.
For me the "town square"
For me the "town square" concept (I am assuming this akin a micro community or neighborhood collective) is a compelling use case - I'll checkout the code and take a look. Thank-you for sharing!
Sadly, the wrong part is the most mature
Definitely akin to a micro-community, though the emphasis is on local knowledge and conversation rather than social networking per se (Facebook and Twitter are for finding and communicating with friends, but they don't scale down very well).
Sadly, the most mature code is in the volunteer manager, whereas I think a slick wiki + slick conversations are the more general use case.
Very interesting project,
Very interesting project, sounds somewhat similar to Drupal Commons (which was developed for business-oriented social networks), but Townsquare is not based on Organic Groups, correct?
Best, Marilyn
Similar to Drupal Commons and Open Atrium
Marylin, you're exactly right that technologically and conceptually, Townsquare shares a lot in common with Drupal Commons as well as Open Atrium.
Townsquare will likely adopt Organic Groups to handle our small teams, but our development agenda is driven by our organizational pain points. Our spreadsheet stopped being an effective way to track volunteers late last year, so that gets replaced first. Our wiki is really frustrating, so that's next. Both of those are close to being decent. Eventually, we'd like to replace our Google Groups with something based on Organic Groups, but that's probably not until the late summer or fall. For the time being, role-based access to content will be sufficient for defining a "group".
I'm working on a similar suite of software (called E-Center) for the US Department of Energy, only significantly more specialized. Townsquare will use E-Center's editing system, but nothing else.
Townsquare will be significantly less complex than similar solutions because our audience is by and large the working poor: many volunteers are poorly educated (significant illiteracy and innumeracy), most use some combination of smartphones, netbooks, and craptops to use the 'net, and many do not speak english as their first language. Making it dead simple, accessible on a wide of variety of devices, and multilingual are key goals.
Do keep us in the loop as you
Do keep us in the loop as you progress with Townsquare. Keeping it simple for your audience should mean it would work well for a general audience.
You might also check out Eventslots which is being developed to work with Commons. It's will be for organizing volunteers for events, so probably wouldn't work for you, however might be worth a look.
Best, Marilyn
Thanks for the tip
I will reach out to the Eventslots developer -- our feature sets are orthogonal and complementary. Sweet, thanks so much.
The reason the 'micro
The reason the 'micro community social network' idea is good is because that 20-person community group will eventually become the 10-employee non-profit with a 5000-address mailing list.
So: Design for that 10-employee non-profit. Then be sure and announce that the new Drupal 8 theme is designed for small organizations. Ideally this would be alongside an announcement that Drupal 8 has some number of features designed especially to help small organizations.
I think Drupal core does have
I think Drupal core does have some compelling tools and features for small community sites, whats needed is a clear way to glue them all together to make a cohesive website - afaict that is what Snowman is all about, however if that doesn't fly in D8 then we need to think about a distro coming on top of both D7 and D8 for this purpose.
I agree with you, Jeff
I've been asking myself how would this discussion help us design a core theme, when we're talking features and tools, which are module-driven, whether core or contrib. I watched the development of core themes for D7 from afar, and saw one that got close but wasn't accepted, and watched the process itself strip down the actual design to the bare minimum, imho.
With small-core seeming to gain momentum, Design4Drupal seems to have little functionality to work with.
Something that might help (since much of Drupal theming is based on page elements and views) is defining which elements need design consideration. Views isn't yet in core, so theming views wouldn't be included, correct? The base question is what functionality will core contain in D8? Which I don't think can be answered today. Please correct me if I'm making incorrect statements.
I'd personally love to see a system similar to the Theme Builder in Drupal Gardens. That would make theming much more intuitive, allowing non-programmer designers to develop themes more easily, and would certainly draw designers towards Drupal. I'm considering developing themes in Gardens then downloading them for use in D7 projects not in Drupal Gardens. I'm also learning to theme, but it's pretty slow going.
As initiative lead, could you discuss this with Acquia? They are doing wonders with Drupal Gardens and donating the work back to Drupal. Such as the work they did to develop the D7 version of webform for Drupal Gardens, and then release it to the community as a whole.
Best, Marilyn
Well, adding a theme builder
Well, adding a theme builder to core is not really in the scope of the initiative. I don't think I'd really be able to "sell" this as an essential core feature, even though I actually disagree about the "small core" mentality. What I see evolving is more mature approach to the framework vs product discussions. Clearly Drupal will really begin to mature as a framework in Drupal 8 (Configuration Management and Context Core initiatives), whats needed IMO is a better install profile that actually does something (aka Snowman) so we have a usable product that ships with core.
I don't want to go off-topic,
I don't want to go off-topic, Jeff, so thanks for pulling the discussion back to the point. I guess I need to read more about Snowman. Would it be one, or more than one installation profile? I'll check it out.
Best, Marilyn
Should we focus only small, or large sites?
Before we go too far down the path of focusing only small sites, new sitebuilders, etc. I wanted to at least bring up a different question, so it can be considered.
Dries said in a fairly recent blog post that he felt that we spend too much time comparing/worrying/etc. ourselves with Wordpress when Drupal actually competes with SDL Tridion, Vignette, Sitecore and Polopoly and other open source software including Typo3 and ezPublish, at least in Europe. It definitely competes with some of the same companies in the US.
So, should we only concern ourselves with design for small groups, individuals, etc.? Some of the large companies that investigate Drupal are apparently turned off by basic-looking themes, at least that's what is being said about the base theme for Drupal Commons. I'm not sure, so wanted to ask now, rather than later.
Best, Marilyn
I have been looking at many
I have been looking at many of our competing systems and to be fair most have pretty dull default themes - Bartik stacks up quite well, and all plans coming to fruition, we'll blow the socks of all of them with our new core theme in D8.
I think you are making the assumption that design for small groups et al = a basic looking theme. That does not need to be the case - what it needs to do is embrace a set of values that make application of the design to a broad set of use cases possible. This does not demand a particular aesthetic - its the designers challenge to incorporate these values AND make our new theme beautiful - not easy, but if this were easy then it wouldn't be a core initiative and I wouldn't need to be doing this :)
Large companies
From what I've seen in large corporations, when it comes to design and theming, branding and marketing are the primary drivers in making that decision. If they have decided on making the investment in the Drupal platform, these organizations will usually devote the resources to build their own theme. I tend to believe that a core Drupal theme should address the needs of site builders who do not have time or resources to create a functional and accessible theme.
Yes, large companies would build their own themes
Jim, I'm glad you brought up this point. You are absolutely right: Large companies won't be expecting Drupal to produce their branding on its own; they'll simply expect it to provide the tools with which they can produce their branding themselves.
I've been wondering just how we can give site builders who are on their own the support they need to adapt a basic theme to their needs. After all, their customers will want more than just another BlueMarine site, except in an incredibly unique shade of purple.
Sometimes I wonder if what we need is a video demonstrating how to use one of the tools that will help you pick theme colors from a photo, and then how to decide which of those colors should be a background, which should be a foreground, what backgrounds should be paired with which foregrounds, and what color combinations should be allocated to which regions of a template.
The trick to making that work is to get the customer to give you a photo or two that triggers the response (or "feel") they're looking for. When you sample the colors from that photo, you're almost guaranteed to come up with at least one combination that they will like. Or at least that's what a successful designer told me.
So is it a new theme we need? Or is it better support to help us geeks use a theme and get the results we need to satisfy our customers? Or both?
I tend to believe that a core
Pretty much nailed it in a nutshell - this is the goal of the Design Initiative, to put good design in the hands of the site builders who do not have the funds or resources to purchase bespoke design and theme services.
There are lots of resources out there on the web - basic theme building guides, color wheels, color scheme libraries etc etc. What I think we should do is make a few videos to show people how to use Color Module (our new theme will almost certainly support Color module as does Bartik). I know its a bit early to be thinking about "features" in our new theme but I would really like to see more theme settings to allow site builders to tweak stuff without having to touch a line of code.
in general, a core theme is
in general, a core theme is considered as a reliable and a bug-free theme, truely speaking but they are generally "not-that-beautiful", so this initiative is appreciated as good-news for august 2013,
first of all a core theme must be as-customizable-as-possible, in terms of visual elements, say color wheels, as well as in terms of module positions, as many positions as possible and wherever possible these must be collapsible too, and most important of all it must and definitely must have an out-of-the-box, working and easily configurable dropdown menu, and (whether superfish will be included in the core or not) just can't emphasize enough how indispensible this matter is
with such a userfriendly core theme, drupal will be "double-drupal" :-)