What shall we do about Themes?
Update - 22 Feb 2010: One of the issues lightly touched on below is the market need for some themes besides those on drupal.org. Acquia has started to collect both themes, as well as links to theme providers, at a new site devoted to the design-aspects of Drupal. See design.acquia.com for more information.
(Original post follows.)
For almost as long as I've been involved with Drupal, there's been a running complaint – either a (false) perception or (true) reality – that Drupal is "theme-challenged" compared to alternatives like Joomla and WordPress. I had this complaint myself when I first started using Drupal. Our investors heard it during their due-diligence on Drupal. And I continue to hear it from people I meet who are building their first Drupal site.
I've got some cycles now to pay some concentrated attention to this, and see if there's something we can do about it (where "we" means both Acquia and the Drupal community at large.)
I encourage you to add your comments / thoughts to this blog post. In fact, my primary purpose in this post is to listen to people. So read on, and give me your thoughts.
What's the problem - really?
The first thing to do is to characterize the complaints. I think there are (at least) two high-level areas of interest:
- Issues surrounding off-the-shelf (available) themes;
- The size (or lack of...) of the "designer" community within the Drupal community at large.
Let's tackle these one at a time. Note: In examining this entire subject, We now have some actual data on this, arising from a recent survey of Drupal & Joomla users. In the survey, each (self-identified) community expresses its opinions both Drupal & Joomla. While I haven't dug too deep to know the precise statistical validity of the survey, it looks like there's "enough" to hear a message. So I'll use the data here to discuss the subject.
Off the shelf theme issues
In my thinking, I've started to sub-categorize the problems faced by those looking for OTS themes into quantity, quality, and discoverability issues.
Quantity
Typical complaint: Drupal doesn't have a wide-enough selection of off-the-shelf themes to choose from compared to (Joomla/WordPress/...).
The survey data (summarized below) validates this complaint.
- Both communities score Drupal theme quantity poorly. Only 58% say the quantity is Satisfactory or better. In fact, Drupalistas themselves don't give Drupal very high marks in the off-the-shelf themes area. But Joombies (credit to Amy Stephan for the nickname) are pretty blunt: 0% of respondents said Drupal has very good quantity, and 60% say the Drupal world just plain lacks themes.
- In contrast, both communities view the Joomla themes ("templates") quantity situation more favorably. It's pretty stark: > 80% of the total (no matter how you measure it) say the quantity is Satisfactory or better. (Note also that Drupalistas give the Joomla project higher credit for Very Good than Joombies do themselves. Clearly we Drupalers are carrying a chip on our shoulder about our situation.)
One thing changing this is companies like Top Notch Themes (an Acquia partner) who are building businesses around selling Premium (non-GPL, pay-to-use) Drupal Themes. (How can a theme be a Premium Theme if Drupal is GPL?) This can gradually help; but is one company enough?
The behemoth (if there is such a thing) in the Premium Themes business is TemplateMonster.com. To their credit, they offer the majority of their designs as Drupal themes (vs. just Joomla Templates, where they started). There are hundreds of choices here. But TemplateMonster suffers from occasional complaints about the quality of their templates. Which leads to the next issue...:
Quality
Typical complaint: I can find theme designs I like, but the ones I find have functional problems, e.g. inflexible layouts, menu issues, hard-to-swap-out stock photos, etc.
Yup - survey data validates this, too. Both communities of respondents judged Joomla Template quality higher. (Remember - we're talking about off-the-shelf stuff here.)
Side note: It would be useful to have more specifics in this quality area. Are the issues more around "This design is better than that," or "This implementation is better than that," or...?
Discoverability; Premium vs. non-...
As I've considered the question about Quantity, I've started to wonder whether the problem is as much a discoverability issue as a quantity issue. Drupal.org only lists GPL themes - and doesn't list Premium Themes.
Finding these Premium Drupal Themes turns out to be not so easy. Look at the first page of Google results when you search for Joomla Templates vs. Drupal Themes, and compare the number of commercial (Premium) theme providers.
Joomla templates:
Compare the above image with the same for...:
Drupal themes:
It's possible that the Joomla community achieved Template-critical-mass because their community actively supported those in their ranks that sell Premium Templates. Want proof? There's no tab on Joomla's downloads area pointing to a collection of free templates on joomla.org; people must go Googling to find them, thus "pushing business" to Joomla shops. If Joomla were a company (vs. a project), this would be called "enabling a growing partner community."
Note that most of the Drupal listings are for sites that are re-publishing the themes from drupal.org, while the Joomla results point primarily to Premium themes. Does this suggest that the "problem" is that the Drupal community doesn't embrace a Premium Themes community as Joomla does? Maybe. Maybe not.
WordPress Themes. WordPress is a third data point. The WordPress community has had a running debate since Fall 2008 about whether Premium Themes are "a good thing" or not. Matt Mullenweg initially didn't discourage them; in fact there was for a while talk about building a Theme marketplace. But last fall he basically said he thinks Premium Themes are not in keeping with the spirit of open source, and is discouraging them.
I think WordPress' situation may be different than Drupal's (and Joomla's). There were already > 750 WP themes (778 now) on wordpress.org, all nicely tagged with # columns, colors, sidebar placement, etc. before Matt started discouraging Premium Themes. So in some ways, discouraging Premium is an easier position to take once WordPress had a critical mass.... ;-) And blog themes are less work to create than "full website" themes - making it easier to grow a critical mass.
Conclusion? I'm frankly not sure what to conclude – is the Drupal themes problem partly a problem in being able to simply find themes outside of drupal.org? Or is it that we need a community that embraces Premium themes listed en masse on Google? Because of the need to include rights-managed stock photography in a wide collection of Themes, I'd tend to lean towards the latter; except that it's influenced by the next major point...:
The designer (un)friendliness of the Drupal community
As much as I've heard that "Drupal lacks Themes," I've also heard "The Drupal community is primarily made up of programmers, not designers. So the (... fill in the blank, e.g. code, templating system, ...) isn't designer friendly, and it's too hard to (... fill in the blank ....)" Likewise, I've heard (or even claimed) that Joomla had stronger roots in the designer community (I think..), so it's natural they'd be more designer-friendly.
I've been thinking about this for a while. I've concluded there are a number elements that contribute to why designers aren't as big a part of the Drupal open source project:
- Code entanglement. To get Drupal to "look like you want it to," frequently you have to resort to coding PHP; you can't just tweak HTML/CSS. This forces designers to have to learn Drupal to get that done. Drupal is trying to be more scaleable, flexible, etc., than competing systems, so it's learning curve is higher. Designers just want to make stuff "look like this." Learning how to code to get it done is more work than they have time for. So they pick an easier path.
- Lack of in-CMS editing. In Joomla (and WP?) the site builder can edit the CSS & template HTML from within the CMS itself. You can't do that in Drupal. There are technical justifications for the Drupal approach. But it makes it hard for designers coming from the Joomla ranks. I'm one of them; I learned Joomla templating by making changes in the CSS / HTML from within Joomla. Once I felt more confident, I started changing it outside of Joomla (and using version control). But I learned within the CMS. Drupal doesn't let you start easy like this.
- Reputation history. Drupal 6 made templating more sane in many ways, and IMHO many designers could easily learn to make Drupal templates. But while the Drupal community fixed the technical problem, they either didn't try, or didn't succeed in overcoming the reputation that "Drupal Themes are hard to build."
- Lack of outreach. Related to reputation history, there's been desire, but no organized effort to go attract the designer community.
Most of these problems can be solved. We at Acquia are going to spend some marketing time and money this year to do outreach to the designer community, and try to erase the "hard" reputation. We can also do some things like telling designers how big the Drupal community is, and how much impact creating a theme can have. Showing them how – in an open-source-friendly way – get themselves the branding / reputation they want for design within the community. Creating guides that show the relatively simple steps to adapt, say, a WP Theme or Joomla Template to Drupal.
And if we really want to make life easier for designers, the Drupal community may just have to do some more work on changing how the theming layer works. (More here.)
We at Acquia have lots of ideas about how to make the Drupal world a place where designers feel warm, and welcome. We'll be putting effort into this in the next months. But we'll need to partner with the Drupal community - both for ideas, and for execution.
So, what should we do?
All this is just analysis; I've pointed out the problems: We need more, better, easier to find themes from a LOT more designers. The question is, how?
Please help our community by sharing your thoughts here. In a week or so, I'll follow-up with another blog post that summarizes the results, and shares (some or all) of what (at least) we at Acquia think we can do. Thanks in advance!
(Back-info...)
Data from the survey
Quantity of themes
Respondent's opinions about the quantity of Drupal themes:| Very Good | Satisfactory | Usatisfactory | Very Bad | |
| Drupal Users | 12.77% | 51.06% | 34.04% | 2.13% |
| Joomla Users | 0% (!) | 38.46% | 53.85% (!) | 7.69% |
| Total | 8.82% | 50% | 36.76% | 4.41% |
| Very Good | Satisfactory | Usatisfactory | Very Bad | |
| Drupal Users | 59.09% | 31.82% | 4.55% | 4.55% |
| Joomla Users | 44.12% | 47.06% | 5.88% | 2.95%% |
| Total | 44.62% | 41.54% | 9.23% | 4.62% |
Quality of themes
Respondents opinions about Drupal theme quality:| Very Good | Satisfactory | Usatisfactory | Very Bad | |
| Drupal Users | 18.37% | 65.31% | 14.29% | 2.04% |
| Joomla Users | 0% (!) | 50% | 35.71% | 14.29% |
| Total | 12.5% | 63.89% | 18.06% | 5.56% |
| Very Good | Satisfactory | Usatisfactory | Very Bad | |
| Drupal Users | 26.09% | 69.57% | 0% | 4.35% |
| Joomla Users | 58.82% | 32.35% | 8.82% | 0% |
| Total | 41.18% | 50% | 5.88% | 2.94% |
Premium themes
How can a theme be a non-GPL, "premium" theme if Drupal is a GPL project?
The GPL "taints" (causes the GPL to apply to) code by examining whether an addition to the program in question creates a "derivative work." In the context of web applications, the software running on the server is an application, and the stuff that server sends to the browser is "data." The browser, and the data it is using, is a "separate work."
So the Javascript sent to your browser by the Drupal server isn't part of the Drupal application running on the web server. Therefore, the Javascript isn't "tainted" by the license of Drupal. Of course, the Javascript itself could be licensed under GPL, but it isn't determined by the license of Drupal.
Premium Theme providers can therefore include things like rights-managed stock photography, Javascript (that isn't GPL'd in the browser) - even the CSS - that isn't licensed under GPL, and for which you must purchase a license to use.
Theming layer
When I had our team review this post prior to posting (asking for feedback), Jacob posited the following thoughts I thought were worth putting here. The rest of this page are his words.
...
I've used various PHP templating frameworks (mostly flexy and smarty). I don't think big difference is PHP code (although I know for some designers it is scary to use <? in their code.)
The thing which makes Drupal themes hard to use IMO is the nesting, the abstractness of it all, and the magic function names. In most "normal" templating systems, there is a $masterTemplate variable (to define the whole page layout and generally left and right columns and a $template variable (to define which template file makes up the center body). Then inside each template file there are includes which point to other template files.
This control flow makes sense to someone who doesn't need to know the intricate details of how drupal works or even PHP, it also plays better with WYSWYG tools like DW.
A designer can grok, left-column, right-column, etc, but in Drupal, often the "right" way to theme involves writing a lot of code in template.php, and creating files for each block, node type, etc. It is very hard to learn all these magical names. I think D6 devel module with the themer tool is great for this, but still assumes a certain general understanding.
I'd do 2 things:
- Add a comment or even better some type of non-presntation XHTML before and after each theme'd element which shows it's javadoc, location of the function, etc.
- Make a quick way to click and "override" an element w/ JS. This will basically give a modal dialog displaying the existing function, renamed to fit into your theme, and a little shpeil about where to put it.
This helps people find what they need to override and tells them how to override it. It also helps newbs get into theming from the browser while not allowing browser based editing of templates. (BTW, there is a module sorta for this called contemplate.)
Related Content
AcquiaBlog
2010 has been an inflection point for the Acquia partner program. We are doing more business than ever with partners, including case studies with Palantir.net, Blink Reaction, and IBM Global Services.
Bryan House
It is that phase of my life! I'm just turning 30 in a month, working with Drupal for 7 years and just had my third Acquia anniversary a week ago. Time to look back and evaluate how things went, all the good and bad things; even better if the wisdom can be shared with others. This was part of my thinking when I submitted the session titled "Come for the software, stay for the community" for Drupalcon Copenhagen.
Gábor Hojtsy
It sounded like a really simple request: "Is it easy to add a search filter for 'My posts'?". In other words, add a search result facet for posts by the current (logged in) user through the Apache Solr Search Integration module APIs?
But then the wheels start turning - we want not just one blind link, but a real facet link that tells us how many results we'll get. Also, if we are filtering by 'My posts' then we probably have an equal use case for the opposite filter 'Posts not by me'. So we really need a facet block with two links and facets counts.
Peter Wolanin
Comments
Please don't include "in-CMS
Please don't include "in-CMS template editing". It is the one feature I most dislike in Wordpress, Textpattern etc. I also find that the client has very little if any need of that feature.
I agree with Jacob's thoughts, also I would like to see a solid separate admin layout that doesn't cross into the front facing layout (not as default but by choice). It's easy enough to set an Admin template but often administrative tasks will still cross into the front facing layout.
And for my last thought. Search, it would make my life (and perhaps others) so much easier if I had the ability to restrict search indexing on certain content types (including titles).
Overall the learning curve is steep with Drupal (I'm a design dude), but proper project analysis and learning to understand Drupal has brought the overall (front and backend) experience that my clients experience to a new level.
There's my two cents,
Chet
Jacob Singh
Hi Chet, thanks for your
Hi Chet, thanks for your comments.
If you're looking to restrict search by content type, check out Acquia Search:
http://acquia.com/products-services/acquia-search
We provide a hosted search product which integrates tightly with Drupal, providng faceted search, content biasing, content recommendations (as a block on related nodes) and many other features.
One feature is the ability to make certain content types "float" to the top in search results more often, or omit certain types all together.
Hope that helps!
Jacob
Thanks for the tips, I'll be
Thanks for the tips, I'll be looking that faceted search over.
There is a module -
There is a module - http://drupal.org/project/theme_editor that give you the in-CMS template editing features like wordpress has if you really what to do theming that way.
I did a cursory code review
I did a cursory code review of this module and of the companion module_editor; it looks like it needs quite a bit of love before being usable on real sites.
Jay Batson
Thanks both Chris and
Thanks both Chris and Andrew. I (a) wasn't aware of the module, and (b) am happy somebody took a look at it.
Chet, I hear what you say about not wanting in-CMS editing. But the point here was to ask whether this would make it easier for people to work on themes. Fortunately, Drupal gives us ways to turn capabilities on/off by role. So if such a thing did end up in Drupal, you'd be able to avoid the feature if desired - or at least control who can muck with it.
Drupal's permissions don't
Drupal's permissions don't help here. The issue is that to edit theme (or module) files, they need to be writable by the web server, which means many more ways for your site to get hacked.
I think the theme issue for
I think the theme issue for Drupal is a very complex one. Some of it is (for what I read) tackled by the d7ux project.
But, I'd like to try to give my 2 cents here.
First, I'm from a design background with a previous degree in computer sciences (programming for automation). Yeah, I'm kind of an hybrid monster, but this makes me unafraid of code. That said, I try to avoid coding as much as possible when it's not necessary. That is one of the main reason why I found Drupal, looking for a framework to build sites.
I will start by commenting on the Drupal community and its lack of designers (or is it really...)
I would tend to think that it is not by offering many well designed/fancy themes that you will attract designers to Drupal.
A clean, well balanced neutral interface with a clear ability to shape it into any idea you might have would do the trick.
I believe that a designer will, at first, be attracted by the design of the product (d.o redesign will surely help).
Then, since it will probably be used to provide a customized site design to a client or for a personal project, will look to bend it to fit her/his design idea(s). This is where Drupal shines vs Joomla I would think. The problem is that Drupal doesn't have the first contact appeal that Joomla/WP seems to have.
You could have a look at a CMS called indexhibit. It's community is largely composed of artist/designers/photographers with (often) limited knowledge when it come to web technologies. The platform, although limited and mainly aimed at portfolio sites, empowers its users to build the site they want. I believe part of it's success in its easy administration interface and clear separation of admin vs site. Maybe this could be part of a default Designer's Drupal install profile...
This is only one facet of the Theme problem, but attracting a few designers would probably also help build a stronger (premium or not) theme base.
Antoine
Jeff Noyes
I completely agree with you
I completely agree with you that a "clear ability to shape it into any idea you might have would do the trick." I'm hopeful the work Mark and Liesa are doing will have this impact.
Designers are builders, creators, imagineers. They want to build the theme library vs use it. I fall into this category. As a designer, the only way I'd use a theme from a library of other themes is if I'm in a hurry to release - otherwise I'd much rather be original and get the experience of building a theme in an platform that appears to be growing.
Jeff Noyes
Interaction Designer
jeffnoyes1@gmail.com
Jay Batson
Jeff -- (Chuckling that
Jeff --
(Chuckling that we're using this public tool to have a conversation, when I could just yell down a couple of cubes... ;-)
I think there are two separate issues here that I'm discussing:
We need to attend to both.
I agree on the need to have
I agree on the need to have both. There are so many facets to building a website that we can't just neglect anybody (non-designers are often the best content providers.)
I would also like to emphasize on the fact that attracting more designer will, in part, also solve the problem of having a good base of high quality theme available for the non-designer crowd...
Barry Sampson
Sure we need to address the
Sure we need to address the technical obstacles to getting designers involved, but there are similar challenges when theming Joomla or Wordpress.
I think the biggest issue is that it's much harder to build themes for Drupal because it has no default 'out of the box' layout or use case. Sure you can use Wordpress for other things, but it's basically a blogging engine, and the majority of the available themes are blog themes. Joomla may be more fully featured, but it still has a default layout that you can theme.
Drupal's power is in it's flexibility to let you build anything your imagination and skills can come up with. It would be impossible to come up with a theme that met every eventuality.
Perhaps the answer is to have a set of default install profiles based on common use cases that we can build themes around?
Glad you guys are going to
Glad you guys are going to look at the theming part of Drupal.
Im about to launch a new line of premium themes on alldrupalthemes.com in 10-14 days, it's going to take Drupal themes to a whole new level with professional designs, elaborate configurability and full color module integration.
if you guys want to learn more or be part of it before it launches send me an email at my form: http://alldrupalthemes.com/contact.html
My wishlist for the Drupal theming engine:
-color module out of core: http://drupal.org/node/445990 (we need a color API not a garland-render module)
-File based CSS settings caching. I use this in my premium themes and will try to get it in core
JR
Thomas Moseler
Contributing a GPL'd theme
Contributing a GPL'd theme to drupal.org
CVS - oh yeah.
This is about contributing a free theme to drupal.org. I recently did this, and it was quite an eye-opener why there are not more contributed themes on drupal.org.
Thinking from a designer's person mind set - avoiding coding and coding-like thinking as much as he can: frankly, no one that does not have a real strong determination will succeed to submit his theme.
CVS itself is hard to use - well, in the end I switched to Tortoise as a GUI-driven client which helped a lot. But _all_ documentation you find on d.o. describes using the command-line. So a designer could use Tortoise quite well - still he won't find much help how to.
Next step (after having struggled through how to use your CVS account at all, since there is no "login" which you would expect) is to create a project page, filling out a lot of fields, and linking this to your CVS Folder.
It sure was my own fault I did not find the link, but for quite a while I did not find a link to create a release (which is simple in the end, but you might overlook it).
The entire interface, process and hurdles to overcome is unbelievably tangled and counter-intuitive. If I had not been long fallen in love to the Drupal community I'd sure given up, took me two to three days with several re-try's anyway.
What was more: it was not easy to find help for this on IRC. Some kind people helped me out (kudos to killes patience), but you soon learn no one loves CVS...
Well, this has turned into a bit of a rant, sorry for that.
If we want to have more themes on d.o., this process must be built in a way a not-so-technical designer can make it, how it is at the moment it is rather a solid "iron man" parcours.
Jeff Noyes
I agree. I've been in the
I agree. I've been in the design business for a long time, and I've never had to use CVS, SVN or install patches to A) figure out what's going on B) contribute.
Having been in the space for almost a year now, I understand it's value. But its taken me a long time to get there, and so long as these types of barriers remain, we shouldn't expect a mass of contributions from designers or any other type outside of the developer community.
Jeff Noyes
Interaction Designer
jeffnoyes1@gmail.com
I understand it's value. But
This hits it right on the head. Especially for designers who mostly deal with non-textual assets, version control doesn't seem like a very useful function. What if there was CVS documentation specifically for designers? It could explain specific use cases of why CVS is important and how it's a benefit to designers and theme users. For users of themes, project pages with their summaries, recommended versions, and so on are a huge benefit compared to 500 post long forum threads containing random versions of a theme - and that's all made possible by the use of CVS.
Or, you know, do something
Or, you know, do something crazy. Like allow theme submission without CVS.
Around 50% of the open
Around 50% of the open source themes available for free download on drupal.org contain functional errors. These are usually worked out in the issues queue and in subsequent version releases, but new users may not expect or realize that some of the free themes are not 100% production ready immediately after download. As an individual site's complexity increases, with the addition of more and more third party modules from different developing hands, the "join points" where they all come together in the theme layer multiply, requiring more and more site specific CSS fixes to maintain a consistent display.
DHTML complexity - all of the "seam points" between php, javascript, html, css, xml, and other code layers includes a wide variety of methods for styling output display that may have to be addressed individually by the developers / designers. For around half of the sites built for client requirements, use of stock free or premium themes + "bug fix" will be sufficient. The other half have a specific design vision or new idea that requires significant css, code, & template modifications to build a new theme, layout, & GUI that works with the site's functionality (ecommerce, social networking, social bookmarking, blog, etc).
CSS iterations of a base theme are probably the biggest resource to draw upon for drupal themes. So many designers have modified blue marine, zen, newswire, or other free themes to amazing new levels - if we can enable the sharing of all the sub-variations of a theme back to the design community, there would be many more options available. Expanding the theme garden to include multiple sub-versions of a base theme, along with review functionality on themes, would be excellent.
Tools enabling Drupal theme design in Dreamweaver or providing additional diagnostic integration through Firebug are available, but very minimally supported and used over all. A Dreamweaver-like layout tool for drupal allowing one to easily set the sidebar column widths, the size of the theme's block regions, colors, font, etc. save & publish a style.css would be great. Many new D6 themes are offering more & more of this in admin settings, working with theme api, color module, etc. but required custom css changes are sometimes difficult to integrate with these automated settings.
There is a huge difference between the drupal community and joomla when it comes to commercialized module & theme solutions. WordPress and drupal themes & modules are still primarily "free" in the sense of free open source software. It is a difficult path to walk but the commercialization of module & theme solutions as paid downloads is a proprietary model. The reason many developers build on the drupal platform is the open source sharing / foss philosophy - any loss of this = doom.
Things that would help also with theming would be integration of a WYSIWYG editor like FCK into core along with advanced profiles like APK / BuddyPress. There is a lot of future strength in developing powerful, finished, and thoroughly tested themes that are built specifically for an installation profile, and then supporting them like Acquia & Top Notch Themes. Cross-browser display issues remain a continual problem.
We have bought premium drupal themes for projects and have requested also mySQL maps of the demo site structure. Installing a site template from a mySQL map allows for the inclusion of positioned block elements as well as custom code in the display that can more easily be reconfigured by the designers, saving a lot of time.
Josh Miller
From where I sit, there are
From where I sit, there are two major obstacles to more/better themes on d.o:
If you want to focus your fire at something focus at this: Help the drupal.org team make it easier for themers to upload their themes AND/OR help the patterns team make default configurations (including downloading and installing dependent modules) a reality.
Josh
I also believe that patterns
I also believe that patterns will help improve Theme development a lot.
I think that the best thing
I think that the best thing to do is encourage professional themers. There are many other drupal commercial themers that you don't mention here.
Joomla.org , before used to have a section where new themes could be published, regardless if they were free or commercial, and now that there are many community sites doing that so they have removed that section about 1 year ago.
Take a look at Magento, they have a section where they display all extensions, commercial or not, and a themes section too. They encourage commercial themers and in such a short period you have many magento theme providers and some really excellent themes. Because themers know their themes will be seen by people.
I think the best thing to do is encourage non-GPL themes, open a section for those themes in drupal.org. Making non-GPL themes or modules should not be seen as a heresy.
I would agree that CVS is
I would agree that CVS is one of the biggest challenges for designers.
Having ported a couple of themes back then for D5, I never managed to get them into CVS. So I just gave up.
The other problem lies in the drupal architecture itself. It can do so many things that a theme just can't cover them all. That might not sound so challenging for a coder but for a designer it is.
Designs are build for a special audience and a special use-case. Unlike modules that is almost impossible to abstract.
So instead of looking for generic drupal themes, specialized themes for news-sites, social communities, galleries would be needed. But what modules are used for that task? What blocks? Drupal is so flexible, that is is very hard for a designer to build a generic theme that covers many use cases.
Having a few install profiles that a designer can design for would help.
But are there many?
Is there one for a forum?
For an image-gallery?
Maybe that would be a starting point. Give designer something that they can actually design. Not just a gazillion options.
Jan
As to the information about
As to the information about JavaScript licensing; does using any of the functions in the Drupal.* namespace bind your code to the GPL? I would think that many themes with heavy JS would then have GPL'ed JS.
Jay Batson
Difficult question,
Difficult question, Andrew.
I've asked lots of questions about this from various people that spend all day thinking about open source licensing. Note that I'm a lawyer, so I can speak the lingo; and I think I've looked at this a lot. But I still defer to people who think more about it.
I'm not a coder; so I'm going to assume the Drupal.* namespace you refer to is Javascript present on a page supplied to a browser by Drupal. If so...:
I think the controlling principle here is similar to what the OSF, etc., has said about web services: when application A on host 1 consumes / uses web service S running on host 2, A does not become a derivative work of S. If S is Drupal / GPL open source, the GPL of S does not "taint" A.
So, even if Javascript happens to use a Drupal.* namespace, that Javascript is still either running locally (in the browser of A), or accessing web services offered by S. In neither case, is it creating a derivative work of S (Drupal). So that Drupal.* namespace code would not be GPL'd simply by operation.
Make sense?
Yes, it does, and makes
Yes, it does, and makes sense for Javascript which doesn't call Drupal functions. But, a better example might be a theme which has translatable text. If Javascript is changing text, it probably calls the Drupal.t() function, which I think *is* GPL'ed. So then it's not just code living in your browser, it's code that directly interacts with Drupal. Other common functions might be Drupal.checkPlain(), Drupal.theme(), etc.
Thanks!
Sorry Jay, but you're wrong.
Sorry Jay, but you're wrong. :-)
Drupal includes PHP code that is GPLed. Any part of a theme that executes as PHP on the server (which includes all template files, as well as template.php) is subject to the GPL.
Drupal includes Javascript code that is GPLed, which includes the copy of jQuery that ships with Drupal. Any Javascript code that shares data structures with that code is therefore also subject to the GPL.
"Premium" themes have a hard time with the GPL, due to the GPL, not Drupal. PHP, template files, and Javascript are all subject to the GPL. Imagery is not subject to the GPL, assuming it's not derived from a GPLed image. CSS is an odd case; I suppose there it depends how much of your CSS is copying and pasting from core or a GPLed contrib theme like Zen.
All of this is already detailed on drupal.org: http://drupal.org/licensing/faq
Please direct people there when they have questions about the GPL.
--Larry Garfield
Drupal Association Director of Legal Affairs
Jay Batson
Larry -- Drupal includes PHP
Larry --
All this says is that the portion of the theme that executes on the server is tainted by the GPL. It does not say that the theme "as a whole" cannot have some reserved, proprietary IPR. A theme could become commercial (requiring a license to use) based on the inclusion of:
Kent Lester
Simpler theming will require
Simpler theming will require a few tweaks to Drupal itself, but I think these changes would be fairly minimal. Drupal has the potential to be far more modular in its theming. Here are my suggestions:
Definitely ++ on the block
Definitely ++ on the block theming part. On nearly all professional sites there are blocks that need to be differentiated within regions, but as of now it's still required to use contrib modules for this functionality, and many people don't even know these modules exist:
http://drupal.org/project/blocktheme
http://drupal.org/project/block_class
Jeff Noyes
Good ideas. Have you seen
Good ideas. Have you seen Gabor's work on blocks? http://hojtsy.hu/
Jeff Noyes
Interaction Designer
jeffnoyes1@gmail.com
Douglas Tschetter
The best solution I've heard
The best solution I've heard is one Mentioned above by Jan Krummrey.
I can do anything you like with CSS. Give me some semantic HTML and an idea, and I'll style your site. The downside of Drupal is that it takes a while to get the site configured the way you want, before you can really consider the style. A few default configurations would go a long way towards making out of the box themes a more reasonable expectation.
I tend to agree on that
I tend to agree on that too.
Using patterns, We can have something like the following:
Community defined patterns (the gallery pattern, the forum pattern, and so on).
Then we have templates supporting X patterns.
This makes clear design objectives for designers to base their templates on.
And having patterns in the mix would make it possible to have all the necessary modules installed, configured and tweaked in order to have the 'common ground' needed to do so.
My list: Prepackaged,
My list:
Firstly, wow it's so
Firstly, wow it's so positive and refreshing to see how many users are passionate about theming in Drupal.
When i started using open source CMS a few years ago, i started out with a few other CMS but mainly used Joomla. It was relatively easy to build sites with Joomla because of it's limited features and functionality.
Drupal is different in the sense that it is very modularised and pretty much any thing in the theming layer can be overridden. This gave a lot of power to the themer than any other CMS i've used, IMO. However most of this power relies on knowing PHP placed in the template.php file which obviously isn't something Designers want to touch upon if they had a choice. So what i feel will make it easier for Designer are the following:
- To have all the theming settings already in a default drupal theme. Think of Acquia marine or Slate theme (or even Zen) with all the theme settings and configurations but stripped down frontend template so it can act as the base theme to build upon, which means ditch Garland.
- I agree CVS, should be abolished in favour of a simple upload and download feature for contrib themes. I use it only because there isn't any other choice.
- Separate frontend and admin panel. I don't have a problem with the way Drupal is but it will surely make theming less frustrating since at times there are conflicting CSS styles rendered for frontend elements and admin, and it becomes cumbersome having to override css classes each time it happens. This should keep the CSS clean and more manageable. Of course, there are ways to prevent this perhaps by loading certain CSS files using PHP but do we really need to put in that extra work? This separation does not mean you can't still have frontend inline-editing features.
- Agreed with everyone, there should exist more Install Profiles, however they can be too general and building an install profiles take quite a bit of time. So how about a tool to help build Install Profiles tailored to your own needs or community.
I don't have issues and think it's great that people can make a living from selling themes but I think commercial themes should be kept away from d.o since this can create conflicting interests within a community. Even Joomla has learnt this and now everything must be GPL only on their site.
The alternative to install
The alternative to install profiles are patterns.
The limitation of install profiles is that they are used only at installation time. Patterns can be turned on at any time in the site building phase. Many people setup their site first, with a few modules, try stuff on then would like to add, say a gallery, even if there would be a gallery install profile, that would mean redoing another install. Although there are workflows to go around these limitations, Patterns are IMO what is needed as a supplement/alternative to install profiles.
Thomas Moseler
Documentation for
Documentation for Designers
When the D6 theming handbook came out, I was really enthusiastic about it: it had nice graphics, was quite coherently structured, a.s.o. As far as I know it has been mostly the effort of one single person in its basic form.
Meanwhile I see things a bit differently: it's a theming handbook written for developers. It has got the same flaw as other Drupal docs: It cannot withstand the temptation to mention the gazillion options that are there.
This is a fundamental flaw of Drupal itself seen from the eyes of an end user: loads and loads of options, but too little sensible defaults.
So there is a need for a Designers Doc that is _targeted_ at designers.
We need to try put ourselves in the shoes of a Designer that comes to Drupal and may have experience with other CMSes Theme layers or is maybe a pure CSS guy.
What you mainly have to think about is not, what you include, but much more, what you omit. Writing as little as one can, and just as much that is needed.
Really, when you start out, you don't need much. You won't even design a CCK content type with many fields. You just won't. So writing for the 80% comes in.
How little do you need to write a theme? I tried for D6 (older version for D5 also available), run through Google Translate, because it is in German.
http://www.drupalcenter.de/handbuch/17767
Well, sure, it is not true: you need to know more than that. But I think the page mentions (not explains) almost all you need to do your first Drupal Theme. When I did my first theme, I think it did not have much more that header variables, $sidebar_left and $content. But it worked. And it was in Drupal. At that time blocks and regions scared the hell out of me, I just did not use them - and did not miss them.
You can add more variables later, you can do whatever later. But first you need an experience of success, to make possible there is a 'later'.
Having a Graphic design
Having a Graphic design background and only just recently adopting trekking the drupal learning curve, I like the flexibility of Drupal.
Yes! Drupal is difficult to theme at first, but once you overcome the hurdle of learning a little php (phptemplate)fundamentals, I feel there is more benefit in that than shying away from code.
I second helping the drupal.org team make it easier for themers to upload their themes AND/OR help the patterns team make default configurations (including downloading and installing dependent modules) a reality.
This would considerably keep Drupal as diverse and robust as it is, but further enable its diverseness to be a strength and not weakness for designer purists.
My last Drupal theme: 1 base
My last Drupal theme: 1 base theme with 4 sub themes, around 30 theme templates.
If you have a theme which "kinda" works for the front page, and have some basic styling for forums, that isn't really a Drupal theme, is it?
And it could be even more flexible: http://dc2009.drupalcon.org/session/limitations-drupal-theme-layer
Jay Batson
Bálint - Your video is
Bálint -
Your video is interesting. I take it you're basically suggesting mushing XSLT into Drupal? I think I get the implications:
This makes some technical sense. I wonder: would this make it easier or harder to get designers to consider Drupal as their favorite / default platform? It may yet be one more technology cliff they'd have to climb (beyond Drupal, jQuery, etc.)
OTOH, the payoff could be so high that it would attract developers.
XSLT has been more used in the Java world; it didn't seem to "take over the world" there, though. Does that suggest how well / poorly it'd do in the Drupal world? Or do we need so much improvement that this might be latched onto as salvation?
Interesting talk. (It was hard for me to follow; whether it was my player, or the encoder, but the audio & video weren't synchronized.....)
My own experience is,
My own experience is, although very powerful, xslt isn't easy to understand (especialy if your programming background is limited) and also requires a fair understanding of recursion to harness a lot of its power (I might be a bit off on that part...). I basically, didn't have a very enjoyable experience using xslt.
Jeff Noyes
I also think there's just
I also think there's just generally a lot of confusion as to what Drupal is, and why it should be chosen over Wordpress or Joomla. On that note, I personally think it would be very helpful to have a showcase of Drupal sites that reveals how diverse Drupal is. Such showcases exist, but finding them is a chore. Hopefully the drupal.org redesign will help this problem.
Jeff Noyes
Interaction Designer
jeffnoyes1@gmail.com
Thanks for a thoughtful,
Thanks for a thoughtful, honest post. The complexities of theming in Drupal preclude easy answers, but it is great to hear that Acquia is taking on the issue.
I think providing a set of very clean, simple themes to start someone off that can be played with from with Drupal (exposed style sheets through a module) and superb documentation would be a step forward. The marketplace for paid themes is helpful too, but since this is such a free-oriented community, there should be a bundle of free themes available, ones that really offer visual options (not all top nav, etc.).
A contest with real $$s for winners to come up with themes that you might help support might also work.
Another thought might be a theme configurator - let someone start with a theme, then play with its attributes in some sort of engine on your site, and when done download the css files into their site. This could work with the Acquia module.
At this point, whatever you do to extend Drupal's ease of use (documentation) and aesthetic appeal (themes) will do more to extend its use than new programmed features.
Jay Batson
Common ideas so far. Thanks
Common ideas so far.
Thanks all for an excellent start. I'm particularly glad to see a bunch of self-described designers participating. Maybe this can be the start of a (sub)community of designers in Drupal!
In reviewing comments up to today, here's the condensed version of the suggestions (no editorial pen here; just consolidating / summarizing):
I'll edit this post to add any new stuff that shows up in the next few days. This sounds, though, like what I might have expected so far - though the surprise (for me - maybe not Dries & others) is the distaste for needing to submit themes via CVS.
"Some desired pre-defined
"Some desired pre-defined things: blog, magazine (media generally?), forum site, eCommerce, gallery."
+ Brochure site.
I'm a non-technical drupal
I'm a non-technical drupal user with neither programming nor design experience but i've known drupal for quite sometime now and am able to install and set up a basic site using out-of-the box features. From my perspective the design challenge with drupal can be reduced if there is more easy to understand and use documentation in the form of books and tutorials. People like myself are not afraid to dabble into css/javascript/php but I do need to see good practical step by step examples of how some good themes have been set up. Let's face it drupal does have some brilliant websites out there which look really nice but unfortunately when people talk about the process they went through to build them the language used often only appeals to experienced developers and designers like themselves. I would really like to commit myself to the design side of drupal but good books (in addition to the existing ones), video tutorials and affordable training will go a long way in attracting more designers to drupal.
Jay Batson
Bola -- Actually, the last
Bola --
Actually, the last 12 months have been a good year for Drupal books. There are currently over 35 Drupal books listed on Amazon, and several of them are focused entirely on Design.
I for one do want more books, and training. But do you have some specific holes you think are left unfilled from the current suite of Drupal books? We get asked by publishers all the time to help with new book titles; if there are holes, we can find ways to fill them.
I won't pretend, at all, to
I won't pretend, at all, to know all about the various Drupal books, but it seems to me it would be helpful to have additional books for Drupal designers/users who will never need to install Drupal -- i.e., they're going to work on an existing site created by another team or developers (the situation for a big university site, say, or many company/nonprofit sites) -- but who want to do things like the following:
create a new content type
create views
actually make them look like the rest of the site and fit in with an existing design
So a book that really gets into creating new content types, new views, and the theming of both (yet doesn't delve at all into installation issues, etc.).
I recently picked up "Front End Drupal," which I'm hoping will help in this regard.
Johnny van de Laar
In our blog at Internet
In our blog at Internet Unlimited we once discussed several changes that would be helpful for theming (the blog article is in dutch so I didn't link it).
One of the things that will help a lot of themers is a repository with little snippets that they can include in their template files. Like a repository to change the primary links menu, etcetera.
Ofcourse there already are the handbook pages, but searching on d.o is awful. You'll end up with articles about drupal 5 that will not work anymore in drupal 6, you'll have to search through comments that might suggest a solution which might work but actually is a very ugly solution etcetera.
it would be better if there was a page like api.drupal.org is for developers that only contain small snippets with some extra documentation for designers/themers. this would help starting designers/themers a lot with building their templates.
--
Internet Unlimited
I say give the user
I say give the user something simple but elegant and "good enough" to start with (Garland is not that: it was made for the admin screens, not for a website, Acquia Marina is much better but still not there). Something that he'd use for his site right away but at the same time would feel easy to customize, even just a bit (add a logo & change the colours). There must be a couple of nice and simple themes right in the core distribution. User has to start out with a simple unbranded theme (and please, please, please remove all traces of the hideous blue alien!).
I think that some of the most successful "seed" themes out there are Dave Shea's & Michael Heilemann's themes for Wordpress and Douglas Bowman's themes for Blogger. They are minimal, they use nice typography and subtle graphic elements and (most of them) offer room to grow. I also think part of their success was on the marketing level: hire a cool designer to make a great theme and the rest of the designers will follow.
Now these themes were all targeted to simple blogs while Drupal is a different beast. Creating different themes for different purposes sounds like a great idea. However, to offer a usable starting point for a specific purpose you'd probably have to use a couple of extra modules (CCK and Views as a minimum) and you'd have to start with some purpose-specific content types with appropriate fields. So it will probably involve more than a selection form a list of available themes.
Jason Reed
Wow- a lot of great
Wow- a lot of great commentary here. I'm excited for the Drupal community- the efforts being made in both attracting designers and improving usability are huge.
As a designer who is pretty new to Drupal and the Drupal community, I'd like to think that I have some perspective in terms of what challenges face designers considering using Drupal.
I'm not sure that a lack of available themes is a priority issue for designers/front-end web developers, as I (and I think other designer/front-end types) would typically never start from a theme. If they did start with a theme, it'd be one specifically meant for branching off- a clean, simple theme that designers can use to both learn Drupal theming and provide a starting point beyond ground zero (as described above by George Terezakis).
That being said, I think having a place where designers could congregate around (and be inspired by) great Drupal themes would help promote the idea that great design and Drupal are not mutually exclusive. By the same measure, I think it'd be critical to have a directory of great Drupal sites, to show the design community (and the web community as a whole) what sort of crazy and wonderful things can be done in Drupal. (As an example, 16 Different Clones You Can Build with Drupal.) Designers need to see that Drupal theming not as challenging as they may think, and that some clever and wonderful things can be done with Drupal.
In my opinion, the biggest hurdles designers face are ease of theming and Drupal's usability. I know that what turned me away from Drupal initially was the fear that my clients would have a hard time using Drupal to manage their site. If I had to spend a lot of time walking clients through managing content, or if I had to spend a lot of time providing support for the platform I chose, it would be disastrous to both my bottom line and my mental health. Fortunately, Mark, Leisa and everyone else participating in d7ux are making great headway in this area, so I'm going to focus my comments on theming.
Any system- Wordpress, Expression Engine, etc - all have their own way of doing things, so I don't really believe that this is a huge hurdle. I've never created themes/templates without having to dig in at some level. Johnny van de Laar's comment about a simpler API makes a lot of sense.
Well, Wordpress templates aren't accessible from Wordpress itself. Expression Engine allows you to edit templates within EE, but I never liked that approach. Personally, I prefer using applications tailored to code editing such as Coda or CSSEdit. I think most themers would probably approach the initial heavy lifting of template development with tools that make writing code and styles most efficient.
I can't speak to what does and doesn't make sense for people learning a new platform, but I would consider this a secondary concern.
I agree here- with the launch of D7 there needs to be a serious push from the community to show how much Drupal has grown.
One advantage that other platforms (Wordpress in particular) have is the perception that there are more resources aimed at designers. Any given visit to Digg will likely turn up ten times more links to Wordpress resources than Drupal resources. I'm not sure there's a clear and easy solution to this, but I think it takes a community effort to move perception of Drupal forward.
Another improvement I think the community should consider to ease designers/front-end developers' pain would be to improve Drupal's markup approach. Things like class="block block-block" and 'divitis' can really frustrate front-end developers. I would really love to see Drupal be the obvious first choice for developers who care about web standards, semantic markup, and accessibility, but that's probably a whole other topic of discussion. :)
gaus surahman
Hi, Jay, We at Acquia are
Hi, Jay,
You don't have to do that for me, I am reaching you. Sorry, gotta be serious this time. Yes, there are two motivations in my part, as a designer, when I started to contribute my themes to drupal: giving back to the community and the lack of OTS themes about which I find so many end users complain. I just hope I have enough strength to go deeper into drupal to produce much better and more usable themes.
Jay Batson
It's great to hear you're
It's great to hear you're putting in the effort, Gaus. We need more people like you! Thanks. :-)
Hi all, "Code entanglement"
Hi all,
"Code entanglement" not only for Designer, also for Customer(main problem).
I buy a Wordpress theme, I active it and get what I want (just some few options, like setup the right categories). But in Drupal, there's different. Some Drupal sites use Views, some use CCK, or only Block.
If I build a Premium Theme, what should I build for ? build it base on all default Drupal install ? then the theme will be very simple, just like a container.
give one example, a magazine theme (http://woothemes.com/demo/?t=34)
In Wordpress, we use Custom field for image thumbnail
Also in this site < hard code with WP SQL
all Premium Theme do that in SAME way. and no other way to do that.
easy active it, this is "look like you want it to".
In Drupal, images thumbnail can be imagecache, image upload, CCK upload ..... many modules
"Also in this site" < using a block? CCK? a Views Block? (different module, different theming way)
active it, this is NOT "look like you want it to".
As Drupal flexible, We can't limit Customer in one way. and it's no value to pay for a theme container only.
Kevin Quillen
The biggest gripe from our
The biggest gripe from our designers is the amount of HTML returned by Drupal causes them to redo parts (sometimes all) of the approved comps. For instance they create a block callout on the right hand side of the page. Without a CMS, you could easily do this with a container div with content. Add in Drupal, and you may get anywhere from 3 to 12 nested divs before any content is output, depending on how that content is placed there (block, views, panels, views + panels, etc). This in turn makes them have to do more work by making the CSS very specific, and also have to monitor IE6 more often due to higher usage of divs/containers. As programmers, we get a lot of grief for this. I feel this also is why themes are very bland and basic from sites that offer up lots to download.
My answer for that to them was to learn the theme_ hook system, as sometimes you can override the output and tweak the result. They can also feel free to create their own block or node tpl, or if using Views, create their own template. However, I get more grief then because they feel they have to learn how to 'program' just to complete a design/layout.
I think the methods of theming need improvement, not necessarily how or where to find premium themes. A lot of web firms (myself included) don't use ready to use themes because we have graphic designers do them.
Also, if they ever do put a in-system template manager (edit theme in Drupal) hopefully its optional and can be turned off. We use Subversion and I can imagine that would cause some headaches.
==============================
http://twitter.com/kevinquillen
http://www.inclind.com
http://twitter.com/inclindinc
Jay Batson
Kevin -- This is an
Kevin --
This is an oft-discussed topic in the Drupal community, and there are people passionate on both sides of the discussion. On one hand, one group of people (oft called "Markup minimalists") cry for much less specific markup by Drupal - fewer nested classes/divs, and less complexity (e.g. your blocks/views/... issue).
On the other hand, there are those who say "More markup is better, so we can target exactly what we want with our styling."
There may be an approach on the way that comes at it from an orthogonal direction: The skinr project. While this project is in its infancy (e.g. not well documented yet), this may provide a different way of thinking about the styling - and as I understand it, it's best experienced in conjunction with the studio theme pack. It may take some digging to figure this out, but there was lots of excitement at last weekend's Design4Drupal event, particularly from designers who are always needing to do rework of themes based on comp changes. Note also that I know of at least two other Drupal shops that were working on basically the same solution that skinr provides, and once they saw skinr they immediately jumped on folding their work into skinr. One of these two shops is a premium theme shop, and they really saw the leverage of this. (You might ask about skinr in #drupal-design in IRC. Look for the module maintainer - jacine).
In addition, there's been some interesting work going on to allow more granular theming of drupal_render'ed elements. While this is more granular in one sense, it actually may provide a way to address some of your issues in an orthogonal way.