Configure extra fields for theme projects

As for me, the most important is how "open" a theme it is. Did it just take a design, implement and that's the end of the story? Is it a theme with a high customizability level like Zen, Basic or the One Above All, Fusion? I recommend

Base or finished

theme.

I think those suggestions all sound really useful, especially the grid-based, fluid + fixed, and the need to be able to indicate whether a theme supports mobile formats. Browser compatibility would be awesome. Colour scheme is a bonus, but if there are thumbnail/screenshots not 100% necessary.

Does anyone create non PHPTemplate themes anymore? Maybe a filter for theme engines?

And like chx says it would be nice to be able to filter which are base themes vs. very complete polished ones. (Or even something more granular, in case you wanted to eg. know which ones included CSS resets.)

Well. I'd think of resolution as something like 800, 960, 1024, 1280 and Fluid. So really it's 'width', not resolution, so Fixed means picking how fixed.

Agreed with merlin's suggestion, but drop 960 from that -- 960/980 is really just designed for 1024px wide resolutions with room for browser chrome. But that will need a multi-select.

Columns, browsers, color.module (less useful right now but I think that will change in D7), base theme vs. not... all yes. Mobile feels easier to just search for, but I'm not opposed to it.

Also: RTL.

I think a collection like this would give people a really great start to filter it down. Anything much beyond this and it starts getting really granular and hard to draw the line...

It would be nice if
Part 1) A theme that used a base theme could specify what base theme it uses.
Then
Part 2) Have a view on the base theme page that will pull all themes that use it as a base theme.

About #7.C, I think that in most cases all the possible options are selected, even if there are users who keep to open issue reports because they have problems with browser Y; differently from color scheme, resolution, and layout, browser compatibility is not something theme maintainers can know before the theme has been correctly tested.

I would argue for these public facing pages we need to avoid doing to much. From #7

A, B, D - sound solid and useful but the others I believe are not common quantifiers while choosing a theme.

C) It should simply be compatible with all, I don't choose my theme on compliance with IE, I simply expect it to already be. I applaud the focus on mobile themes, but honestly that is still less important.

E) Shouldn't themes try to support RTL? Why is this a quantifier? Is this something people looking for RTL themes truly look for?

F) Lets not, if we look at the numbers especially for Drupal 7 I think there would simply be not enough themes for such an option

Drupal 6 has already support for RTL themes. Maybe the quantifier would make more sense for Drupal 5 themes.

Well, the fact that Drupal 6 supports RTL themes does not make all themes RTL capable per say. Themes should strive for all kinds of things, and some of them lack localizability or RTL capabilities. This could easily be a differentiating factor IMHO.

I'd like to point out that it's not all cut and dried as to fixed vs. fluid. Fluid in itself could mean "any width" or it could mean that there's a min-width and a max-width set … which would seem to put consideration back into width settings.

Number of columns assumes it's a theme with "columns" in the first place. The concept of columns is itself perhaps an outdated assumption.

I'm working on a D7 theme that is "fluid" but has all fixed-width components … and has no columns per se in terms of display. Not sure how that would be tagged in these schema.

Resolution is also perhaps outdated. We now have high pixel density displays to consider.

Doctype is certainly something to be added: xhtml (and do we want to get into different versions?), html5, whatever else.

Does the theme use CSS3 (which has incomplete browser support)?

Maybe a way to look at this is a method to prompt for answers to these questions not so much for tagging but to give solid data for Solr to be able to drill in on. My guess is that, for me, if I'm digging through themes or modules or profiles or whatever, what Solr finds is going to be more important and relevant than browsing through zillions of projects by self-tagged designations.

Drupal 6 supporting RTL is just a first step... unless you take specific action otherwise, out of the box a theme is unlikely to be RTL-compatible. Any asymmetrical properties (floats, padding, margins, text-align, etc) need to have RTL equivalents in the -rtl version of the stylesheet.

I agree with laura-- i think doctype should be considerd. At least with regards to html5 and css3.

Also, what about accessibility -- wcag 1 vs 2? (are there any others?)

