Google the terms “placefulness” and “Drupal” together, and the top results all point to … Plone! As we move more deeply into our web site design, we are gaining a better understand of our site needs.
Placefulness: the Plone community makes frequent use of this term to describe how the system automatically retains the “location” of each new document one creates in the site. In end-user terms, the user clearly knows where he/she is within the site at all times. This makes Plone well-suited for sites with a clean content hierarchy. Contrast this with Drupal, in which new nodes have no location by default. The system only automatically assigns them a node ID number. Drupal developers use content types, menus, tags, views, and modules to create the illusion of place and hierarchical structure.
Many of our users, responsible for a particular school program, need to manage the hierarchy of article in their content area. If this process is difficult to use, it will challenge a lot of people and become an obstacle to content creation. We must also consider permissions and menus. Plone cascades editing privileges in a way that Drupal does not — if you can edit the parent, then you can also edit its children by default. Users may expect menu items to appear automatically in a hierarchical content structure.
Recognizing the need, the Drupal community has generated a number of modules that help automatically link new nodes to their location within a hierarchical content structure. Most obvious is the book module, distributed with core. Users may create child pages, and the Book Navigation feature automatically generates a book menu on the fly.
I learned that it is best to automatically display Book Navigation on whenever one is in a book. If one restricts the block’s visibility based on the URL path, then one has to specify custom URLs for all of the pages in the book or use PathAuto to automatically generate them. This quickly becomes a hassle again.
At first glance, it does not appear straightforward to mix book and non-book menu items in these menus, which could be a problem. We could create separate menus for structured content navigation and links to interactive pages (a.k.a., transactions). While that would work better within Drupal, would it make the site more or less usable to our visitors?
To further complicate matters, we want the landing page of each top-level section to show the news items for that category instead of a book page. Now we need to make the book navigation appear before we are actually in the book. This code snippet makes book navigation appear on all pages — we would have to modify it to display a navigation block to match the book one is about to enter. Another possible direction is to insert PHP code into the book landing page to manually query the database for news items related to that book. That may be more straightforward.
Good news: I just tried two new tricks (for me). I inserted PHP code into a book page to mix dynamic with static content. Drupal provided me the SQL query in the Drupal 6 View interface.
$sql = "SELECT node.nid AS nid FROM node node LEFT JOIN term_node term_node ON node.vid = term_node.vid INNER JOIN term_data term_data ON term_node.tid = term_data.tid WHERE (node.type in ('news')) AND (term_data.name = 'admission')";
$result = db_query($sql);
while ($row = db_fetch_object($result)) {
$node = node_load($row->nid);
print node_view($node);
}
And also used a redirect to send the user from a static page to a separate, dynamic one.
header('Location:http://ww2.catlin.edu/scripts/admission.pl');
(I know, I’m showing my novice Drupal learning curve. It’s my blog.)
We could throw in the towel and manually manage the menus. We really want the ability to post a single article to multiple places in the hierarchy, which seems to run counter to any automatic menu generation feature. However, if a user responsible for a small portion of the site needs to scroll through the entire site menu hierarchy to place their item, they will be stopped in their tracks.
Node Hierarchy appears to address our concern directly, allowing a user to specify the child relationship of a new node to an existing one. It’s unclear whether development on this module is sufficiently active to use on our primary, public web site. The Drupal 6 version is currently in alpha. I also question whether it uses a popup menu to select the parent node, which would be very awkward on a large site. Node Hierarchy is incompatible with book, which would mean that we were placing our trust in a module with less community support than Book.
I have yet to investigate breadcrumb navigation, which would also help strengthen the sense of placefulness of each node. I hope it will play well with the other hoops I am jumping through to make this work.
For classroom pages, it may make more sense to use Organic Groups. That should allow teachers to post articles, manually maintain a simple menu, and create items for other content types as we support them (image galleries, calendar, blog posts, etc.). This will also allow individuals to maintain both public and private content, which should help us both maintain visibility of classroom programs and protect the privacy of our students, teachers, and parents.
Amherst College developed their own solution, Monster Menus, to provide this functionality to their site. However, development was so extensive that they were not able to publish a module for this, despite recognizing the high levels of interest and expressing their willingness to share.
If we need to choose between Drupal and Plone, we may need to determine the core nature of our site. Is this a traditional content repository with some interactive features, or is it an interactive site with some hierarchical content? Will the interactivity be mostly one-way (collecting information from school community members), or will we really reply and produce lots of original, dynamic content ourselves? In other words, will we really have the kind of community site that Drupal was invented to provide? We don’t want to constantly swim upstream against Drupal’s core tendencies.
The ace up our sleeve is that we can set up a test site to experiment with different potential solutions before we commit to a development platform.
tags: drupal, plone, placefulness, menus, structured_content
