Add new theme to Drupal 8.1.x or another minor version

Subs.

Sub.

I was having a discussion last night and thought of the following line that to me would some up what the brief should hope to gain from the finished theme:

"The design should be one you can't find on d.o"

The meaning behind this is to have a design that brings something new, something fresh to the available themes in core and would carry well over the period that the theme would stay in core. I personally would be looking to design a theme that brought the direction from the keynotes at DC into perspective especially the "any device" idea. I think media queries have been proposed in another discussion which would be great and would be a possible second point for the brief:

"Provide concepts for a range of devices"

As these are just a couple of thoughts I had if I was to write the brief I want to keep this relatively short. My third point would be aimed at keeping a set of clear objectives. For example what use type should the theme be directed at? What would be the minimum regions? If the idea is to have a minimal theme is that perceived as being minimal in design or minimal in features?

sub

Sure, I'd be glad to remove Garland. I do not understand what process you propose, even the group D4DC process says "Choose the next theme based on the design (before the theme is built)." - does this mean its purely a aesthetic discussion? If so, how do we want to facilitate this - because I know, those kind of discussions are really hard.

Regarding the brief, to what extend are you opening this for discussion? As it seems pretty confined, nonetheless I am not sure if we want another minimal theme in core. I love it, you love it. But our audience is bigger, and Garland appeals to an audience that wants a visually heavy theme. If we remove that ability from core, we need to be aware of the consequences in audiences that we reach from the initial get-go.

subscribing

+1 :)

We absolutely need to add a new theme with Drupal 8. Garland attracted lots people to Drupal at the time, a fresh new theme would do the same for Drupal 8. People will try out Drupal because it looks pretty. The big question is how do we go about it so we don't end up having to make a last minute decision like in Drupal 7. I think I've read somewhere before that we don't want to do something like a design contest but we should have at least a call to action for designers to propose designs. This could be done all within drupal.org I guess.

I like the idea of having a visually heavy theme, but we should CSS whenever possible instead of images for better front-end performance.

Subs.

Actually, may I suggest using a module like Style Guide To demonstrate the theme?

The problem is, this could easily get too subjective too quickly if we just focus on which theme 'looks nicest'.

We need a clear objective for this theme Jeff. Something we can assess the effectiveness of each design solution against. I'm completely new to core development but maybe the objective of the current included themes need to be outlined so see what is missing.

The problem with having a 'visually heavy' theme is that it narrows the use case rapidly.

I see Bartik as a modern visual equivilant of Garland. On the early Drupal 7 sites I've seen it is fufilling the same roles as Garland. Garland was mainly used by Drupal developers for personal sites in personal experience.

Bartik is great for maintaining the Drupal brand and 'flying the flag' but for new experimental 'design focused' Drupal users something less patriotic and minimal could go very far. I'm going to point to Wordpress and Tumblr for examples.

I'm going to solidify a solid proposal in a write up either tonight or tomorrow.

@lewisnyman - Did you put together your proposal? I'm interested to see what you've come up with.

I've decided it's better to start at a very high level. I've written a set of design principles that the design brief should take into account. Hopefully coming to some kind of consensus on these principles will increase the likelyhood of coming to a consensus on the whole brief.

The google doc is open to be edited here: https://docs.google.com/document/d/1pH9o6FEUAnzZhdlPahB7sAYThvdOuMXSR4jA...

Principles

It’s worth setting out some assumptions about what a ‘good design’ is for a Drupal Theme from an objective stand point. If there is any disagreement on this proposal hopefully it will start here.

Good design is not a pretty picture.

Designing a website is more then just how it looks. It’s how it the user interacts with the pages, how they navigate between pages and how this feels.

Good design is contextual.

All real life problems have constraints, whether they are financial or technological. This one is no different. A successful theme design should take into account the context.

It should take advantage of Drupal’s core functionality while taking into account Drupal’s restraints as a CMS.

No additional plugins or libraries should be required to implement the design outside of the ones included in core.

Good design is technical.

A design candidate should take into account how it will be implemented on the using modern web standards. A design candidate should be aware of accessibility and usability on the web.

See: Designing Accessibility Into Themes

Good design is flexible.

A design for a CMS is not the same as a design for a static website, the design solution should be as flexible as the content is. It should also take Drupal’s global theme settings into account, how will the theme reflect changes to the site title, logo or mission statement? How will the theme look if the these values do not exist at all?

As well as adjusting to fit internal context, a design candidate must respond to external context. It should take into account the capabilities and context of the device it is being displayed on.

