You are hereBlogs / bmann's blog / Form follows function: the growth of Drupal themes will directly mirror the growth of custom distributions
Form follows function: the growth of Drupal themes will directly mirror the growth of custom distributions
Yes, I've also read Morten, Todd, and now All Drupal Themes. Here's my take:
The growth of Drupal themes will directly mirror the growth of custom distributions. We are currently in the "it's so easy, we click together lots of Drupal modules from scratch" phase. Once there are more Open Atrium and ProsePoint type of distributions, with known modules / module options and features, then you can build great themes to support those functions.
Form follows function. I've tried to explain this a million times in the D7 process. Having a "great" core theme is impossible when we don't decide what kind of site Drupal should be optimized for out of the box. This same holds true for trying to build and market a theme that will apply and work well with the many vastly different kind of sites that one can build with Drupal.
Yes, CVS is "hard". Yes, all GPL is "hard". I would argue that the overhead of trying to create infinitely flexible themes for any possible view, module, and block layout is the hardest part. Define your functions, and we'll have the beautifully formed themes to match.
Judging by the current themes status, I'd rather say "Drupal themes won't grow until custom distributions grow".
But yes, the design process only works with specific sets of constraints and *features*. Distributions are key, and I hate myself for not actually working on the Portfolio install profile I've been thinking about for years.
I think there is no single reason why there are so few good Drupal themes, it's death by a thousand cuts, for the reasons explained in the posts you linked, and many more.
Agree with Alex, whatever he means by "vocabulary" (patterns, HIGs, more theme functions?), even if we embrace the distributions path. A shared richer vocabulary among distributions would make for a healthier ecosystem.
By better 'vocabulary' I actually mean additional and improved theme functions more than anything else.
"The growth of Drupal themes will directly mirror the growth of custom distributions"
I don't disagree, but I would add an important point:
Drupal's theming layer needs a better vocabulary.
Right now, we're building all output with theme_item_list(), theme_table(), theme_image(), some of their buddies and a myriad of *custom* theme functions.
In order to build more portable themes, we need to expand our common vocabulary and improve its existing elements.
This will ease the themer's job by driving down the number of possible output patterns that need to be themed and it will make developer's lives happier by improving and adding to the set of theme functions they can use without worrying about the theme breaking and - without worrying about complying with UX best practices.
(I just rewrote one of my modules, I was depressed at how many theme functions I actually had to invent for the backend.)
This: improving the vocabulary we work with, improving and adding theme functions is what for me Drupal UX should have always been about. Instead it was about building a Drupal site.
So I would close with: The growth of Drupal themes will directly mirror the growth of custom distributions AND the improvement of our theming vocabulary.
It's true that the value of a theme can be much higher if you know what it's going to be used for.
For now I'm just building themes that are designed to use Drupals core modules but in the future I will surely deviate from that.
Ubercart should be in your list as well by the way!
Don't forget to list Open Publish and Tattler in your list.
The proof for your statement is already there, by the way. TNT has been doing Ubercart themes with great success - Ubercart = function, form follows.
Morten was inspired by Open Atrium and immediately did his own theme.
Now - the challenge is to align everybody behind the though that optimizing Drupal for specialized distributions is the bright future we're all looking for. This includes optimizing the core development efforts as well as jiggling Drupal.org infrastructure.
DevelopmentSeed is playing the hero role here - long live Features, Aegir and Drush!
Yes, the list should definitely include Ubercart / UberDrupal (the distro). Tattler / Open Publish are (I think, today) a bit more resource intensive and are more likely to be deployed by larger orgs who will customize the look and feel heavily.
(Of course, I say that, and Tattler isn't even available yet :P)
Yes, much work to do on infrastructure.
For it was those wise people who saw this coming, uh, 5 years ago?
Hi Boris,
I hope this hot topic will bring the DrupalOOB experience back on track for Drupal 7. For the people that are interested, here are some important links:
Once the specifications are in place, it's a small matter to create an actual installation profile from it.
There is no one with code skills that seems to want to jump into this, unfortunately. As I said on the wiki, we're in "code slush", and install profiles usually get a pass at this stage, so it's not too late (but getting there).
I still still still don't understand why *designers* aren't jumping up and down about this -- other than those that care always build custom sites too, and also have lost touch with the "little guy" first experience.
Couple of reasons I can think of:
- Designers can't scratch these kind of itches themselves. Jumping up and down hasn't proven to be a succesfull strategy at convincing devs to help out.
- The concept of install profiles is unknown. Choosing between 'Standard' and 'Expert' during installation is hardly enough indication of what's at work there. Where are they? How can you make them? Sure you can find them on d.o. if you want, but I don't think it's generally known what they are and which possibilities they represent.
- Creating a specific use case is not exactly welcomed by core developers who care mostly about generalised, abstracted, reusable implementations.
- Following that, the seperation between the framework and the CMS application on top is a concept more and more people realise is at work here. I'm curious to see how this will play out for Drupal 8, smallcore et al and if it will create more or less room for extra install profiles (in core).
The concept of install profiles doesn't have to be known - no designer that I can name cared about deciding what Drupal should do out of the box.
Perhaps, because the majority of their work is building custom designs for custom websites, which is all about making building and theming easier, but like app developers, could care less about the "little guy" out of the box users.
Oh but we do care. It's just next to impossible to design an explicit use case for core because it excludes all the other ones. It's perfectly possible of course but you won't ever convince core devs of it. And discussing stuff on g.d.o. (I've seen and read your proposal there) is interesting but experience has taught us that any discussion/decision made outside of the queue will be torn down and done all over again once it hits the issue queue.
I guess the Standard and Expert install profiles are not enough to really make a specific use case possible. Same with core themes. We've been toying with the idea of calling out for new core themes for a 'News', 'Social', 'Bizbrochure' and 'Portfolio/gallery' implementation. We'll see what we can do with a theme-specific D7CX.
Default would have a central use case. Expert or minimal or whatever would be the "site builder" profile that doesn't exclude anything. The initial install screen would make this clear.
In my proposal, I've also suggested that even "Default" would have a "full wizard" approach -- that would just install, much as we have today. As well there would be a guided approach - forums, extra roles, etc. would be optional choices. Choosing none of the optional choices would result in a default similar to today, with perhaps some nice additions like a few fields or roles or whatever.
The point being that we showcase some of the extended features of Drupal as a starting point for people to explore further, as well as (for those that want the full auto wizard) provide some great out of the box functionality.
I agree that focusing on (for example) a single user blogging install restricts many other use cases. But then, I also think that such a use case is not a good showcase of Drupal's capabilities and we would be better served choosing something different.
Without focusing on one use case -- and actually TRYING to build it -- we never reap the benefits of focused support for this use case in UX, design, etc. that such an approach can yield.
I started working on install profiles a while back and found packaging up a distro to just be a lot easier (no real learning required). I know install profiles are intended for users who are going to say something like "I'd like a blog from this" but the creation process kinda makes it annoying to do that. If there were some kinda automated scripting process to essentially do something similar to a DB / SQL dump into an install profile w.o. any custom coding to arrive at one I think it would get more people into creating them. Even something more similar to jquery ui's "build a package" feature where you can select checkboxes and it'll download the code w/ all those code packages included. I know there's a billion modules out there but even at that level I think it could really help people get up off the bench and into the game which is a major part of this argument for install profiles right?
I know internally at least we give distro's out to people in a "use this to create a blog site faster" type of format. From working off of other people's ideas too it's been really powerful as a rapid prototyping tool. Not that most advanced drupal users don't know how to configure views and the rest of the funness in settings to get a site where they want it for a "community wiki", but clicking 3 buttons to take me 99% of the way there not only lets me rapidly see what others are thinking but also gets me there much faster then page loads and indy-clicks :).
Sorry, just pumping install profile use cases a bit more..I do agree with your original posting as well that form follows function. I know in our own shop i've been working towards a distro for education and as a result a lot of discussions of "frameworked" (color module-esk) w/ lots of configurable settings based themes are getting kicked around as the way for us to go. Hopefully I'll be able to convince our designer to start putting out some of his work as a result of the distro.
I'm curious though, does anyone else possibly see a need to lower the cost of entry for theme development (however that goes, zip to cvs or whatever) and then have a spot in the info file or even just classification / tagging for a theme to be listed based on what it was intended for? I've seen a lot of people argue "designers don't get paid to put stuff up freely, they make designs for specific clients.." blah blah blah and that that's not applicable to others in production environments, I get it. But even just making a theme for a company selling bike parts (example) and then taking that theme and posting it online and tagging it as "online retailer", wouldn't that help at least in PoC and rapid prototyping for others? Building a site (or listing some possible good distros to use with that theme) would help people get a site up quickly to show it off to someone else and then they can fidget around with getting a theme specific to that company.