And I think light/dark and colorizable (regardless of the method, ie built-in or color module) and/or style variations are important as well.

Accessibility would be nice, but could cause a problem. We are talking about self certification here. So, there is a benefit, if I am looking for adoption of my theme, to say that it is 'accessible'. However, perhaps the risk of poorly catagorized 'accessible' themes, that actually aren't, is worth the payoff of being able to find themes where the designer has at least considered accessibility.

I would say that the options for accessibility should be:

WCAG 2.0 - Priority A
WCAG 2.0 - Priority AA

Since these are the targets that we aim for in core.

marked #299025: filter rtl themes and #167906: Drupal.org Themes classification as duplicates of this issue

Target purpose could help as well. Examples: Blog, corporate, e-commerce/shop, personal, news/newspaper, community, media, information,...

Width: 800, 1024, 1280, fluid [multi-select] is a very old-school way of thinking about things.

I'd prefer: Fixed, Fluid, Responsive.

I vote for not worry about specifying a pixel width for fixed widths. Most are for 1024 wide screens. I highly doubt people will submit themes that are for 800 pixel-wide screens at this point. And if someone is going bigger than 1024, they won't just do 1280 — they could do anything.

I also agree, let's add: HTML4 / untamed HTML, standards-based XHTML, XTHML+rdfa, HTML5.

I think being able to search for HTML5 themes, or Responsive themes is way more important than being able to search for 800-pixel wide themes at this point. It's 2010, not 2005.

And +1 for accessibility too. That raises people consciousness about making their themes conform to an accessibility standard, and allows people to find themes that conform to a standard.

What else?

Mark themes that use color module. Themes that are Base themes.

Are we doing Five Star on themes? I think that would be very helpful — rating. Plus some way to search by popularity (based on use). By date added. Number of columns. Colors. Skinr support. SASS support. RTL support.

Definitely:

A) Width: Fixed, Fluid, [Adaptive or Responsive] [multi-select]. Possibly just something that reflects "Fixed vs. not-fixed" because my gut is that's what 90% of end users actually care about and aren't as familiar with specific technical terms about layout.

B) Orientation support: Left-to-right languages, Right-to-left languages [multi-select]. Not sure this is the perfect wording but it seems to make it more self-explanatory.

C) Designed as a base/starter theme: Yes, No [single select]. Would save the awkward task of coming up with a comprehensive and non-confusing phrase for the opposite, and having too many people selecting both ("but my theme COULD be a good starting point...") :)

D) Recolorable: Yes, No [single select]. Not sure of the clearest wording for this. "Color Module support" seems kind of technical, and perhaps even too specific (per #16) with the possible increased popularity of other colouring modules. Also would this include multiple colour schemes, like if they were separate subthemes? Listing specific colours or even light/dark feels like a can of worms that gets awfully specific.

E) Doctype: HTML4 / untamed HTML, standards-based XHTML, XTHML+rdfa, HTML5

Date, popularity, rating, definitely, but that's not vocab.

Possibly:

Number of columns: 1, 2, 3, 4, more than 4 [multi-select]
I'm on the fence about this. It's becoming more old-school but people still REALLY search for this, so says google stats. I don't think I'd put grid-based in this though because the gridiness is often separate from the standard sidebars. If we have grid, probably as another item in and of itself.

Accessibility: I agree with Everett, if we do this it should be the standards, so it's not just a "sure, my theme is accessible!" checkbox free-for-all. At least then it opens itself up to specific bug reports when warranted. I'd love to see this but I think it depends on how much we want to foreground this in Drupal at large.