See: Responsive Web Design, Networked Consumer Device Platform

Good design is unobtrusive.

A good design candidate should not forget who this theme is for. A good design should complement the content, stay modest and not distract the user.

No one seems to be very active here. Maybe that's a sign everyone is content ;-) either was I'll piush ahead with a full on proposal soon.

Saw this today, Cameron Moll has just produced an excellent example of a theme design that is minimal yet still has a lot of character.
http://cameronmoll.tumblr.com/post/4366534284/coming-soon-brief-a-woothe...

The initiative doesn't start until mid April so I'd take that as the reason this thread isn't as active. The principles are a good start as a general reference, discussions need to take place around your proposal ideas and the topics Jeff has outlined in the OP like visual treament etc as they will all need to intergrate.

The style of design is something that definately needs discussing as people are saying minimal whilst others are disagreeing with another minimal theme, if the idea is to have a design that is an advert for Drupal 8 in my opinion this is the talking point for the initiative and what Jeff has said above is what I agree with. We need to move forward design wise and look at possible styles that have not been tried before in Drupal or at least have an emphasis on making Drupal look different to the previous version.

What about creating a theme based on grids like the Less Framework which automatically detects the browser type and resolution to optimize the layout. I'd prefer this rather than a fluid-width-theme.

(Have a look at this: sandbox project | demo site)

Just an idea.. :-)

Good design is good Branding

What we have certainly learned from Garland is the branding effect it had on Drupal. When a newbie installed Drupal, Garland = Drupal.
When people compare theming Drupal and theming Wordpress, they look at garland to judge the theming engine.

Allthough Garland was nice and novel when it came out, the branding effects of it now are mostly bad associations. Garland now makes your site look outdated, flashy and awkward. We need to form our goals in terms of branding associations that we effect to get from the new core theme. The design of the theme will determine peoples 'view' of Drupal.

I think one of the aspects where Drupal needs help is to be branded as 'Designer Friendly' - which is IMHO quiet easy. Make sure the design is done professionaly: in the sense of being designed by a professional designer, not a professional programmer...

But of course this is not the only branding effect a (default) core theme has on Drupal, I suggest we add to the briefing a set of desired primary brand associations. I'm talking about dimensions like formal versus playful, active versus passive, classy versus modern.

If we want the Drupal brand to remain competitive against the other brands we have to think about marketing because it's people's perceptions of Drupal that determine which systems make it through the cut. Other CMS are investing in shaping and building their external communication so we have to keep up and think about marketing. It should be clear in the brief what direction we, as a community, want to take the Drupal brand. If we start a design round without outlining this type of art direction we might not get the desired result.

subscribe

sub

Whilst outside the scope of this specific project, one resulting consequence is that only one design can be chosen, themed and showcased. It would be good if as a side project but equally important there was a decent mechanism within the Drupal ecosphere for designers to be able to submit their work and get access to a good calibre of willing and competent themers.

Jeff's post HERE alludes to something along these lines, but I feel that if getting the level of design boosted within the community is really a priority, then designers should have equal opportunities and tools to be able to contribute - right here. It's possible this is all part of the plan that will be unveiled soon, but thought I'd throw it out there just in case :D

sub

Subscribing. I feel I could help here ;)

This sounds great! I'm all for having a theme out-the-box which really shows off Drupal. There's so many different directions the theme could go, but I would agree that setting a solid target is the best way to go - maybe the discussion will inspire more contrib themes to be spawned.

Some of my initial thoughts of things to think about are: A grid system, CSS3 / HTML5, mobile browsing - which is set to overtake desktop browsing in the next few years.

subscribe

Much of the discussion above seems to be geared toward the display of HTML to the PC/laptop and I agree that a new large display/mouse/keyboard/screen reader theme makes sense. However, I also think that D8 should ship a new theme designed from the ground up for mobile devices. This is one area where Drupal 8 can really shine by leading the way on what creative stuff can be done on iPhone and Android devices using auto-sensing techniques. We also might want to focus on optimizing the amount transmitted back and forth to the mobile device.

subscribe

Subs.

sub

subscribing

Jeff asks

First we need to develop a clear design brief:

• What do we want the next theme to achieve?
• What might the visual treatment be?
• What features will our new theme support?

This is probably the only contribution I can make to this process, but I remember a post on Drupal Planet a while ago in which a decent drupal shop posted a checklist/template of the major theme elements that they always made sure their theme styled... there are so many it's easy to overlook things, when even a small treatment would make a site look more harmonious.

