Redefining the Architecture.

I decided to start again by defining the information architecture for the site based on a proper discussion with the Club committee. The first few meetings on this topic just weren’t as well focused as they should have been; mostly my fault for not knowing what I wanted from them; but this time I tried targeting those features that the membership would really value. Each of the features that emerged seemed to fall into logical sections of the information architecture:

• About the Club — including notices, events and membership contacts.
• Content on Birding — after all it’s the main focus of the Club.
• Social groups within the Club divided by specific interest.

These overall sections were used as containers for the more specific features, and these formed the basis for implementation.

I’ve tried an online tool called WriteMaps for developing and sharing the architecture of this site. I haven’t decided whether it’s the best way to approach the job yet, but here’s the link to the detailed sitemap.

Implementing the Design.

The original site used custom taxonomy — tagging — to enforce the architecture, with multiple sections of the site sharing the same content types. As I mentioned, this made it very confusing for the Club editors, which was reflected in the site presentation.

Installing new modules.

I needed to add several new modules to support the new content. There are several ways of doing this; this alone is a substantial topic; but the simplest is to download the module directory containing the code into the modules directory of your Drupal installation.

Content types.

For this redesign I decided that each of the features should have a dedicated content type so that users only need select the right one, there’s help text as you can see, and it’ll end up in the right place on the website. No more messing about with tags!

A great tool for this is the Content Construction Kit (CCK) module. It makes implementing new content types very easy; no PHP required; and there are a wide range of modules that provide additional data fields. I’ve used several to provide dates, images and even GoogleMaps, take a look at the full list of compatible modules on the Drupal website.

Once the CCK module is installed, all the changes you want to make can be managed from the Content types section of Content Management.

Providing access.

All these new content types need to have access control set–up before you can go any further. This is done in Access control, under User Management in the administration section of Drupal.

You should find both create and edit options to set under node module for the new content types.

Once these are set the content types should appear on the appropriate create content menus.

Setting up the paths.

But you’ll want to set the URLs to reflect the new architecture before deploying.

I use Pathauto to provide aliases for my content that better reflect the structure of the website and present friendly URLs. You can do this manually, but if you can’t rely on your users to do this consistently I would recommend using Pathauto.

The Pathauto settings are under Site Configuration, and it’s the Node paths you want to set–up for your new content.

These, combined with the individual content types, provide the structure for the website. For example I wanted the bird guide to appear within the birding section of the site architecture with individual entries beneath this, so I set the pattern to birding/birdguide/[title].htm.

Time for a View.

The Views module provides the ability to present node data in a range of different formats. With the module installed your views can be managed from the Administer views section found under Site building.

Here you can define new views for each of the content types and define a URL from which the specific view can be accessed in the browser. In the image above you can seen that I wanted the bird guide list to appear as the default in the bird guide, and gave it the URL birding/birdguide. These views can generate lists, tables and customised sorting, in addition to the more standard web page presentations.

…And a menu.

Finally we’re going to want a menu from which all our good work can be accessed. The menus and blocks in Drupal can all be found in the Site building section.

The sequence is simple, first create a new menu for the features you’ve implemented, under the Menus section, using the URLs of the views;

and then go to the Blocks section and put the new menu where you want it to appear on the website.

That should be it! Your new functionality has been added.

Conclusions?

Having established this workflow, I implemented each of the identified features one at a time, ensuring it was working and acceptable before moving on to the next.

I believe, and feedback suggests my users agree, that this approach to building a Drupal website is far more successful than a taxonomy based one. I still use taxonomy, but it now provides addition information for particular types of content rather than forming the basis for site architecture.

As for Drupal itself, it’s relatively easy to use, even without significant PHP knowledge, and the large community provides a huge range of contributed modules and support. This makes it a powerful way to develop feature rich, multi–user websites very quickly.

On the downside, I’ve found providing users with an easy way to upload and insert images very difficult. There are serious problems with using the popular TinyMCE WYSIWYG editor and IMCE file handling together; individually they work OK, but together… I need to look at this again.

I would definitely recommend trying Drupal out if you need a CMS, for an image rich website; such as a gallery; I’d try Flickr or, for ultimate control, hand coded XHTML.

The scope for customization in both the information architecture and presentation is huge in these systems, and I have to admit I was pretty shaky on where to start. I read blog posts and watched video tutorials, most of which were excellent, but I have often found that personal experimentation is the best way to find things out.

I started be using taxonomy to link content together. I customized the default content types to present a range of taxonomy terms from which the users could select to define the nature of the document. I’ve found that this leads to a patch association and presentation which is pretty hard for inexperienced users to follow. Basically, it’s a bit of a mess!

I’ve subsequently installed the Content Construction Kit (CCK) module and I’m impressed with its flexibility. I don’t think it’ll handle some of the more complex content types that I’ve in mind, but these would be best implemented as separate modules anyway.

The CCK module allowed me to define customized content for each type of blog post, article, or sighting report that the Club needs. What’s more it creates an input form for each, allowing members to simply select the form they need and fill in the blanks. Much easier to control and far less confusing.

I’ve also discovered the Views module, and I’m hopeful that this will provide a far better way of ordering the website architecture than the old taxonomy driven solution. This module should allow me to really leverage the new content types I’ve defined and produce just about any content presentation I want.

I’ll post how I get on, but right now I’ve got a video tutorial on Drupal CCK and Views to watch.