usability

Just wanted to post this quick trick I’ve been using lately to automagically hide/show useful default text field values (e.g. “Search” in the search box) using jQuery and the ultra-handy Drupal.settings() object.

Here’s the short and sweet copy/pastable jQuery code:

Basically this quick snippit will add a blank array object (ahh, the joys of moving between js and PHP) to the Drupal.settings object — which is useful for all sorts of great javascript functionality, and is integral to Drupal 6.0’s extended AHAH features; if you don’t already know it, do your self a favor and study up — and automatically fill it with any textarea’s default values when a user clicks/tabs it into focus. This lets us clear the default value, but replace it quickly if the user moves on to another element.

As listed, you probably don’t want this on your site, as it will affect things like editing nodes (e.g. title inputs will go blank when you click on them… not what you necessarily want), but it’s easy to tune this to only hit elments within certain forms since every form in Drupal has a unique #id.

Thinking about this, I decided to tune it up and actually make an extended jQuery function for this so it could be more easily applied to speecific elements like so:

This is a pretty nice little plugin, I think, and it shows just how easy it can be to add nice/reusable UI functionality. Happy Drupaling, and go get ‘em jQuery!

(updated w/slight improvement to jQuery fn)
(updated again w/object style improvements from comments)

Navigation. Without it, we’d all be lost. And yet, for many of us power-users site navigation can be something of an afterthought, with “a useful set of links” falling somewhere below “hackable urls” on our personal list of priorities. But if you’re going to try and win over the browsing public, you’d better have a good menu system.

When dealing with simple brochureware or blog sites, Drupal core’s menu module provides everything you need right out of the box. For design-heavy sites with a simple navigation tree, workable menus can be baked direct ly into the theme. However, keeping users oriented becomes increasingly important, and increasingly difficult, as your web-empire spreads and sprawls beyond what menu.module provides and what a designer can code into a theme file.

With that in mind, Chapter Three is happy to announce Menu Trails module, developed with sponsorship from the uber-cool cats (uber-flatulent raptors?) at Songbird.

Songbirdnest.com is exhibit A of a growing web-empire, making use of Bugzilla, Trac, and Drupal to manage the online life of their open-source media player/browser mashup. With several sections, sub-sections and more in their site plan, we realized it was time to transcent theme-based tweaks and add some common-sense usability to Drupal’s menu system:

• Menu Trails implements primary/secondary links which keep the current menu trail “active” or highlighted. A handy snippet ready to go into your template.php is included.
• The module provides a means of broadly categorizing nodes (by type or taxonomy) as falling “under” an existing menu item. These nodes are not added to the menu tree (keeping the menu admin system sane) but they will trigger the functionality above — preserving navigation state for the user — when viewed.

How is this useful? Compare:

Before:

After

Makes a big difference, right? After talking to pwonlan about this functionality in IRC, the theme layer part — giving parent menu items a CSS class so they can be highlighted — will likely be in Drupal core for version 6.0.

For now the module is checked into CVS. We’re going to be doing a bit more tuning, and I want to see how feasible it would be to integrate somehow with views, so that nodes can be assigned to fall “under” any view which generates a menu item. I expect to package a 5.0 release later this week. Stay tuned to the project page for more on this.