I think it would be a useful to come up with a list of elements the theme must support, and that the third gate the design must pass should be support for all those elements.

Fusion have a list here: http://fusiondrupalthemes.com/support/theme-developers/designing-fusion/...

And cmsquickstart http://www.cmsquickstart.com/blog/drupal-theme-design-process-and-checkl...

I can't find anything similar in the theming handbook but http://drupal.org/project/styleguide seems to be helpful.

I think a canonical list, perhaps prioritised (so headings are top tier, but the maintenance page might be lower) would be invaluable for this initiative and much else.

There is also the "design" module which goes in the same way as styleguide: http://drupal.org/project/design

In my dream this theme should be done with sass/compass but these tools shouldn't be required. When the theme is released sass files would be compiled to css. It would then offer a lot of flexibility and demonstrate some sort of best practice.

I think Less / Sass / Compass are all great tools but I think a core Drupal theme should be an example in how a theme should be made and executed with only the core tools shipped with Drupal. So if peMaybe tools like this would be useful when prototyping the design, but the final theme I think should be written in plain, well formed CSS.

I also think it would be easier for people to contribute to the theme without using any additional libraries.

subscribe

Sub.

I am very interested in this initiative. I have long been disappointed by Drupal's theme designs (I often scrap everything and start from the .info file rather than use a default theme or a "starter"). I think it's great that design and user experience have become more important as Drupal has moved from 6 to 7 and now looking toward 8. I'm no Jen Simmons, but I have built up a bit of experience building front-ends with Drupal. Hopefully I can contribute something positive here.

It will be really helpful if the new theme makes everything as a variable that can be put anywhere in the page as wished. While this may be attainable by Contemplate etc it will be really nice if we have every and each thing churned out by core and modules have a variable output for example:

$comment, $commentauthor, $commenttime

Thus comments canbe shown both below a node and by the side of a node if wished.
Also a delimiter for the number of objects eg. $comment, n=5 can show all comments below a node and 5 by the side. And a delimiter for long words, eg $subject, $subectwordlimit_for_title=100 can make the theme non-breaking in certain situations.

Hovering on a special output of any page will show what $variable is that displayed text or image and this can this be easily modified then.

The essence is that anyone can very easily shape her site in this way. CSS and other tpl stuffs can follow.

One of the tricky aspects of developing a design for a drupal theme is that it's going to need to demonstrate the kind of flexibility that yeti22 is talking about. People are not going to be able to submit simple, single file mockups. A theme doesn't require just a design; a theme represents a visual system (or visual language, if that helps) that defines the output of all the various ui widgets Drupal needs.

This is why I think that some sort of open contest-thats-not-called-a-contest for a core theme design is not the best approach. Get a team together that can work this problem and create one (or perhaps a few) designs that the community at large can review and comment on.

I know people within Drupal (and the wider no-spec) world, really hate the idea of contests. But the more I think about it, the more it would seem sensible to actually brand the selection process this way. Drupal is not only selling itself as a product in the market place, it's selling the ideal that Open Source actually works as a business model as well.

I totally agree that the core theme should be selected "by committee", and the vote up or down seems the most logical way to police this - as long as the system is prevented from abuse, and it's not really the designer with the most number of twitter followers behind them rigging the voting....

What I wouldn't like to see is a closed system, whereby at the end of the whole process the unsatisfied many appear complaining that the process wasn't open and how they wished it would have been done with more community involvement.

Lots of idea generation and solutions need to be found, but I can imagine the "selection/contest" starting with a generic but well briefed idea, that is then fleshed out and progressed with all the Drupal gubbins by the designer + theme team + accessibility bods + others. So all in all as the process gets more refined, so does the workforce.

