We're proud to release our latest Drupal theme Pompano, a general use responsive theme (of course) that brings a couple new bits of jQuery fun to the table: Infinite scrolling on views using the...
For awhile now I've been thinking about putting together and releasing an official ThemeShark framework . Branded frameworks are very popular within the Wordpress and Joomla premium theme community at the moment , and it seems like all of the big name theme developers have rolled one out at some point. So should ThemeShark do the same for Drupal?
Maybe we should. It could certainly generate interest and bring in some extra business, and it would probably make the updating the themes to the lastest version of Drupal a bit easier. But here's the thing: it seems to me like it'd be a bit redundant at best, and a self-indulgent waste of time at worst. And I'm just not convinced that anyone would really care.
For starters, there's no shortage of theming frameworks already available on Drupal.org . You've got Zen, Omega, Fusion, and AdaptiveTheme, just to name four of the most popular. And they're popular for a reason: they're all very, very good . So what could ThemeShark possibly add?
The second reason I'm hesitant to build a framework is because I never use them myself. Currently all of ThemeShark's drupal themes are built upon a very straight forward, simple starter, because that's just the way that I prefer to work. It seems to me that theme frameworks can be subject to a lot of bloat. Is it really necessary to include idiot proof toggles for every little element? If you don't want the the links to display on node teasers, for example, it takes a few seconds to chop them out of node.tpl.php. Are an additional ten to twenty odd lines of code really necessary for such a simple task?
Because the vast majority of Drupal's users aren't new to HTML, CSS, Javascript and PHP, and because many are seasoned developers, I can't help but think that adding a bunch of settings onto the backend is largely unncessary. And no one's buying a ThemeShark theme to abandon the design and start from scratch anyway - I very rarely see sites using our themes that deviate significantly from how the theme appears on its demo.
So, then: here's what I've ultimately decided. There'll be no ThemeShark framework. Instead I'm currently building a new starter theme, inspired by several different boilerplates. It will mark our move from XHTML 1.0 Strict to HTML5, and incorporate a responsive 960 grid (more than being a marking buzz word, a responsive grid layout truly does seem to represent the future of web design - or at least for the next couple of years). Theme Settings will be sparse, simple and efficient, and retaining a few that will be familiar to those already using our themes, and it won't be publicly released, unless I decide that it's especially useful or brings something new to the table that the dozens of other GPL starters don't.
But I'd like to hear what others think, so feel free to share your opinion in the comments. Maybe by the time Drupal 8 is released I'll have re-evaluated the situation, but nah, probably not.
We're proud to release our latest Drupal theme Pompano, a general use responsive theme (of course) that brings a couple new bits of jQuery fun to the table: Infinite scrolling on views using the...
Back at the end of 2007 I took note that there were very few premium Drupal theme sites, and I started working on learning the platform and Drupal theming methods. I hadn't used Drupal prior to...
Presenting our March Theme, Atlantic! This is a super clean corporate flavored theme that uses almost pure CSS3 to get the job done - it's fast and responsive and search engines will love it. As...
I agree that Drupal already has some great framework themes and does not need another. However, I, personally, think utilizing a community supported base theme is the way to go.
My advice: Omega - Responsive HTML 5 Base Theme.
There are a wide array of reasons I think embracing a base theme, such as Omega, is the way to go. For example, it allows for better community collaboration and contributions. Also, by joining forces with a community around a project, we can reduce redundancy and multiply efforts. And, from an end user's perspective, it is extremely helpful to have standards (i.e. if I learn about the Omega Base Theme, I will feel comfortable with all your themes and other themes based upon Omega... rather than learning each individual's preferred method/approach).
To be honest, now that Symphony Themes has embraced the Omega Base Theme, I am more inclined to use their themes for my future projects.
The momentum is moving towards Omega, in my opinion, and I think its got HUGE potential. Consider that it has skyrocketed to nearly 20,000 users in the past year... and even Acquia.com, Dries Buytaert's company, is using it for their site.
Anyway... you asked for opinions, so there's my two cents.
On a separate note... thanks for all the Kick-Ass Themes!
Thanks for your feedback! I think maybe it was you who brought Omega to my attention initially. But I may have some disappointing news for you: ThemeShark won't be using it. There's a few reasons, but it's primarily because I'm trying to minimize any dependency on 3rd party/community contributions. That may sound odd, but I can explain why. There's no doubt that Omega has picked up a lot of support lately, and I definitely did consider it for the reasons you've outlined.
But I also have a personal preference for simplicity as well. The size of the premium Drupal theme market (relatively small) means I'm forced to streamline things as much as possibly can. The vast majority of ThemeShark customers aren't developers and often brand new to Drupal entirely - and they never touch the nuts & bolts of a theme - therefore I'm interested in making things as intuitive and user friendly as possible. There's the matter of support: I currently spend a huge portion of my time solving problems that aren't related to our themes, but to Drupal and popular 3rd party modules in general. Omega would bring with it a whole lot of options and settings I'd then be responsible for troubleshooting, because I make the effort to solve problems internally instead of deferring to the Drupal community. Telling a customer, "That's a problem with the Omega theme, go ask them" would most often go over quite poorly, and rightfully so. I also don't think it's particularly fair to the maintainers and contributors.
So hopefully that makes sense, and you can see that I have real reasons for not choosing the Omega path. Though I'll be working from a starter (that won't be released, because I agree, it's redundant) our future themes will continue to be stand alone. In a few days I'll post a rundown of what to expect from them.
That makes a lot of sense Rob... thanks for the reply!
Post new comment