No:
Browser compatibility (agreed with the above reasons)
Skinr support (even with my Fusion bias, this doesn't feel like nearly enough of a standard yet)
LESS/SASS (ditto)

I do think number of columns is a good one. It is something people who aren't front-end-developers care about a lot.

As for "Width: Fixed, Fluid, [Adaptive or Responsive]", Stephthegeek said:

Possibly just something that reflects "Fixed vs. not-fixed" because my gut is that's what 90% of end users actually care about and aren't as familiar with specific technical terms about layout.

This is assuming most people who are searching for themes on drupal.org are non-technical people. I agree we *need* to design interfaces and buttons and documentation for the non-geeky person! I love how much the Drupal world and the d.o redesign is moving in this direction.... but also, I think there is room to remember the large base of users of drupal.org who are geeky, who are web design/development professionals, and create tools for us too. Both audiences are important.

"Responsive web design" is a specific phrase with a specific meaning. It's a term coined this year, and it refers to a specific set of techniques for making a layout that's much more than fluid. Anybody who's anybody in the web design world is buzzing about Responsive web design right now. (See look, a DrupalCon panel on it: http://cph2010.drupal.org/sessions/responsive-webdesign-drupal-theming). The name is "Responsive", not adaptive. The word "adaptive" means something else, much less specific and less meaningful. "Adaptive" is not a layout technique... it's just an adjective. Responsive is a CSS layout technique, just like fixed width and fluid width are.

I'm proposing we add "responsive" to "fixed" and "fluid" as one of three options for the kind of layout a theme has. We are going to see some responsive themes being created this year and next. They are not fixed or fluid. They are responsive. If someone makes a responsive design, and has to pick from the choice fluid or fixed, they'll be like "it's not either, what do I do?"

I know people who haven't heard of the responsive web design movement won't know what that means. But I don't think that's a good reason to not include the option. If a theme is responsive, the person who made it will know that it is and will know the word. They'll be able to choose it just fine. If someone is looking for a theme, and doesn't know what the choice means, that's cool, they can try a few out and see. Some people don't know what fixed and fluid are — some have no idea what "fixed" means. Plenty of people don't know what a doctype is, but we aren't arguing to not tag things with HTML5. Some people barely know what a "theme" is....

BTW, if you don't know what "responsive" means, try this out: http://hicksdesign.co.uk/

^^^ Open that site in a browser window, and then resize the window. Be sure to make it very narrow — like a netbook/iPad... then like a phone. Totally awesome, eh? I promise you, that's the future of web design. Not *all* webdesign, but a lot of it. All the top-tier web designs I know/ follow/ and respect are freaking out in excitement about responsive web design.

It's my hope that the Drupal community is forward-thinking enough to include this option when listing layout types: fixed, fluid, responsive. I hope we don't get lost in a semantic bikeshed that negates the ability to be a part of where the internet is going. I want to be able to search for Responsive themes on drupal.org! I want other people to be able to find any responsive theme that I might make. I want to be able to search and see how many responsive themes are popping up, or not, and pick apart the ones people have made, see what people's techniques are, keep up with the trends. I know anybody who's also excited about responsive web design and Drupal is going to want to do the same thing.

@stephthegeek wrote:

Accessibility: I agree with Everett, if we do this it should be the standards, so it's not just a "sure, my theme is accessible!" checkbox free-for-all. At least then it opens itself up to specific bug reports when warranted. I'd love to see this but I think it depends on how much we want to foreground this in Drupal at large.

* I don't quite understand the end of this statement "foreground this in Drupal at large".

Yes, thanks Derek.

I don't know how this will play out in the redesign, but the form you show above doesn't seem like the best layout for presenting these options, especially with this many. Are there mockups for this for the new design?

Also is it possible to have the Yes/No checkboxes just as a single checkbox? i.e. Base theme, direction, and recolourable. It doesn't seem as important to allow users to specifically *exclude* themes that are RTL (because you don't tend to have RTL *only* themes) or recolourable in particular. I maybe could see wanting to exclude base themes, but there aren't *that* many of them and they're usually pretty obvious. I'd still propose it to simplify things.

Designed as a base/starter theme: [ ] Yes
Supports right-to-left (RTL) language: [ ] Yes
Recolorable: [ ] Yes

Recolorable doesn't make any sense to me. Or at least the term seems to overstate what's offered. For example, Garland is recolorable but barely so. Several themes have color widgets that change almost nothing, or have predefined color palettes that cannot be changed without hacking the theme. Are those recolorable?