(also seeing as it's easter, I knocked up a witty little egg poster for the non-contest - see attachment)

very open, collaborative process with full community involvement. -- design by community is going to work for sure. You will get stuff like "formal versus playful, active versus passive, classy versus modern" versus an old curmudgeon like me who reads that and finds it particularly like the musings of wine tasters who invent their fancy dictionary to describe things noone else can feel (in case, see) and pretty much try to dictate.

Don't fall for that. Architecturing / design needs to be done by a few, with a firm hand of one to decide with of course input from others but not a full community involvement.

In anticipation of people submitting lots of ideas for the design brief, I've taken the liberty to create a book page in the Design Initiative section.

This can be found here -> http://drupal.org/node/1137000

If no-one gets to it first, I'll update (later today) with sections from this thread and other references so that all the ideas are collected in the same place - that should make it easier to chop down to a managable document.

@49 "you're talking about fundamental overhaul of Drupal's theming system which is not within our scope"
Hi Jeff
I am not speaking about Drupal 7 which I have not much experience. But if Drupal 8 will not overhaul itself, when it will? Most sites still use Drupal 5 and 6, so 8 is a long way and the best viable option to overhaul anything.

Theme, irrespective of what it visually is, should be very easy to manipulate. For example, if I want something like the follwoing I cannot do it Drupal 6, a serious restriction

<table><tr><td>$content /*meaning $node_body*/
<br/>$comment_submission_form
<br/> $comments, [comments, show=all] </td>
<td> $comment_author_pix [comments, show=5, link_more=yes] </td>
</tr>
</table>

If this sort of "easy"ness is not provided whatever is done will be basically the same sort of problematic as it is now for end user web masters like us and it will be basically a very rigid theme. Most of us, when we discuss in chat or other forums, we feel we need this from a CMS instead of any geeky things or verbose UX things. Once the theme lends us this flexibility we or even any ordinary wordpress-type blogger can decide what UX suits best his audience. As far as I heard WP, Joomla and Plone is going to have this soon, if not already.

So far as UX functionality, I will request to take a hard look at facebook, since almost all "users" are used to it and see how easy or intuitive they have made to add a text or more prominently a photo.

Yeti:

Your suggestions are about overhauling the theming system. This issue (and Jeff's role) is about helping the community create a new theme(s) and an excellent user experience for Drupal 8. Your suggestions are totally valid and you are correct that the right time & place to make that sort of change is while D8 is in its planning stages. You should open a separate issue though and be clear that you are suggesting improvements to the theming system (not to a specific theme). If people in the community like your ideas they will comment on that issue and you (and/or others) can start writing some code to make it happen. If the community is not in favor of your idea I would suggest you create a custom "base" theme of your own in which you can implement some of these ideas.

Now ... back to discussing new themes, how they're born, who should design them and what can we all do to make them rock...

@56 Apologies for jumping the gun, just thought it would be helpful for everyone to have a collation of the ideas raised to save having to scroll through issues 100's of post long searching for references. I didn't intend it to be the final brief, or even a first draft of a brief.

Regarding #57 point #3, I sense that this new theme will be geared to relatively larger screens of the desktop and laptop. Does it make more sense to make this new theme geared toward the mobile device (smartphone/tablet etc) and then only more traditional screen capable?

I fear that mobile device support will be a secondary focus/after-thought where, by the point that D8 is in wide use, most of the devices accessing Drupal data will be of the mobile variety. Somewhere I read recently that mobile device sales are already exceeding those of laptops. This trend is highly likely to continue. I think this is another great place for Drupal to lead.

@Lars - Yes (I mentioned in an earlier post), smartphone's are set to overtake desktop & laptop's internet browsing usage in the next few years. I think it would be great to have a new core theme which is up to date with technology (and maybe it could even lead the way).

I'm no expert on web development for smartphones but I've noticed a trend that websites seem to re-direct to a mobile version, I'd imagine doing this would be beyond the scope of this theme. Maybe a solution would be to include a subtheme for mobile devices? Maybe Drupal 8 will include the ability to automatically display a subtheme to users using a smartphone...

To answer the three questions:
1. What do we want the next theme to achieve?
It should make thousands of people not want or need to switch from this theme.

2. What might the visual treatment be?
It think it should look kick-ass but be kept fairly simple

3. What features will our new theme support?
In terms of adding new features, I think this really depends on what Drupal 8 will support - I don't see it as a core theme's place to add new feature but more to showcase the great things Drupal can do already.

@Jeff:
Design by community is a terrible idea. As a designer, I've seen this process fail spectacularly. I fully support an open process where the community at large has a chance to supply their input, inspiration, ideas, concerns, etc. I do believe that the responsibility for producing the design(s) needs to be assigned. I don't see what is closed about this idea.

To get back to the core theme discussion:

1. Clearly the theme should showcase the Core Drupal features. I also think the theme needs to have great flexibility -- and not just the responsive web design kind of flexibility. The end user should have many options for customizing the application of the theme.
2. Visual treatment and branding. Branding Drupal with the core theme is an interesting idea and adds another dimension to the development of a theme design.
3. Ideally, the theme would support a lot of features that relate to flexibility. I'm thinking about color scheme, typeface, position of user interface widgets, element styling (think a switch to turn on and off rounded block corners). I'm not exactly sure how far discussion of features gets us in talking about the design... is that not more of a theme development question?

Specifically regarding development for mobile:

You can do this with CSS. Simon Collison's website is (I think) a great example of how this is well done. And there are other wonderful examples. Happy Cog's recent-ish "Cognition" blog also has a nice responsive design.

It could also be done by providing some kind of administrative interface for assigning blocks and other elements dependent on the user's viewing environment. There are currently modules that support various ways to customize the Drupal UI for mobile devices. I imagine some of this functionality could be moved into core for themes.

In a mobile-centric world of smart phones and to some extent tablets, there is limited display space. Hence, there is limited use of multi-column formats and big blocks of text often need <next> or <scroll [direction]> user interaction. As a result, popular page hits tend to have very focused information (text snippets) and very often graphics/images.

Think for a moment of a "localized" "application" (or web page) with location check-in, restaurant review and restaurant reservation sections. Other than the review section which likely will have several paragraphs of a general review and perhaps many comments, most of the application is short text snippets and graphics.

How this application might present its information conceivably might done on one web page if the target was a wide monitor display. However some small portion of the page would need to be displayed on an iPhone.

The above leads me to several thoughts about this new theme (and possibly theming system) requirements:

1) Graphical elements of the theme need to be possibly scaled based upon target [Implies that image manipulation function(s) need to work on graphic images outside the /files directory.]

2) Theme will need to create its display both as directed (through url) and/or auto-sense that for instance this page is to be delivered to an iPhone.

