although it’s a very powerful CMS, I didn’t have the greatest time with it as it came to be one of the most cumbersome and roundabout pieces of software...
"It was also my first chance to play with Drupal. Unfortunately, although it’s a very powerful CMS, I didn’t have the greatest time with it as it came to be one of the most cumbersome and roundabout pieces of software I’ve ever worked with."
http://avalonstar.com/2006/06/13/flocks-home-gets-a-makeover/
Anyone want to follow up and get some feedback?
Kieran
Kieran Lal wrote:
Anyone want to follow up and get some feedback?
I think the blog post tells you all you need to know:
"Maybe, I’m just too used to how WordPress works." This is clearly someone that is used to working with a different system and found wrapping their head around a new one a bit hard. Lets not forget that WordPress is a blog system, Drupal is a lot more. It's always going to be a bit more of a learning curve.
"there’s quite a learning curve when trying to conquer those quirky nodes and blocks." Whilst this is true changes in the theme system that are already in the pipeline will radically alter that, making it much easier to conquer blocks and nodes :)
But whilst themeing Drupal can be made *easier*, it's never going to be *easy* to set up and theme large or medium sized websites, not if you want to do it well.
My shot:
Op woensdag 14 juni 2006 09:36, schreef Kieran Lal:
"It was also my first chance to play with Drupal. Unfortunately, although it’s a very powerful CMS, I didn’t have the greatest time with it as it came to be one of the most cumbersome and roundabout pieces of software I’ve ever worked with."
«roundabout» It is. The theme layer is, very much like a theme-spaghetti. The longest theme trace in general Drupal is: Page » node » engine » core » engine » comment » engine » details » username » link Inbetween we move two times out of "views" mode and let the theme engine call core, call teh theme engine. And so on.
Point is: its spagetti. How can any sane designer learn simple things as "redesgn the usernames that appear with the comments" if that username gets onto the screen via such a long, winding route?
We, themers, have drupal grown onto us, so for us such things are easily overlooked, taken for granted. Teh more since we know the code and the core.
In a true themeing system, one should never need that knowledge. The theme should be a decoupled entity that has at most two levels (comment prints username) but certainly not 10 that are not even all of them in the theme level!
I beleive that, if we can manage this, we aer saved. I beleive that for that, we should, or could, develop a SIMPLE theme engine. Not somethign as opwerfull and flexible as phptemlpate, but something as simple as clean PHP. Something as clean and simple in usage and designability as liquid, for example. http://home.leetsoft.com/liquid.
Something alongside phptemplate and the phptemplate2.0. Then PHPtemplate can remain the complex, powerfull and flexible one.
Anyone up for this?
Bèr
«roundabout» It is. The theme layer is, very much like a theme-spaghetti. The longest theme trace in general Drupal is: Page » node » engine » core » engine » comment » engine » details » username » link Inbetween we move two times out of "views" mode and let the theme engine call core, call teh theme engine. And so on.
The path is true and that can be avoided but might not be very wise. It will add a lot of constraints on what is themeable and what not, unless we overhaul not only the the theme layer but the way drupal works.
The recent attempts to redo the theme system Adrian, Karoly, Dries and me are doing come from a few observations.
* From a designer's perspective it is not easy to find out what is themeable. And when they find it there is a high chance that is php code. Ooops. Hard to read and grasp if you are not a coder.
* Different theme pieces are scattered around the codebase. Again, hard to find.
So we are undertaking two things, split all modules into their own directories. Take out all theme functions into their own files living either in the appropriate module directory or in a new templates directory. Some of the phpteplate's internals now live in theme.inc We are trying not to make this stuff slower or more memory hungry.
This will hopefully help to find themeable components. Those which make sence should be migrated to mainly html with some php as opposed to the current state.
Creating a new theme from scratch can even be done like copy all tpl.php files into a directory. Change all files to suit you. Presto completely new look drupal.
The complicated threading of theme-code-theme-code-... is still there, but far more unnoticeable. Potentialy that is. In the end it does reflect the application flow.
On Jun 14, 2006, at 5:25 AM, Vladimir Zlatanov wrote:
«roundabout» It is. The theme layer is, very much like a theme- spaghetti. The longest theme trace in general Drupal is: Page » node » engine » core » engine » comment » engine » details » username » link Inbetween we move two times out of "views" mode and let the theme engine call core, call teh theme engine. And so on.
The path is true and that can be avoided but might not be very wise. It will add a lot of constraints on what is themeable and what not, unless we overhaul not only the the theme layer but the way drupal works.
The recent attempts to redo the theme system Adrian, Karoly, Dries and me are doing come from a few observations.
- From a designer's perspective it is not easy to find out what is
themeable. And when they find it there is a high chance that is php code. Ooops. Hard to read and grasp if you are not a coder.
- Different theme pieces are scattered around the codebase. Again,
hard to find.
So we are undertaking two things, split all modules into their own directories. Take out all theme functions into their own files living either in the appropriate module directory or in a new templates directory. Some of the phpteplate's internals now live in theme.inc We are trying not to make this stuff slower or more memory hungry.
This will hopefully help to find themeable components. Those which make sence should be migrated to mainly html with some php as opposed to the current state.
Creating a new theme from scratch can even be done like copy all tpl.php files into a directory. Change all files to suit you. Presto completely new look drupal.
The complicated threading of theme-code-theme-code-... is still there, but far more unnoticeable. Potentialy that is. In the end it does reflect the application flow.
Sounds like a thoughtful approach. But also sounds like more a re- engineering than an attempt to meet the need of these designers trying to design with Drupal for the first time.
Can you elaborate on "help to find themeable components. Those which make sense should be migrated to mainly html"?
-I want to understand more clearly the benefits to new designers trying to understand Drupal theming
Kieran
themes mailing list themes@drupal.org http://lists.drupal.org/mailman/listinfo/themes
On 14 Jun 2006, at 6:08 PM, Kieran Lal wrote:
Sounds like a thoughtful approach. But also sounds like more a re- engineering than an attempt to meet the need of these designers trying to design with Drupal for the first time.
Can you elaborate on "help to find themeable components. Those which make sense should be migrated to mainly html"?
Instead of finding theme functions in the code.. to override anything you just go : cp modules/event/event.tpl.php themes/mytheme
Overriding any template no longer requires any knowledge of php. It is literally just copy and edit.
Instead of having the code in the format of :
function theme_block($block) { $output = "<div class="block block-$block->module" id="block- $block->module-$block->delta">\n"; $output .= " <h2 class="title">$block->subject</h2>\n"; $output .= " <div class="content">$block->content</div>\n"; $output .= "</div>\n"; return $output; }
Contained inside a file filled with other source. It is instead just :
<div class="<?php print "block block-$block->module"?>" id="<?php print "block-$block->module-$block->delta"?>"> <h2><?php print $block->subject?></h2> <div class="content"><?php print $block->content ?></div> </div>
Because of this, we can also write a _proper_ inline theme editor. Something which was possible up to now.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Op woensdag 14 juni 2006 18:08, schreef Kieran Lal:
-I want to understand more clearly the benefits to new designers trying to understand Drupal theming
I asked a skilled designer a while ago, when I wrote my theme stuff/proposal for Railfrog and this is what she wrote (translated to english by me)
«Do you know mollio? That is a theme, and the nice thing is that it has all components in one page. One big HTML page, is very friendly for designers. While that page also lists all elements that must be styled. This solves two common problems: A designer does no know what to design and will design one page only. Or will design all elements he sees on one page. The other common problem is that a designer cannot oversee what the effects of a certain design element looks like in the "big picture" if you work with all sorts of loose files. And designers should never need a fully, filled with content installed site to design on. We call that the F5 method.
How about code in the templates
I find nothing wrong with some PHP. as long as it is simple and consistent.
A personal thing I dislike in most template systems for CMSes, especially Open Source CMSes have this, is that there are hundred ways to get to Rome. Why? I, as designer want one way. Have that documented and worked out into great detail. Not fifteen abstraction layers, several possible ways to design a piece and so on. It is important for designers, who know nothing about the system, to have clear borders and good documentation. That is more important then huge flexibility, or lots of choices to do something.»
Hope this helps a little. Bèr
On Jun 14, 2006, at 9:47 AM, Bèr Kessels wrote:
Hope this helps a little. Bèr
When we did the administration user experience survey with almost 900 respondents it helped to focus improvements in Drupal and many many user experience improvements were added for Drupal admins. Multiple comment administration and Blocks by Roles(now in 4.8) were obviously important but just not a priority for core developers until we had some data, not just opinion.
Drupal's roadmap is to win in the battle of the "easiest to use CMS wins" all else being equal.
The admin survey showed that fixing themes was the hardest thing to do for Drupal administrators. What we need are more anecdotes, similar to what Ber showed us so we start a parallel effort to PHPTemplate 2.0. Anecdotes can lead to designer interviews which can lead to broad surveys.
Broad surveys can lead to user centered design.
Ber if you want to do some interviews with designers to start a user centered design process that will merge with PHPTemplate 2.0 then that's interesting to me and CivicSpace will back those efforts.
Kieran
-- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | _______________________________________________ themes mailing list themes@drupal.org http://lists.drupal.org/mailman/listinfo/themes
Op woensdag 14 juni 2006 20:10, schreef Kieran Lal:
Ber if you want to do some interviews with designers to start a user centered design process that will merge with PHPTemplate 2.0 then that's interesting to me and CivicSpace will back those efforts.
I don't have the resources, nor the skills for this. That mail came from a reply to some short questions I mailed to a designer whom I know and whom has a good portfolio in CMS designs. I don't know many such people, nor would I be able to manage audits and interviews. in an orgnaised manner. :)
Bèr
On Jun 14, 2006, at 11:41 AM, Bèr Kessels wrote:
Op woensdag 14 juni 2006 20:10, schreef Kieran Lal:
Ber if you want to do some interviews with designers to start a user centered design process that will merge with PHPTemplate 2.0 then that's interesting to me and CivicSpace will back those efforts.
I don't have the resources, nor the skills for this.
It's not hard. I can do some on Skype with you listening and then you can take if from there. If I wanted to do it all myself I could. I am more interested in getting the Drupal development community as interested in user centered design as they are about how to properly serialize arrays. We aren't going program our way of user experience issues no matter how many clever hooks and APIs we develop.
That mail came from a reply to some short questions I mailed to a designer whom I know and whom has a good portfolio in CMS designs. I don't know many such people, nor would I be able to manage audits and interviews.
I can help.
in an orgnaised manner. :)
I can help with that too.
Kieran
Bèr
| Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
Written while listening to Taste Of Snow (live in Bp Trafo) by Zagar on Website _______________________________________________ themes mailing list themes@drupal.org http://lists.drupal.org/mailman/listinfo/themes
On 14 Jun 2006, at 8:10 PM, Kieran Lal wrote:
The admin survey showed that fixing themes was the hardest thing to do for Drupal administrators. What we need are more anecdotes, similar to what Ber showed us so we start a parallel effort to PHPTemplate 2.0. Anecdotes can lead to designer interviews which can lead to broad surveys.
Regarding what Ber said.
One of the reasons we want to do the template stuff, is we have implemented a hook_widgets, which allows you to register all the theme functions as well as provide default lipsums for them. Basically so we can build unit tests for the markup, and we can construct a single HTML page containing all the elements that are themeable.
We need to get the templates patch in first though (and it's getting there).
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
-
Adrian Rossouw -
Adrian Simmons -
Bèr Kessels -
Kieran Lal -
Vladimir Zlatanov