New Drupal 6 Theme Nearing Release

Been working on the new drupal 6 design for this blog. Its taken longer than normal, because i'll be adding it to drupal's contributions. Haven't named it yet. Probably will go with something along the lines of "green nerd hippy", but am still not sure.

The theme aims to be a slick, two column layout, that is flexible enough to be used as a base theme.
The priorities in the theme are:

Updating to Drupal 6.x

Bit the bullet and upgraded this ol' blog to drupal 6.x. This is a painful update, since my blog was running on a weird hybrid 4.7/civicspace codebase, and had relics of early CCK, Views, etc. Am not planning on sticking with garland (not that there is anything wrong with garland).

Notes on the Drupal Usability Report

Indeed, this is a great usability report.

I scribbled these notes as I read it:

  • Statuses (such as "publish", "unpublish", "promote to frontpage") should not use checkboxes -- they should use BUTTONS. Clicking a button helps ensure that a user understands the gravity of their actions -- which is extremely important. These buttons should show a certain amount of intelligence. "Unpublish" or "Save Changes" for live content. "Publish" or "Save as Draft" for new content, and "Publish", "Save Changes" for unpublished content... etc...
  • "Promote to frontpage" is a checkbox that wants to read "Show on frontpage". It's a checkbox, because its an attribute that piece of content can have -- not necessarily an action the user makes on a piece of content. Above all it is of lesser importance than the buttons listed in the previous note -- forgetting to promote a piece of content to the front page will probably be a lot less embarrassing than what could appen if someone accidently publishes a less-than-ready draft. Especially when our interface merely reads "save" -- which is deceptively safe looking.
  • The "story" content type needs to either die, or be renamed "article".
  • "Book pages" should become simply "pages" with pages as we previously understood them thrown away. The behavior that I think users expect from "pages" is what the book module does best. The book metaphor isn't extended that much -- "child", and "parent" are the main terms used in the interface -- not "chapter" and "page" like you'd expect in a book.
  • Settings like front page path are deep enough in drupal admin hell, that a quick fix may have to be a special help box that appears in certain circumstances. Messages would read something along the lines of "Your frontpage is currently set to "/blog". [link] Where can I change this?" These boxes could serve as bandaids for some of our more complex usability problems that aren't going to be solved in a single release.
  • admin/content is important enough to have its own unique section dedicated to content management, and content management only. Site settings, user management, and content management are three very different things afterall. I believe they deserve their own individual sections outside of our behemoth misadministration console.
  • Yes most users really do expect a wysiwg editor of sorts. I speak of our userbase -- e.g. people who'll never visit, or would ever need to know what kind of CMS is running a website. At bare minimum, it should let users add links, images, lists, and blockquotes. A message should instruct users that "[return] = paragraph/ [shift-return] = linebreak. TinyMCE is evil because of the number of options it provides.
  • Permissions themselves should be split out perhaps. There is quite a big difference between content related, admin related, and user related permissions. Perhaps splitting these permissions out into more intuitive locations (e.g. content permissions are found in content type settings) and offerring overview pages of what various users can do with various site components would help alleviate this problem.
  • There should be a region, and navagition devoted to admin tasks. I think it belongs at the very top of the page (but is not so high that it takes up too much room). Its separated from the main theme, and is design is always consistant no matter the theme currently being used.
  • The top admin bar, and admin page (as well as perhaps the content creation pages) can be modified, but not quite as readily as a "theme" as we know it. This roadblock frees up theme developers (ESPECIALLY NON DRUPAL EXPERT ONES) to focus on how sites look to their visitors -- they shouldn't nomrally need to worry about how the sites look to their admins/content managers as well. That should really be the the association of drupal ninja's concern.

Overall -- drupal's flexibility and configurability seems to be a curse to our users. The out of the box drupal should aim to offer a few good approaches to common needs that people are trying to satisfy with their website. Like an object, the more that we encapsulate these distinct needs and settings the better. Perhaps we lose "flexibility" -- but if I wanted pure flexibility, I'd write things from scratch, no?

7 Types of Development Articles that Set Kittens on Fire

Everyday, I attempt to read 20 or 30 web development articles, usually via dzone,, and the drupal planet. Its a perverse and masochistic ritual. The articles I scan leave me with a dreadful sense of emptiness -- and a longing for a different career. On the otherhand, it tends to make my development work seem exciting by contrast.

Guide to PHP 5 Design Patterns

Stumbled on a really awesome overview of object oriented programming for PHP 5. If you're looking to get out of the php 4 mindset, this is a good place to start.

PHP Design Patterns

Drupal Tough Love

BillMeanGuy copy Drupal Tough Love is a new site by The Notorious C.H.X. , and Morbus Iff. Want to become a better drupal developer? Get ready for some tough love:

"We all make mistakes; that's how we learn. Sometimes, though, we need someone to point out our mistakes...

And if you don't learn, than Curly on the left will show you some really tough love.

Drupal Tough Love: I'll be watching you like a hawk.

Top 5 Reasons Developers Don't Use Drupal

Jeff Whatcott ponders why Drupal isn't dominating the job postings for social app PHP developers.  He guesses the main problem is lack of awareness and understanding of drupal among the greater developer community. With this line of thinking, the obvious fix would be outreach and education. Personally, I'm skeptical that the developers who choose systems other than drupal do so because of lack knowledge, or awareness. I think its something far less rational

Drupal 6 AHAH forms: Making New Fields Work

Today, I was working with drupal 6's AHAH form elements. Initially, I was delighted at how well they worked. That delight turned to confusion once I realized that the form elements I had put in the menu callback of the #ahah['path'] was missing its name attribute. After doing a bit of research in how the poll module handled the formapi voodoo, I created a generalized function to aid in building AHAH callbacks. If there is a better way to do this, I wasn't able to find it. <?php

Drupal CSS Coding Standards

On the #drupal IRC channel, Excallibur points out that there are no coding standards for CSS. I'd like to propose some straightforward ones.

Note that I am not intentionally omitting indentation within rules, but am having trouble with my code filter.

The Keyboard: Perhaps this Contraption Might be of Use to Drupal

Imagine this: you are viewing a node, and hit alt-e. That keystroke brings up a node edit form. Or instead of dragging blocks, taxonomy terms, and menu items, you merely hit the "down" key. I wonder, may this strange device called a "keyboard" be of use to us? Well, regardless, there's a freestanding jquery plugin that's done most of the work already. The question is: are the Drupalites FOR or AGAINST the keyboard?*

See Mike Hostetler's keynav plugin for jQuery


Subscribe to Nick Lewis: The Blog RSS