3) Whatever theme is developed is likely to be rather "heavy" to cover the display on a wide variety of devices. This likely will involve rather larger css and js files that need to be downloaded at least once to the display device. As we design for a mobile world, the cost and speed of communication as well as amount of device storage is much more acute than that of the PC or laptop. We will need to investigate whether we should be sending one large css and js file for each page request or just those portions that are needed for the display of that snippet.

4) This in turn leads me to a question about the profiling of CSS selectors. On the laptop display in D7, we currently deliver to the browser every conceivable CSS selector that is defined in enabled modules and themes. I often wonder how many of these are used on a particular page display, Perhaps we should also include some selector profiling as part of this initiative?

5) In my ideal world, after a theme has created the HTML page, there would be a post-theme process would kick off that would identify all of the CSS selectors defined in this particular HTML page and the included js files. It would then extract just those CSS rules from the included CSS files and create a page CSS tmp file. This then would replace the many included CSS files that are included when CSS page aggregation is not enabled.

Lars brings up a good point about CSS for mobile devices. Drupal has MANY CSS files, and most of this style information would not be useful in a mobile viewing environment. There may be a way to specify, using media queries, which CSS files to attach for a particular environment. An administrative interface that allows the enabling/disabling of CSS would be really nice. The same goes for the enabling/disabling of regions based on viewing environment. The more flexible the theme can be, the more useful it will be to potential Drupal users.

There may be a way to specify, using media queries, which CSS files to attach for a particular environment.

CSS already supports the "handheld" media type since CSS2. drupal_add_css already supports aggregation with media types. I can't see the benefit of adding this in an admin interface, surely this functionality is only for module and theme developers?

Let's not digress too much from the topic. There is a Mobile group for these kinds of conversations.

@aaronpinero, Thank you for clarifying my comment.

In writing #63, I very much assume for a mobile device that the new theme will enable the ability to turn off regions like side-bar-1/2 based on the display device. I also would like to conditionally turn-on of a region based on display device. This would allow the use of one type of header/footer blocks on mobile devices and another set for more traditional PCs out of the same theme. This feature of the theme needs to be auto-sensing too.

Let me also stress, we need to deal with Drupal's previous assumptions about CSS/JS that leads to CSS/JS file bloat (which potentially can be reduced to two large files through aggregration). For a mobile centric world, we need to focus on delivering just what CSS is needed and little more.

The Mobile Tools module provides integration with the Context module.

Depending on what happens with the blocks system in Drupal 8 maybe some of this functionality would be worth bringing into core?

Subscribing. Just read the post on Dries homepage and would love to get involved.
But still need to get an overview about the targets & facts.

I guess on very important thing is to keep the "workflow" of agencies & clients in mind.
And that there are different units for different tasks which all needed to be satisfied.
Only in very small companies this relies to one inhouse-unit.

With bigger companies there are coming up bigger & complicated structures:
# content creators / editors
# content lead editors
# design unit frontend
(maybe one inhouse & the external lead agency for the whole company CI, maybe an extra one for social media and one for online-design issues)

