It sounds pretty simple. Take the resources you want people to navigate around---so generally the furthermost leaves of your navigation tree: rich content pages, applications and the like rather than section indexes, which might contain navigational preconceptions---and try to assemble them into groups. Pretend they're written on cards---or, in a more agile way, actually write them on cards and shuffle them round a table---and try to assemble piles of similar resources. Closed card sorting involves predefining the groups, and is ideal for arranging new elements in an existing navigation and a good compromise for building a new navigation quickly; open card sorting is the same, but with no predefined groups. The results are better but it takes longer.

Card sorting really helps site maintainers escape preconceptions and build a navigational hierarchy that makes sense. So although it seems like overkill, this is actually what I have just done for this website. As with much that I'm currently doing towards the site rebuild, it's intended as a learning experience; a voyage of discovery, albeit taken on a Tonka truck within the safe confines of the wee sandbox that's my personal site.

My first pass yielded around fifteen resources---rather fuzzily defined, but including varied things like "my blog" and "a link to my Twitter feed"---which I wanted people to be able to navigate around. I arranged these in a single-parent hierarchy beneath six main headings: ongoing, literature, coding, academia and portfolio. However, this felt a bit forced (and some sections, especially "academia", are mostly opportunities for old documents to gather dust. I tried to imagine adding a more freeform vocabulary that cut across a lot of this, something like tagging, but there was something wrong.

Unsatisfied, I completely scrapped the single hierarchy and tried again. This time the list of resources had expanded to more like twenty, and I went for a more radical approach to grouping. Instead of trying to group objects as cards in a pile, so each card could only be in one pile, I tried to imagine from the start what groups plural they might fit into. Although I was still thinking in terms of menus, the parent terms were now more like categories from a taxonomy, with any menu item being available from several categories.

This resulted in seven terms:

tech, content, social, lit(erature), work, love and misc

This blog, for example, could fit under "tech", "content" and maybe "work", and would be accessible from all those places. My attempts at creative writing on Quiet little Lies could go under "content", "literature" and possibly "love".

As long as the number of objects didn't get too long (and objects didn't spread under too many terms) then these seven terms could still make sense to the user as a starting point, even if they found different things in multiple places. In fact, in the brave new world of folksonomies and tags, web users might be getting used to less hierarchical ways of navigating, so this might even pay off.

Drupal's menu system supports multiple or mixed hierarchies out of the box, but I preferred instead to actually use categories, and tie these to a menu with the Taxonomy Menu module. I might not follow that route in future, as it essentially only supports linking to Drupal's out-of-the-box category index pages, with content sorted in reverse date order, whereas I'l almost certainly want to do something nicer. But like card sorting itself it was a good springboard to getting things working and feeling happy with progress.

For now the hierarchy is implemented with dummy content, but I hope to fill it out more---and then expose the navigation---in the next few days. Right now it's just nice to see things starting to come together. Also, having seven top-level terms fits in rather neatly with the design decisions I've already made: more on those later.