But stepping back a bit, I'm quite certain that there is no way we are going to come up with the perfect abstracted, quantifiable profile schema, but we are already flirting with a rather oppressive form to fill out that is starting to remind me of an online tax return.

We have Solr at hand. Perhaps the better way is to take more of a big data approach to our relational db content here and let search be our finder. Let people put in keywords, and have some predefined, cached searches linked at hand for people to go digging. I know this is a bit of a wildcard approach, but that form above is daunting. When people see big forms, they stop paying attention and start checking everything off (or nothing off). Rather than try to shoehorn design into pigeon holes a machine can easily understand, maybe we let design be design and teach the machine to understand it better.

Or we KISS.

Re #28, I have some issues:

* Columns is a concept that is fixed in certain platforms. For example, they would not apply at all for an iPad webapp. As noted above, I have a theme that has no columns per se. "Column" assumes a narrow design approach — and one that has been oft-criticized about Drupal by people outside of the community.

* Resolution has the same problem. These are desktop resolutions that are all very similar in approach for a front-end developer, especially with responsive implementation.

* Fixed or Fluid is vague. If a theme as a min-width and max-width, is that fixed or fluid?

What I would find more germane would be:

* Is this offered as a finished theme or a base theme?

* Does this theme use CSS3 or other approaches that may have limited browser compatibility?

* What platform is this theme designed for? Desktop? Tablet? Handheld?

It would be *fabulous* if we could work image search into it, and be able to search for colors. It may not be big for themers, but end users would probably love it. But that's a big wish. I believe there's a Lucene subclass for image search, but have no idea as to its stability or effectiveness.

I can only repeat myself that we should add but I'll try to explain it better.

Try to view the issue not from a themer or developer standpoint looking for a theme to built upon. Don't only consider how professionals thinks about themes but also how new drupal user would.
He/She won't look for a three columns fixed theme for 800x600. He/She wouldn't care about these things, instead what he'd look for is a theme for his blog, sports club, online shop or company. We should add this filter option as it helps new users (and us as it is the same category as "base theme") and it is easy to implement. There is a reason why every bigger theme shop offers this filter option.

Another discussion popped up over #957692: Basethemes/starter themes should have their own section on d.o - clear interest in getting 'base themes' tagged and given their own listing. While they are the most installed, they are not finished themes.

Another addition to the list above would be administration themes - to make them easier to find, or to filter them out.

Other votes for mobile themes, but I think that is addressed above. I would make an assumption about most themes, and add the facets like this.

A) Is a base theme: boolean (default, false)

B) Is an administration theme: boolean (default false)

C) Supports these devices: Desktop, Tablet, Handheld * (make the assumption that all themes support desktop? Just list tablet or handheld?)