# template developer frontend (Graphics & CSS with no Server-File-Access e.g. via FTP)
# template developer frontend / backend (with Server-File-Access e.g. via FTP)

I just made a project in a very huge "traditional" company here in germany, who are now trying to make International eCommerce and there it was really really complicated just to get an account for a networkdrive.

And one conclusion is: just to see how a button replacement changes all they needed tons of new photoshop-screendesigns (I use Fireworks for webdesign !!!!) to could decide yes/no.

That in short and I hope I can dive deeper into all by thursday.

All the best,
mori
-------------------------------------------------------------------------------
PS: for the customer the interface is the product (J. Raskin)

@Jeff in #65 - Perhaps it makes sense to open a new issue summarizing new theme system requirements for the new Drupal 8 theme? Each of the items listed there then could be opened up in an issue so the appropriate patch gets into D8 and possibly back-ported to D7. By doing so, we can get focus on Drupal system requirements separate from the implementation of the new Drupal 8 theme.

I can suggest some items to go on that system requirements list. However, I am sure that you have many more. My suggestions would include:

• Allow for dynamic enabling/disabling of blocks and theme sections.
• Implement core concept of display context for HTMLx output.
• Allow core image manipulation functions to work on images in theme directories (as well as /files directories).
• Address issue of minimal CSS selector files.

I guess the upshot of the last 10 posts or so is that a design for a new core theme will have to demonstrate (visually) what the theme will look like in various contexts which will be more clearly defined in the upcoming Design Brief?

To me, a solid core theme is one that sets an example in terms of best-practices and coding standards. it is a beautiful theme but in the same time very flexible so it can be easily modified - the biggest problem Garland had was that you could use it as is (sure, you could color it) but if you wanted something a bit different you were better off using something else as a starting point, the result was "the Garland/Drupal look" or something completely different, Bartik do this much better - just as a POC I used Bartik as a base theme for a gallery (nogaart.co.cc) that didn't had anything to do (visually) with what Bartik was originally, it worked beautifully.
We want people to like the theme visually, but also like working with it as a starting point for their modifications without limiting their possibilities or their creativity.
Don't get me wrong, I'm not saying this should be a starter (AT/Fusion/Zen style) theme, It *must* be beautifull out-of-the-box and cover all of core's styles needs, but it also should be so well constructed and easily customizable that we will also enjoy working with it as a base, to cover all the overrides we *don't* want to bother doing in our modified theme.

I think we're talking about adding at least one theme really. Unless we're just renaming Seven to Eight, it seems like we're going to have to rethink the admin interface a bit. There are basic color contrast issues with Seven that we weren't able to address which will need to be fixed in D8 too. I think there's more we can learn from other admin themes through the D7 process too. What are the best practices of admin themes like http://drupal.org/project/admin & http://drupal.org/project/rootcandy

We have Stark, why not add a starter theme too? Something that gives themers something to start working from in building sub-themes from core.

It would be great to have a nice flashy theme to replace Bartik. Bartik's going to start looking pretty old in 2 years time. I think it should still be in core, but just like Garland, it should be the default which we phase out of core after it's served it's time.

Design-wise: a showcase theme should probably be generic enough (or customizable enough) for wide use/acceptance. This would probably go well beyond the ability to change the colors to modifying a host of CSS-related attributes -- ideally using some theme configuration interface in the Drupal admin. Shadows, typefaces, corner rounding, font sizes could potentially all be up for grabs. Number and size of columns could be flexible in some way. The base configuration should, in some way, reflect a "brand" for Drupal but be pliable so that many users could reconfigure the theme (without a lot of CSS work) to make it their own.

I suppose, as an alternative approach, the theme could be something that's a showcase rather than a useful multipurpose theme. It would be less flexible but more attractive -- something to dazzle prospective users with rather than serve as a tool.

I guess there's an argument for both approaches.

sub

subscribing

subscribing

subscribe

subscribe

subscribe

Perhaps this initiative could be loosely based around what Snowman is doing (that is, Snowman comes up with some cool functionality that we can offer out of the box and while this initiative focuses on making said functionality look awesome).

subscribe

Can we ensure that the next theme name isn't as easily dated as Seven? As I said here, I'd really not like to see a D8 theme come out with TwentyThirteen as a name #1297428: Rename Seven in D8

Also, can any new core theme provide open source SVG screenshots of the theme to work from so that contributors have the flexibility going forward to change the design to meet current needs? These are useful files for the community to have and we should all be making better use of powerful tools like Inkscape.

