Posted by ChrisBryant on March 2, 2007 at 7:57pm
Hi Everyone,
I just wanted to write in and link to Steven's excellent post titled "Drupal's Designer Future" in case you didn't see it:
http://acko.net/blog/drupals-designer-future
Let's work together to make Drupal better for designers! There is a lot that can be done that will make our lives easier and benefit the entire Drupal community. It's not an easy task, but let's figure out a game plan and priorities to get some enhancements done now so they can be included in the next release.
Your thoughts?
PS: I've cross posted this to other relevant groups, sorry if you feel it doesn't fit in your group.
Comments
Thanks for the link. I have
Thanks for the link. I have a rather long winded response on Steven's blog so I wont say much here other than I think the problem isn't in Drupal as much as the community around it. Yes, things could be easier for designers but there should be more of them involved as things stand now. Drupal simply does not have the traction in the design community as it does with php developers. That needs to be fixed by changing the community mindset and DNA more than anything else.
Rick
Lets hook up at oscm
How many designers are attending the drupalcon? -woudnt it be an idea to gather for a beer or something and try to figure something out - what we could do together?
/morten.dk king of rock
/morten.dk king of rock
morten.dk | geek Royale
Design is sublime, UI is social
I have deviated from my design career a few years back because I was inspired by the community driven environments and new media model of many-to-many communications that were emerging. I felt that THIS needs to have it's foundation in society and replace the few-to-many model. It is an artifact of the transition that coders are dominating this environment right now. Designers in the past have been held in bondage by the choke-points of huge media conglomeration. The business model of big media more and more took the conversation out of 'we the people through freedom of press', and made design only skin deep. The functional half has manifested itself in the code development outside of that model, where now we are seeing the doorways to a healthy communications sphere with designers and coders on either side, each one holding an important enabler of the other.
THIS new environment is being populate by all the right building blocks by coders, and the designers know how to HELP arrange those building blocks into functional artistry. However, it is futile to try and design the "silver bullet" of UI design; that universal design that will enable anyone to navigate any information. The human element stripped by media conglomeration must be built again by local groups adhering to globally relevant and open frameworks.
I think the functional elements of menus and what information is navigable by those menus and links has to be a product of face-to-face conversation and collaboration. We can not mass produce this revolution.
Artistry will just happen more and more.
“Design for Drupal!”
Many of the arguments in the comments to Steven’s blog were that designers tend not to collaborate. And that they can be difficult for programmers to work with. And that the Drupal community lacks many good designers. Some even said designers are prima-donnas and they don’t know CSS.
But there is a long tradition of collaboration in designing with CSS (note the emphasis.) To think that CSS is the purvey of coders is incorrect. The current state of CSS design techniques is entirely built on collaboration. Designers may go off into a corner to work for a little while, but they come back and share!
Rick’s argument that “there should be more of them involved as things stand now” is exactly the lament Steven was making about how “for years now, the Drupal community has been hoping for a group of prodigy designers to magically appear.” I believe we don’t need more designers; the Drupal community already has the right people to make Drupal designing better.
And there’s a lot that could be done to make themeing easier and better understood in Drupal.
<?php ?>can be scary.)What we need is a single entity to be THE clearinghouse for brainstorming and implementing improvements to Drupal’s themes. And there’s every reason why this very Theme development group should be that entity.
Maarten rightly suggested that the Designers group should be working on new Drupal themes. But, as tim brilliantly pointed out Designers have been previously prevented from designing UI because of the murky technology and…
So there is no reason why the Theme development group and the Designers group can’t be collaborating. The natural “place” where coders and designers are meeting is CSS. And, the CSS community at large is already a mixture of both; Drupal should be leveraging that. The themers and designers groups need to be working to make Drupal’s themes spectacular!
Steven’s article should be the catalyst for a new rallying cry in the community:
“Design for Drupal!”
- John (JohnAlbin)
I have to agree...
In truth I'd have to agree.
I have thus far been rather disappointed with most of Drupal's themes (only finding one I really liked this morning and can't try it out due to my website being stupid). I have spent about a month trying to get a certain theme (Warped) working for 5.1 and working for a left sidebar with no CSS or PHP experience. So far it has taught me that CSS is hard but somewhat easy to learn and PHP is a monster than I really need to study. But in the end I got it basically the way I wanted with mostly either searching through Drupal's forums or just testing specific things out myself.
In the end this whole process makes me want to learn all this stuff just so I can make a easy theme to pop in some simple CSS and let the theme worry about the rest. So basically I guess that would mean yo have another person who is going to work their way into trying to design themes for drupal from the ground up (with little experience myself... wish me luck).
There's still quite a bit I
There's still quite a bit I find difficult to change about Drupal when theming. Designers like details. Details are what make something special and it's our attention to them that helps define what we do. Unfortunately, I still can't figure out how to separate $content into something like "$body" and "$comments" and how to separate $links easily so that I can place "Read More" at the end of the last sentence of a teaser or put the links at the top of a post, or any number of small details that really make the difference.
These are not things that can just be dealt with using CSS. CSS is not a designer's best friend because it doesn't let us easily make these kinds of changes. Things like these required PHP-wizardry that gets many designers (or, at least, myself) overwhelmed. The control over what elements can be placed where within the theme just doesn't seem granular enough. Simply including "$content" in my phptemplate theme will not suffice and is part of what makes a Drupal site feel like a Drupal site.
(p.s.: I read somewhere on the site that Drupal's future also possibly lay in the use of fields, not nodes. This seems to be the way it's headed and I hope its done well in Drupal 6 because it could add the granularity that's needed to create truly unique designs.)
Unfortunately correct.
You are absolutely right. There are quite a few details that are really difficult, or even impossible to get at. Separating the comments out is right up there on the AUGH HOW THE (&() DOES THIS WORK scale.
The absolutely most popular post on my blog is the post telling people how to move the readmore link around.
Though moving the links above the post isn't too hard.
The good news is that it's something there is work being done on, but be prepared; figuring out a good way to do this is hard. Either it's too complicated or too slow or not flexible enough (or some hideous combination of the above); trying to find the right middle ground is very tricky. Hopefully Drupal 6 will be better.
I'm a developer doing my
I'm a developer doing my first theming job ever! I agree that the theme layer is definitely set up for more of a developer. To do the things you talk about, you need to edit variables in _phptemplate_variables() and that is not completely easy for everyone.
On top of that, you can't do everything in _phptemplate_variables() yet people tend to say you can. It wont fire in certain areas (like admin/build/block) so then I find myself building a themename_init() and executing it at the bottom of template.php which I don't really like doing.
I wish template.php could handle module hooks though :P (hook_init which would solve what I state above)
In a week or 2 when I finish this first theming job, I'm going to write up a blog post (which is something i NEVER do) which will have some snippets and etc explaining how I did things on this job, why, and etc..
Maybe it can help ya out.
Now to solve the problem and make things easier in the theming layer.. I have no answer for that. It's kinda hard to say. It's not an easy thing to make easier other than setting up more pages in admin/ which give you control but then you have the UI problem drupal has.
I doubt Drupal 6 will have much to solve this but I bet after another year or so of jQuery being around, you will see a drastic improvement.
Slowly people are finding more ways to use it to make a simple task that takes longer than it should much faster.
Next year's SOC should have a rule that all entries must focus on Drupal core UI :P
My Solution
Separating the contents of the
$contentvariable was something that I was looking to do also at theme level for complete control over my page layouts, and so I thought I'd share the solution I normally resort too (this it for Drupal 5+). I assure you that complete control over drupal content is achievable! I don't know if it's good/bad coding form - but it works for me!!!N.B. this could just be one field called 'description' if you just wanted something to replace the body field.
Now at node theming level you can create a node-product.tpl.php file and use whatever the field variables are rather than the awkward
$contentvariable. Your field variables will be something like$node->field_detailsor$node->field_specifications. You can see what these will be by accessing the field list page: administer > content types > fieldsSo at theming level, instead of
<div class="content"><?php print $content?></div>you could have
<div class="product-details"><?php print $node->field_details[0]['view']?></div><div class="product-specs"><?php print $node->field_specifications[0]['view']?></div>
<div class="product-order-info"><?php print $node->field_ordering_information[0]['view']?></div>
For complete control over layout. It'll take some playing around with, but I find it allows me to completely control my layouts. Need some more help? Try sticking this code in your node.tpl.php ot node-xxx.tpl.php file:
<?php$node_arr = get_object_vars($node);
while(list($i, $j) = each($node_arr)){
print $i .' - '. $j .'<br />';
}
?>
for a complete breakdown of the $node object.
Happy Theming.
Some thoughts
laurenh, I can't speak for the community but it's been my observation that the issue you're describing is well understood. It's one of those classic difficult problems with no easy answers (except in hindsight!). I offer the following comments, for what they're worth:
Views and CCK, to name just two projects, demonstrate the developer community are more than happy to remove themselves from the middle. The current situation with theming isn't from a lack of will and there are a number of projects like Themer Pack and Content Template that are actively trying to make theming easier.
A lot of the granularity you want is already there, but you need PHP and some specific knowledge of how Drupal does things. Links and most body information is totally manipulatable from this perspective. That said, from a pure designer and/or non-programmer perspective, it's complicated enough that it's effectively out-of-reach. Strategies for dealing with this from a non-programming designer perspective might make an interesting discussion all on it's own.
Theming has improved over time, and based on project activity will continue to get better.
If you have ideas on how you'd like to see the functionality work, I'd encourage you to contribute. For example, flagging a CMS application that does layout well or ideas on screen layouts/techniques. I think the design is the hard part of this problem.