D) Supports right to left languages: boolean * (make the assumption all themes support LTR, you don't need that as an option.)

In the case of RTL... #10 #11 were RTL dissenters. I think Gabor in #12 and Steph in #14 clearly explained why this is a useful filter. There was even another thread requesting this filter #17. It first of all makes it easier for RTL users to locate themes, and then, raises awareness about RTL support.

For the other options of
* Columns: 1 2 3 4
* Fixed or Fluid: Fixed Fluid

Many theme and template search sites include these kinds of filter, but they also include color and usage. Would a free tagging option be possible? Maybe like Daniel's ideas, it's out of scope.

I'm quite certain that there is no way we are going to come up with the perfect abstracted, quantifiable profile schema...

Agreed.

I've read this entire thread and to me the only post that makes really deep sense to me is #29 - KISS and leverage Solr. Use some really basic categories like admin theme, base theme, apart from that its Solr all the way - with saved searches like RTL, Accessibility, Validation, Columns etc.

OK, thanks for the clarification. In that case:

1. "Doctype" is the wrong descriptor - it should "Validation". Doctype is by and large irrelevant unless the theme actually validates.

2. Design attributes - dark, minimal, glossy etc - that's something I'd want to search on.

3. Module support and dependencies - say I want to find all themes that support Skinr, or Panels Everywhere, or which have special support for Nice Menus, Conditional styles, Quicktabs or Views Slideshowy things etc. Many users select themes based on just one of these criteria and then hack it like a starter theme, with that specific feature in place and done for them already. This could be an autocomplete field/comma separated list.

4. CSS version is tenuous at best, unless we're talking about validation, then they might care, otherwise users are much more interested in #2 regardless of how the design is actually achieved. Most have no idea what CSS is, let alone versions.

5. No browser support options - tough one - versions always changing (new browser releases) and flat out poor testing from themers makes this problematic. That said users really do care about this, a lot (especially when the boss is demanding IE6/FF1.5 support for example - I have an RFP on my desk right now that demands exactly that).

6. Columns - what stephthegeek said, old school and hard to quantify. That said Wordpress has checkboxes for both sidebars and columns.

7. Extra regions - users care about this a hell of a lot (its the most requested feature). Not sure how that could be included though.

Bloating the form seems like a minor issue to me (within reason), themers/designers want people to find their hard work - 5 or 10 minutes to fill out the form is rather trivial in the grand scheme of actually preparing and then committing a theme to D.O, and its entirely optional I take it.

#31: Agree with every point except E and F wich are covered well in #35
Re dww: Thanks for the response and the links. I followed the modules discussion for a few links but only seem to find people saying that from a usability standpoint we should rather show what solutions X has to offer instead of technical details. However the categorisation of modules from a "what the user wants" standpoint is a different issue than this one and much more complicated. With drupal one module usually doesn't provide the whole solution but one needs a combination of modules. With themes it is different. A "blog theme" solves a specific need but the "flag module" (awesome module but still) doesn't. Therefore I think module search discussions are a seperate issue and category and task based filters are important.
A: As for a search form only base theme should show up as an option since only advanced drupal users know the difference and could make the choice for a "Finished theme".

#35: Agree
7. Allthough this information would be helpful I fear it is very hard to provide as usefull information via taxonomy. Maybe as a seperate issue theme maintainers could be encouraged to add a screenshot of the block page so regions are made visible via browsing.

OT:

• [Theme Name] is a [Design attribute], [columns], [Drupal Version] [Target purpose] Theme. It is [width] theme and tested to work in [Browser support]. Additional Feaures are [feature]
• Zen is a Drupal 5,6,7 base theme. It is fixed or fluid width theme and tested to work with IE6, IE7, IE8, FF, Safari and Chome. Additional Feaures are special theme options.
• Acquia Marina is a friendly, three column, Drupal 6 Theme, which is best used for Blog, News, Information or community sites. It is fixed width and tested to work with iPad, IE7, IE8, FF, Safari and Chome. Additional Feaures are RTL Support, html5 usage, css3 usage.

#34 is right on point IMO.

If things aren't facets they are much harder to use. The suggestion of using search breaks down in cases like searching for a mobile device theme and coming across project pages that say "This theme is not suitable for mobile devices," or "A mobile companion theme is in the works etc" ...

The other item I haven't seen here that would be useful is base theme. That is base theme as in "this theme depends on Zen/Fusion etc.". I find I often want to quickly locate a theme that will work well with an already installed/maintained base theme and having a facet that listed which theme a particular theme is based on would be very helpful.

It would be nice to have something. All themes are not alike in purpose or intended medium. Perhaps freetagging (such as on this issue) would be too messy, but this issue went around in circles and kind of fizzled in the past couple of weeks. (No doubt plenty of other pressing things to work on. ;) )

But part of Solr's power is to drill down into taxonomy. We have it for modules, I don't see why we can't have it for themes. Some possible tids:

* base theme
* grid-based theme
* mobile theme
* recolorable theme (uses Color module)
* HTML5 theme
* ...

I'm not a big theme consumer on d.o, so I'm not sure by what other things people distinguish what they're looking for, but some kind of array of terms could only be helpful. Or people can ignore them.

Closing old issues. Please re-open if needed.

I get issue cleanup is important, but I don't think should be considered won't fix. I don't there's any disagreement about necessity, just implementation.

Hoping that moving this to Customizations will help.

We can use any field type for this, not necessarily taxonomy-only.