Whatever we come up with should be responsive or perhaps mobile first & illustrate what we've learned as a community about design & usability. What kinds of reviews exist out there for Bartik? What niche does it fill and where is it falling short? Do we need more of a framework like Zen or Genesis in core?

Being available is the biggest piece.

I do love that with Inkscape you can put the files right into the repository & track changes. I was talking to Young about http://dc2009.drupalcon.org after DCDC and he was explaining how they had done this and how it had improved the development process. I don't know if this is possible with PS.

The whole open source tools angle is another ideal, but not something we can insist on.

Scalar vs raster might perhaps be something to specify..

EDIT: I just modified the second last sentence from "but possibly not something we can insist on at this stage." as that's stronger than I intended.

I would rather have an awesome design than dictate to a designer what tools they need to use, personally.

I definitely agree that priority 1 is getting designers excited about using Drupal.

However, having a new GPL theme with public access to the source files that generated it, I do think should be a requirement for core. The community needs the source files for core themes in my opinion.

Scalar will give the community more flexibility, but is probably more than is needed.

Agreed that it shouldn't be a requirement, but do really think that it would be cool to have a few themes generated by a GPL tool that generates very flexible scalar graphics and works in all platforms - http://inkscape.org - but yes, we can't dictate the tools that are used to generate D8 core theme(s).

EDIT: Sorry, too late for long threads.. Just re-reading some of my earlier posts.

Yeah, tools should be a free choice for the designer, it makes no sense to force designers to use a tool (Do we ask devs to use Eclipse ?). And from my own experience, good designers use photoshop most of the time... ;) Moreover, it would narrow down the number of designers of course.

sub

@partyp, please don't leave subscribe comments. Click the Follow button at the top of the issue instead.

Thanks.

I agree that using SVG or Inkscape should not be a requirement.

But... it would be fantastic to have access to visual elements in a W3C standard, text based vector format. To the best of my knowledge it is the easiest way to have graphics in version control. Although I'm still waiting for @mgifford to tell me where the DevSeed case study about the DCDC site is... ;-)

I started a sandbox project to create SVG UI Widgets Unfortunately I can't afford to spend as much time on it as I would like, but my dream is to create a repo of SVG snippets that can be used for Drupal design and UI mockups. Aiming for Bartik, Seven and Stark as a starting point.

This project was inspired by the fantastic session Flor and Nica gave at DCSF on using Fireworks for design mockups, and having a ready template with all the standard drupal 'bits' that need to be styled / themed / css'd etc. Being a linux geek, I was disappointed I couldn't dive in and adopt that toolchain/workflow. So, I thought I'd just start by re-creating it all in in SVG so I could do it with Inkscape instead. Obviously that took about 12 months longer than I expected it would (not because it was hard, but because I didn't have time, and it wasn't core to any work I was doing at the time).

The designer need not use this format or tool to create the initial design, but making sure we eventually get the design into SVG would be pretty damn cool.

Thanks @kattekrab. I asked @younghahn again about that. Heck, at this point I'd settle for some recollections & dreams. They did a great job with that conference and the design still stands out among the DrupalCons.

Something I'd really like to see in a basic core theme would be giving the administrator the ability to upload a header image, and background image as easily as uploading a logo or favicon. Along with being able to change colours and fonts, these things give users the ability to easily customise their sites in meaningful ways.

Perhaps another reminder is in order? Or perhaps we need to get someone to just interview them for a podcast or camp panel session or something? Sounds like great process was used, it would be such a shame if the broader community couldn't learn from their experience! :)

I realize this is an older thread, but I had a few thoughts since this is still listed as an active task.

In reply to Comment #97, I love the idea of a way to upload header and background images. My perspective as an amateur Drupal user is that having that process built in would be fantastic.

From comment #30:

Some of my initial thoughts of things to think about are: A grid system, CSS3 / HTML5, mobile browsing - which is set to overtake desktop browsing in the next few years.

Yes, but why not focus on integrating Panels capability, a specialty of Drupal? Most of you who have posted here are probably already familiar with the Layouts for Drupal 8 initiative that Dries Buytaert outlined on his blog on March 2, 2012. I was excited about this post from Dries because of the possibilities of integrating Panels-type functionality for Drupal 8, headed up by EclipseGC who has been a major force in the Panels project.

