Drupal Ramblings

In preparation for my trip to Washington D.C. next month, I've begun to develop a module that integrates the CAP XML format (Common Alerting Protocol) with drupal's node, location, google map, category, and CCK modules. Put plainly, the CAP format seeks:

"[to standardize] the content of alerts and notifications across all hazards, including law enforcement and public safety as well as natural hazards such as severe weather, fires, earthquakes, and tsunami. Systems using CAP have shown that a single authoritative and secure alert message can quickly launch Internet messages, news feeds, television text captions, highway sign messages, and synthesized voice over automated telephone calls or radio broadcasts."

Having spent about 8 hours researching and experiementing with drupal, xml, and the CAP alert format, I've come to a few conclusions:

I’ve been watching the category module since January. Today, I’m ready to make a rather controversial assertion: this module has rendered both the taxonomy, and book modules obsolete.

It goes without saying that when making a serious decision, such as going to war, or declaring the taxonomy module obsolete, one better have a reason. Here are just a few of my reasons:

1. It converts the book module’s flacid, pseudo menu into something useful: a real menu. In other words, it enables you to create a global navigation scheme (menu trees, and breadcrumbs) that will expand in response to whatever node your users are currently viewing. Before, books were invalid mini-sites that were seperated from the great context of the menu tree. They were a bad solution that one had to make, because there wasn't an alternative. Let us join hands, and celebrate the passing of that dark age.
2. The category module not only gives you the option of automatically generating a menu item for every node that you file under a certain category… it gives you the option to create an pseudo menu item – so you avoid cluttering your menu, but have the benefits of context in terms of breadcrumbs and menu trees. Some "experts" say that its important for your navigation to a) show the user where they are, b) show them where they can go, c) show them where they've been. It was very sad that this simple goal was so hard to achieve in the past. Well, it is no longer, thanks to the category module.
3. Every “category”, and every “container” are nodes. And wait, this should be explained:Foreach (TAXONOMY) { category = term, container = vocabulary }Foreach (BOOK) { category = child, container = parent} Every container, and category have an RSS feed. And since they are nodes, they can be themed like any other node. This = presentational freedom that both taxonomy and book sorely lacked.
4. Pathauto now has native category module support. In otherwords, I dare you to see what happens if you set every node’s default path to [menupath]/[title], and every category and container to [menupath]. What you will find is SEO, and URL heaven – never again will you need to scheme of ways to make URLs, breadcrumbs, and menus all agree.
5. We all know that the views module allows you to differentiate between taxonomy, and node types (just nod along like you knew that…). In contrast, the category module has full fledge views support. I’ll say it again: you can extend the category module’s organizational freedom, with the universe of presentational, and conditional options of the views module. That makes me a very happy person.
6. In general, the new concepts put forward by the category module offer superior freedom in terms of the way content relates, is displayed, is navigated, and can be consumed. For the first time, you can build a comprehensive organized sitemap, using the sitemenu module. Oh – and did I mention, it has a bulk editor that makes complete reorganizations of a site’s structure take LITERALLY 1/40th of the time they would take with book, or taxonomy modules. F@ck yeah!
7. I will never have to explain what a taxonomy is again. I will never have to show someone the difference between vocabularies and terms. Even better, never again will I have to hypnotize some poor bloke into believing that the seperation between taxonomy/menus/book hierarchies is a sensible thing. Though, its worth noting that I've become a good hypnotist.

After some thought, I've come to the conclusion that Drupal's most significant usability problem is findability. Findability[1] is defined as:

a. The quality of being locatable or navigable. b. The degree to which a particular object is easy to discover or locate. c. The degree to which a system or environment supports navigation and retrieval.

The true seriousness of drupal's findability problem may not be immediately evident to expert drupal users. In addition, in various usability surveys, and studies, there is no immediate evidence of Drupal's findability problem.

The more I think about it, the more I dislike the word "usability", and this abstract construct dubbed "the user".

This is not an entirely enviable stance for me to take. A brief search of my past writings will reveal that I've been downright promiscious in terms of discussing users, and their useiness. So why the change of heart?

Well, think about it:

• have you ever thought to yourself "my, this website is insanely usable!".
• Can you even remember the last time you uttered the word"usability" outside of a discussion about usability?
• Have you ever heard a person who doesn't read web design blogs mention a site's "usability"?['1']

It seems to me that the word "usability" is much like the Tao: though one can speak of usability, the true, and eternal usability can only be nameless. If it had a name, than it would not be of the eternal usable nature.

Last summer, nearly every client that I talked with who wanted a CMS would ask for Mambo. This was in spite of Drupal's obvious superiority in terms of code, flexibility, and power.

I was forced to conclude that Drupal's biggest weakness was the first impression it was making. I spent about 2 minutes looking at drupal.org, and Mambo's homepage, and the cause of Drupal's weak first impression was dead obvious:

During today's break, I participated in the second meeting of the drupal curriculum development group. For those of you with sex lives, our group is building a 5 day training course on all things drupal. The curriculum is targeted towards people with some sort of web design/development background. I think this makes sense, as I can't see anyone with a casual interest in drupal spending 5 hours for 5 days talking about drupal. However, I do know that there is more demand for experienced drupal developers than the current pool can supply. It is of the upmost importance for our platform to meet this demand.

Today, while talking to Kieran from Civicspace labs, I mentioned that Civicspace would benefit from taking a more informal tone in their interface, documentation, and training. I supported this argument with, "well... ummm... there's -- like -- these studies... -- or something -- somewhere..."

You're damn straight that is powerful evidence!

I first discovered sIFR last October. If you've never heard of sIFR, then I suggest you pretend otherwise. Simply nod, smile, and read all about it.

The module is now available for download on CVS.

My RSS reader has somewhere's near 800 feeds at this point. In order to cope, I've for a long time had a folder titled, "Feeds I actually read" (yes, a number of my thunderbird folders are jokes that I crack to myself. Its pathetic...). Anyways, one of my favorites in the folder I actually read is a blog called Creating Passionante Users. One of the more recent entries had a graph that I thought every single drupal user, developer, and advocate should see:

Shot in the dark, I know, but its going to be at least a month before I'll have time to build this correctly. I wouldn't ask if it were not for fear that the idea will loose momemtum without a place for interested folks to get together soon... Plus, I imagine a few folks might understand how useful this module could be. Thus, here's a shot in the dark, and basic spec of how the module is to work:

zengarden.module -- a module that enables an open-source approach to a drupal theme framework, and reusable CSS library. Yes, in many its kind of like the zen garden, but really more like listamatic... Here's how it would work: