webschuur.com

update: after some stupid editing of mine, I brought the points down to six. thanks to Bert for telling me I am fool.

More and more often I have to cope with designers in the process of creating Drupal sites. That is a good sign: Drupal matures, so it gets used in more multitalented, professional environments. Not just a pimpled student in the attic who knows some Photoshop and some Javascript and learns some PHP, but project cycles with multidiscplinary teams involved.

The biggest bottleneck, in all this, however, I find, is the wrongly skilled designer.

Ajax is no longer hot, its a commodity. Rich javascript is found all over the place. This is a bad thing. Or at least something we should be worried about. We, being people who care about usability.

Not because javascript is bad, not because of the fact that many javascript is written extremely bad. But because it gives developers an excuse not to work on usability.

Being a Javascript Lover

I am a javascript lover. Back in the days I put javascript in every site I built. You know, the stuff that would alert(‘Your browser is too old’). But ever since then I have held my sepsis for use of it too. Javascript is not evil, nor is it 42. It is merely a tool: use it right, and it is good. Use it wrong and it turns evil.

While browsing Freshmeat (looking for a database structure visualiser) I thought “lets see Drupal’s entry”.

The download urls and so, seem up to date, the description is somewhat crufty, but not outdated either. But the screenshot is an old (pre) 4.0 (I am not sure).

The most asonoshing thing, however, is to see the great usability of our old-and-forgotton admin area. About three-and-a-half(!) years ago, we used to have a separate admin area. And the best of it all is that it looks very much more userfriendly then our current structure. Maybe it safe to state that some parts of Drupal actually regressed, amids all the great progression.

When I was a kid I kind of looked down on the Playmobil Kids. I preferred Lego. It gave me huge power to build my own toys, and allowed me to be creative. It allowed me to build what I had in mind, not to only play the way some marketing department thought I should play.

Recently I thought this actually describes an underlying problem with Drupal. Too many people rant about Drupal being hard to grok. Or about Drupal not being able to built this and that kind of site. And a lot of them rant about the none existing web installer.

But if we have an installer? Will all difficulties suddenly disappear? Will then, from that moment on, everyone be able to build his or her drupal site? Off course not. An installer, is just a part of a big puzzle. Its not some Magic Potion To Solve All Worlds Problems. It will address certain issues, but I doubt it will suddenly make drupaleering a lot easier Making it easier or cheaper to buy Lego, does not mean that you can suddenly build beautiful racing cars.

Drupal is like a sack of Lego. I am talking oldschool Lego, not the recent stuff. Wordpress, or PHPbb, on the other hand is like the playmobil. With playmobil, you buy a race car, so that you can play your own racing stories. Lego on the other hand allows you to build your racing car. Whether you build it from your own fantasy, or from a recipe, the biggest fun lies in building it.
Would you be happy if the Lego came in a prebuilt state? Or if you only had to press a button and you have your racing car? I would not, because I chose Lego for its power. For the ability to not follow the recipe and come up with my ideal racing car.

We all know the mantra “logic and design must be separated”. and we all agree with that, or so I assume. Drupal does this quit well,separating them, in structured and layered templating system.
What is lesser known and more often violated is a strict separation between logic and data. In Drupal we all know the so called PHP blocks and pages.
and while I too abuse these very often, they made me think a lot. As of today I decided that I dislike them. And that I will seek for a better alternative to replace them with.

I dislike them for two reasons. The most obvious is security. One must keep a very very close eye on the site that has php pages. On a few of my sites I found out a bit late that I gave certain people the ability to create php blocks (in older drupal versions it was harder to change that, then in 4.7). I know of one mayor site where I suddenly saw the filter option “PHP code” appear in my node creation forms (yet I was only a moderator). Just examples of how easy this security hole is opened up. The way to avoid this from happening is just to pay attention. Something one should do anyway. But still: switching it all off, is the most secure thing to do. Especially in a multisite hosting environment.

Attached is a mockup of the files dialog inside the create content >> Foo pages. The mockup is annotated, and available as svg. PLease send me any improved svgs and/or pngs.

More mockups will follow. I.e, how the “edit” screen looks.