On a mobile theme for Drupal 8, I've talked to a number of mobile users who say they hate using the mobile version of a site and would much rather see the original site, since most mobile devices will display a full 960px width. With that in mind, I designed a sub-theme of Bartik for my site with larger fonts and navigation buttons that would be easy to press on small touch screens. My site works for both mobile and non-mobile users. As screen resolutions continue to increase overall, I think a consideration of setting a larger basic font size for core Drupal themes would be helpful.

re #99: I think Jeff Burnz was suggesting we use PSDs/Layered PNGs so that as we collaborate on a new theme (and even once the new theme is committed to core), we would all have the raw assets with all their layers (etc) available so we can easily make edits to suggest different designs. If you use a flattened JPG. then it will be nearly impossible to make even the simplest changes.

Thanks, bleen18. I realized that after further reading and cut that from my post before I saw your comment.

As far as I know layered PNGs are only useful if you have fireworks? Pretty sure that PSDs can be opened in GIMP.

Yes, PSDs are fully usable in The GIMP, in my experience.

Re #103: That's not completely true, Gimp does a terrible job at translating layer styles from PSD documents.

Lets not go off on a tangent here ... the only reason I left the comment in #100 is because #99 originally said something like "lets share jpgs instead" (paraphrasing).

Clean up "h2 class invisble"

Lets Make it by module

About two weeks ago, I saw a presentation done by EclipseGC at my local DUG on the work he is doing for D8 core theming. He is working to get the functions of Panels and Panels Everywhere with CTools into D8 to enhance the flexibility for layouts in different sections of a site. This will replace what we currently know as the block system in D7. After the presentation, I asked him if this is going to totally change the way theming is done in D8, and he said it should. From my notes on his reply, "Font and decorations will be the main issue for theming D8. I think you're going to see groupings of smart, well-thought-out layouts, and themes will support those layouts."

I hope the HTML output won't get "panelized" along with that

The goal is to have the default markup not-suck, and be easily overridable. If you want to help ensure that's the case, help is very much needed.

It's been a year and a half. I would love to see where this initiative stands. Could Jeff or someone on the team post an update? I realize this is probably a heavy coding part of the cycle right now, but I'm making forward-looking decisions and want to base them on as much information as I can gather. Which D8 design and layout initiatives are holding their momentum, which are falling away? Thanks.

Diane, refer to comment #107. I hear monthly updates from Kris Vanderwater (EclipseGc) through local DUG meetings, and he is responsible for layout coding for Drupal 8 core. Investigate the Panels module if you haven't heard about that before to help you understand the changes. If you want to plan, then plan layouts and learn all you can about font and decoration. That's the key D8 theming update.

What I would most love to see in Drupal 8 theme design is a complete drag and drop of all components. Moving from from blank page to fully integrated web page. No more theming, no panels and very little if any css.

With Twig, my sense is that the existing themes will need refactoring, and a built-in "Lush" theme (cf http://groups.drupal.org/node/265858) will be needed. BTW all front-end devs and themers should read http://groups.drupal.org/node/265858 for D8 theme system plans.

I'm looking forward to seeing where this goes.

I'd like to see more responsive Drupal sites, so perhaps an "on/off" responsive feature on the core theme would be nice.

Better luck in D9. :\ This won't make it in time for feature freeze, and wasn't started before December 1, in any case. :(

For anyone looking to help with more relevant theming work in D8 right now, there's plenty of work to be done in cleaning-up and improving both Stark and Bartik, and also helping out with the Twig conversions. Check out the following issues:

#1757550: [Meta] Convert core theme functions to Twig templates
#1854344: [meta] Goals for core themes: Make Stark as semantic as possible; Make Bartik a better prospective base theme

Yeah, I'm in on this and would like to give it a go. Do I have a timeframe in which a prototype is needed?

Kris

With semantic versioning, and a whole new theme layer in Twig - perhaps we can revisit this issue?

We have so much that's new and amazing in Drupal8 - it would be great if we could bring some freshness to the "out of the box" experience that reflects that new reality.

This won't go in before 8.0.x though, so clarifying status.

Isn't this a duplicate of the issue about adding a new theme in Drupal 9?
If it's not exactly a duplicate, since this issue was for adding a new theme in Drupal 8.1.x (which never happened, for what I can recall), at least it should be outdated from the new issue about a new theme in Drupal 9.

This issue seems very out of date.

We have Claro in core since this issue was opened, and Olivero hopefully coming soon, so I think this can be closed as outdated?

I am closing it as outdated, since essentially a new theme has been already added to Drupal 8. (Thank you, longwave, for pointing that out, and cilefen for confirming it.)