Rapid Theme Development was: Re: [development] Administration Survey: Theme improvements, theme help system, theme mailing list
Sorry for the cross post - but I thought I would move this discussion to the theme list.
Dries Buytaert wrote:
Having to create a Drupal theme really turns me off.
Making it easier to create a unique, good-looking theme in a matter of hours is a key challenge for the Drupal community.
Well - the 90-10 rule applies. I get get 90% of a theme done very rapidly and have a pretty good looking site at the end of a short session (i.e. matter of hours). But, its that last 10% that takes 90% of the time. All the special cases - all the different forms - different node types - different 'sections' of a site that require a different look etc. All the tiny annoying little bumps that require ironing. That's what's a pain in the ass.
But, most of this is unavoidable. This time consuming stuff isn't the fault of the themeing engine or the templates... its the natural result of people wanting to modify things because they don't want a 'stock' vanilla looking elements. They want to mod almost every detail - and that kind of modification takes time.
And also keep in mind that some of these mods that make a site look 'unique' aren't just simple theme overrides - they are hacked and modified modules - that become completely new modules and/or new functionality contributed back to core modules.
andre
___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
On 12/13/05, andre mcsparkerton@yahoo.co.uk wrote:
...
And also keep in mind that some of these mods that make a site look 'unique' aren't just simple theme overrides - they are hacked and modified modules - that become completely new modules and/or new functionality contributed back to core modules.
Amen.
Robin
andre
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com _______________________________________________ themes mailing list themes@drupal.org http://lists.drupal.org/mailman/listinfo/themes
-- Robin Monks, CSL Web Administrator robin@civicspacelabs.org
andre wrote:
Well - the 90-10 rule applies. I get get 90% of a theme done very rapidly and have a pretty good looking site at the end of a short session (i.e. matter of hours). But, its that last 10% that takes 90% of the time. All the special cases - all the different forms - different node types - different 'sections' of a site that require a different look etc. All the tiny annoying little bumps that require ironing. That's what's a pain in the ass.
I think half of the problems I encounter themeing different drupal sites is with the different modules. Every single developer out there wants to code something in one way or another. And they all want to use page breaks (<br /> [yes, that is the proper way you print out a "<br>" people!) in places where you, the themer, might not necessarily want them. So if you are themeing all the different form elements, you are constantly scrambling for different classes and ID's to try and theme a particular form to look a certain way.
I honestly don't understand why there isn't, and wasn't, a common set of practices decided on long ago for people to use when building modules. I am thinking that's what this new "forms.api" stuff I keep hearing about is for... I'm not sure.
The biggest bulk of a Drupal themers problem is, you typically can't just theme, all generic selects, inputs, etc. You have to specifiy certain elements and my gosh, there can be tons and tons and tons of them. Ending up with a nasty huge giant amount of CSS.
Dries is right, it shouldn't be this hard to theme. I should be able to theme the header, sidebars, footer, content area, select, input, and a few other things and be done. But that is not the case.
Before anyone goes asking me to patch something, I do graphics, and know CSS. I don't code. So, no, I can't "submit a patch"[tm]
Trae
But, most of this is unavoidable. This time consuming stuff isn't the fault of the themeing engine or the templates... its the natural result of people wanting to modify things because they don't want a 'stock' vanilla looking elements. They want to mod almost every detail - and that kind of modification takes time.
And also keep in mind that some of these mods that make a site look 'unique' aren't just simple theme overrides - they are hacked and modified modules - that become completely new modules and/or new functionality contributed back to core modules.
andre
___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
On Tue, 2005-12-13 at 09:37 -0500, Trae McCombs wrote:
andre wrote:
Well - the 90-10 rule applies. I get get 90% of a theme done very rapidly and have a pretty good looking site at the end of a short session (i.e. matter of hours). But, its that last 10% that takes 90% of the time. All the special cases - all the different forms - different node types - different 'sections' of a site that require a different look etc. All the tiny annoying little bumps that require ironing. That's what's a pain in the ass.
I think half of the problems I encounter themeing different drupal sites is with the different modules. Every single developer out there wants to code something in one way or another. And they all want to use page breaks (<br /> [yes, that is the proper way you print out a "<br>" people!) in places where you, the themer, might not necessarily want them. So if you are themeing all the different form elements, you are constantly scrambling for different classes and ID's to try and theme a particular form to look a certain way.
I honestly don't understand why there isn't, and wasn't, a common set of practices decided on long ago for people to use when building modules. I am thinking that's what this new "forms.api" stuff I keep hearing about is for... I'm not sure.
The biggest bulk of a Drupal themers problem is, you typically can't just theme, all generic selects, inputs, etc. You have to specifiy certain elements and my gosh, there can be tons and tons and tons of them. Ending up with a nasty huge giant amount of CSS.
Dries is right, it shouldn't be this hard to theme. I should be able to theme the header, sidebars, footer, content area, select, input, and a few other things and be done. But that is not the case.
Before anyone goes asking me to patch something, I do graphics, and know CSS. I don't code. So, no, I can't "submit a patch"[tm]
Trae
But, most of this is unavoidable. This time consuming stuff isn't the fault of the themeing engine or the templates... its the natural result of people wanting to modify things because they don't want a 'stock' vanilla looking elements. They want to mod almost every detail - and that kind of modification takes time.
And also keep in mind that some of these mods that make a site look 'unique' aren't just simple theme overrides - they are hacked and modified modules - that become completely new modules and/or new functionality contributed back to core modules.
andre
One of the things that often buggers me theming drupal, is modules that randomly append their output to node->body... I like having their output, but in a sensible way that will work with my theme.
Its easy enough to override the theme_* function, but I still have no control of how they are ordered when they're attached to the node. Same with links in a way.
I've been toying with the idea modifying modules to write to $node->html[modulename] instead of node->body so I can have better control of where their output is placed and whether it is displayed or not in different contexts... The a template engine can use a foreach($node->html as $key => $value) { $content .= $value; }
before passing it to its theme...
and if you could do something like array_sort($node->html) You could have finer grained control through the ui for managing output added by modules.
If this is a completely absurd idea, please someone knock sense into me.
On Dec 13 2005, at 02:36 PM, Darrel O'Pry wrote:
and if you could do something like array_sort($node->html) You could have finer grained control through the ui for managing output added by modules.
If this is a completely absurd idea, please someone knock sense into me.
Wasn't it the point of blogs and CMS to separate design and content from the code? If anything, Drupal needs to have some sense knocked into it ;-) OK, that was a bad joke; with all seriousness though, I believe Drupal needs to have core and module developers working with themers on design and UI issues before launching off a new version of the software.
Boris' comment does not take into consideration the need for humongous budgets or allocation of man-hours that go into theming sites like netsquared. I have no idea what happened to the new Air America Radio launch but supposedly the job was monumental.
MovableType and WordPress did away with the sapping of resources for design and development. It's as if Drupal is trying to turn back time. There is really no honor in saying, "well, it's difficult so I'll make more money as a developer". How many developers are right now pouring millions of dollars into the coffers of Drupal for further development? Because that is what happened to MT (pre-VC money) and now to WordPress. They're not doing shabby because people are more than happy to give back or pay for something they know will be easy to maintain. And Yahoo! completely understands the importance of 'ease' in the development of new markets.
I'd like to see something as simple as each module having it's own div tag id so that if I need to change a form in one module, it will not wreck havoc in ALL forms. Also, I find it really problematic that I cannot change the help text on each module because it is encoded. But more importantly, the fact that I have to have advanced knowledge of PHP to customize templates and themes is, well ... it's really a step backwards in terms of design.
This is what I wrote on an earlier email that didn't go through :
If there is one thing Drupal could spend a year sorting out and optimizing is this : Completely separating design from the code; especially when it comes to modules --whether they are contribs or core.
SNIP
I've seen Trae's designs and his CSS rock. Good CSS design and development is extremely difficult to do when you are especially considering issues of backward compatibility. Why would it be expected of him --or any other theme designer-- to know advanced PHP AND CSS (in that particular order) to customize their templates?
Drupal has amazing potential, as I have said before, and I am using it because CivicSpaceLabs sold me on the idea. But please, understand that, Drupal needs to spend at least a year working on design alone --and you can't do that if the code is constantly changing and the specifications for a quasi-bug free site keep changing by the week if not by the day. Not because that's the way it should be but because that is unfortunately how Drupal has been developed --design is way too intermingled with the code.
Trae is supposed to be working on making themes easier to implement, redesign and customize for CivicSpace users. I honestly believe he has a point.
Best, liza
/msg liza that $50 buck check is in the mail...
ooops. :)
Is this stuff hard? Yes, CSS is a PITA. But... I think half the time we (themers) have to fight the structure of the html 2 or 3 or 10 times in a battle of a theme because you are constantly pushing and pulling elements here and there. (I'm in a heated battle right now with @#%!$%#%#$%#@$%#$% forms, labels and crap ugh)
It probably doesn't help me to reply to these things when I'm super frustrated while working on themeing design.
It's too bad we can't get 2 or 3 people employed full-time to sit down and sort these issues (with the support of the community and feedback of course) The problem is, between trying to make money to feed your family, and working on Drupal community issues, it's easy to just work with what we have and push the other things back.
I have no idea what I'm saying right now...
Am I the best CSS person on the planet? No. Do I have a full clue? No. Am I 100% certified in all proper CSS technichs and whatever? No. But, and here is the sad thing, I feel I know probably more CSS than 95% of the people out there. (And when it comes to doing this stuff, a lot of time it's just hit and miss on getting things done correctly)
Sure, I know CSS well enough now to narrow things down to a very close scope to work on. But what happens, and what I keep finding is the problem is... it's like pulling cards from the bottom of a house of cards. You gotta be danged careful, or the whole thing will come crashing down on you. That's not the right analogy... :/ More like, pull here or push there and it effects something somewhere totally unexpected. ie. some module or some table or some thing somewhere else that it was unintended to mess with.
Someone give me a cup of happy happy joy juice! Trae
Liza Sabater wrote:
On Dec 13 2005, at 02:36 PM, Darrel O'Pry wrote:
and if you could do something like array_sort($node->html) You could have finer grained control through the ui for managing output added by modules.
If this is a completely absurd idea, please someone knock sense into me.
Wasn't it the point of blogs and CMS to separate design and content from the code? If anything, Drupal needs to have some sense knocked into it ;-) OK, that was a bad joke; with all seriousness though, I believe Drupal needs to have core and module developers working with themers on design and UI issues before launching off a new version of the software.
Boris' comment does not take into consideration the need for humongous budgets or allocation of man-hours that go into theming sites like netsquared. I have no idea what happened to the new Air America Radio launch but supposedly the job was monumental.
MovableType and WordPress did away with the sapping of resources for design and development. It's as if Drupal is trying to turn back time. There is really no honor in saying, "well, it's difficult so I'll make more money as a developer". How many developers are right now pouring millions of dollars into the coffers of Drupal for further development? Because that is what happened to MT (pre-VC money) and now to WordPress. They're not doing shabby because people are more than happy to give back or pay for something they know will be easy to maintain. And Yahoo! completely understands the importance of 'ease' in the development of new markets.
I'd like to see something as simple as each module having it's own div tag id so that if I need to change a form in one module, it will not wreck havoc in ALL forms. Also, I find it really problematic that I cannot change the help text on each module because it is encoded. But more importantly, the fact that I have to have advanced knowledge of PHP to customize templates and themes is, well ... it's really a step backwards in terms of design.
This is what I wrote on an earlier email that didn't go through :
If there is one thing Drupal could spend a year sorting out and optimizing is this : Completely separating design from the code; especially when it comes to modules --whether they are contribs or core.
SNIP
I've seen Trae's designs and his CSS rock. Good CSS design and development is extremely difficult to do when you are especially considering issues of backward compatibility. Why would it be expected of him --or any other theme designer-- to know advanced PHP AND CSS (in that particular order) to customize their templates?
Drupal has amazing potential, as I have said before, and I am using it because CivicSpaceLabs sold me on the idea. But please, understand that, Drupal needs to spend at least a year working on design alone --and you can't do that if the code is constantly changing and the specifications for a quasi-bug free site keep changing by the week if not by the day. Not because that's the way it should be but because that is unfortunately how Drupal has been developed --design is way too intermingled with the code.
Trae is supposed to be working on making themes easier to implement, redesign and customize for CivicSpace users. I honestly believe he has a point.
Best, liza _______________________________________________ themes mailing list themes@drupal.org http://lists.drupal.org/mailman/listinfo/themes
Most of the trouble with forms comes form strange choices in drupal.css, and also the default form_*() functions behaviour of not letting labels be on the same line as the text box.
Another thing is that what gets printed inside page $content area isn't standardized across modules. It could have a div class="node", it could be a collection of random tags..
Maybe modules that print out custom node types should behave more like blocks when they are printed out and have class="node node-$module"?
The valid html vs. xhtml, and hardcoding markup in module output is a bigger issue beyond just being able to theme clearly and easily.
Op woensdag 14 december 2005 00:26, schreef Rowan Kerr:
Maybe modules that print out custom node types should behave more like blocks when they are printed out and have class="node node-$module"?
I have tried, but gave up. http://drupal.org/node/23584
Op dinsdag 13 december 2005 20:36, schreef Darrel O'Pry:
$node->html[modulename] instead of node->body so I can have better control of where their output is placed and whether it is displayed or not in different contexts...
I prefer $node->modulename[structured]->data
That way we can keep the data untill teh very end of the line. One reason for drupals complex theme thing is that we build slices of HTML *all over the place*.
In my ideal world there would be absolutely no HTML anywhere. untill it reaches theme_page. untill taht point we can add/remove/alter a $page Object.
Then theme_page iterates down and builds up teh page by using sub-theme functions like theme_node, theme_block and such things.
This is how Ruby on rails does it, and yes, a lot of ye think ror has its flaws, it most certainly has (aka nothing is perfect) but its output system is far, far, far more flexible/advanced etc then drupals spaghetti-shaped MVC
-
andre -
Bèr Kessels -
Darrel O'Pry -
Liza Sabater -
Robin Monks -
Rowan Kerr -
Trae McCombs