Writeup: Building QuantumDidactics.net with Drupal 5

This is a writeup of how I built quantumdidactics.net with Drupal 5.
Most of my posts so far has been on groups.drupal.org, so I'm not sure that this is the right place to post the writeup. Any comments on the writeup - including where it should be posted - are welcome.

Background

Quantumdidactics.net is a website aiming at promoting research into the teaching and learning of quantum mechanics. It intended audience is primarily physics education researchers, and secondarily quantum mechanics teachers. (It is of course helpful for everyone in the huge mass of people interested in how students learn quantum mechanics.)
The main contents of the site are the 100+ research articles on quantum mechanics education.

The website is a hobby experiment – I am a Drupal hobbyist and not a web developer. It is, though, aimed at a public (though narrow) audience.
For hosting I used a Swedish low-budget web hotel (one.com). I only used pre-developed modules. Building the site took about 20 hours, of which most time was spent on adding content. The budget was about 80 USD (which was spent on domain registration and one year web hotel).

Site functions

The functions of the website are centred on the research papers catalogued on the site.

• Anyone can read title, publication data and abstract for included papers, and also follow external links to sites with more information and possibly downloads.
• Anyone can search for papers, and also list papers based on authors or research topic.
• Registered users can add tags to papers, to describe them according to research topic (or any other categorization one might find useful).
• Registered users can add comments to papers, to describe what they think about it or summarize it. (Comments are visible to anyone.) Registered users may also rate papers.
• Priviliged users may download papers in pdf, doc or txt, when available.

Apart from these research-paper based functions, there is also a contact form and a number of information pages. These may all be used/viewed by anyone.

Modules used

I used the following contributed modules:

• Poormanscron – since the web hotel didn't support the usual cron.
• CCK, plus links.
• Views – though this turned out to be more or less superfluous.
• Pathauto, Global redirect, Search 404, Token – to make paths and navigation more smooth.
• Tagadelic, Community tags – to enable the tagging functions I was interested in.
• Fivestar, Voting API – to enable the rating functions I was interested in.
• XML Sitemap, Google analytics – to give search engine positioning a boost, and monitor visits. Also Module weight, to make XML Sitemap generate sitemap after Pathauto has made new path names.

Install and basic configuration

The installation and basic configuration of the site went as follows:

• Download of Drupal 5.3 and relevant modules. Unpacking and uploading via FileZilla.
• Creation of files folder and giving it appropriate permissions, plus commenting out the option lines in the .htaccess files (since the web hotel doesn't accept customers using the access command).
• Installing Drupal with tables written with an appropriate prefix (since the web hotel only provides one database). Installing and enabling modules (except for XML Sitemap).
• Entering site information, creation and configuration of user roles ”priviliged” and ”admin”, creation of a second user, putting the site in off-line mode.
• I wrote a custom block/menu with links to some tasks I expected to perform frequently.

CCK design

Next step was creating the node type for research papers. The following fields were used:

• Title.
• Publication data, a group of fields: author names (single line textfield), year of publication (integer), paper type (text select list, indicating eg. reviewed article, book, etc.), publication details (single line textfield). (The author field was added later – see below.)
• (Two taxonomy vocabularies, see below)
• Body, in this case renamed to abstract.
• Related links (a link field with multiple values turned on).

The node had comments and fivestar ratings turned on, and also file attachments (though downloads were allowed for priviliged users only).
Two taxonomies were created and associated with the node type – research topic and authors. Both used free tagging, and the former had also Community tags activated. This allows every authenticated user to add tag terms (without giving them permissions to edit the node), and also allows users to separate their own tags from everybody else's.
The point of using tags for reseach topics was to make it easier for users to categorize research papers in their own way, and I had also decided from start that I wanted to have a tag cloud for research topics.
Using tags for authors might seem a bit odd, and in hindsight maybe I should have done it differently. The point was (1) to make it easier to see all papers contributed by a particular author, and (2) also have the convenient self-completion which is automatically turned on for free tagging. However, I discovered that the order of the authors sometimes changed (most likely they are ordered by term ID numbers). At first I didn't mind, but later I decided to add the authors text field to complement the authors tag. At a future point I might change this into some kind of multiple-choice text field, with one author entered per field – if so I will also remove the authors vocabulary.

Adding content

Adding the research papers was (not surprisingly) the most time-consuming part of creating the website. This was done by copy-pasting from my EndNote database, often complemented by googling for abstracts and relevant links to add to the nodes. In all it took maybe 15 hours of work (maximum).
Once all the papers were added, I had to do some corrections in terms of misspelled categories and a few cases where I had entered author names in the place of research topics and vice versa. I found these via the taxonomy vocabulary lists, and after correcting the nodes I also removed the superfluous terms.
During the content adding I also wrote a number of information pages, presenting the site and its functions. I activated and configured the sitewide contact form.
It might be added that I did most content adding with the first user account, though best practice is to use a second user account to manage content (for security reasons, if not to keep things tidy). This was because I had trouble working with the second user while the site was in off-line mode.

Theme

After browsing at themegarden.org for a while, I decided to use the SEOposition theme for two reasons. Firstly, it has a region ”sidebar top” above two right-hand columns. This double-width region is an excellent place to put a tag cloud if you want the cloud higly visible. Secondly, it was the only of my top-listed themes that had the content header topmost in the generated page code, thereby increasing search engine optimization.
The theme was downloaded and installed at sites/all/themes, and I started doing some minor tweaks: removing some horisontal lines, changing a few font properties, changing header image, etc. Nothing advanced. I had great use of Firebug while doing all of these tweaks.
It might be added that I first uploaded the theme in a custom-name folder, to keep it separate from the unchanged SEOposition. (I understand that this is best practice.) However, this removed all the custom regions. After some thinking and searching, I realised that this was caused by the function seoposition_regions in template.php – which is connected to the name of the folder of the theme. Posting this to some other people who had run into the same problem might be considered my first Drupal bugfix ever!

Navigation and usability

In creating menus and navigation, my primary goal was to make it easy to reach research papers of choice – and also encourage visitors to check out a paper or two. The three main paths to research papers were (1) a tag cloud at the top of the sidebar columns, (2) two of the choices in the primary menu, and (3) the search box in the sidebar.
I also made a few tailored menu blocks, and turned off the standard Navigation menu. In particular, I created a block with some links to pages explaining how to comment papers, upload papers, and so on. Later on I also added a block with three randomly chosen article titles.
I made a user test on my girlfriend, who gave me some really useful comments. Everyone should try their website on someone who hasn't been involved in building it. (And I'm not kidding.)

Launching

Before launching I connected the Google Analytics and XML Sitemap to my Google account. Then I opened the gates, and sent some invitations to the researchers appearing most frequently on the site.

In hindsight

If i were to redo the project, I would have done a few things differently.

• I would not accidentally have left the site online overnight, making Google index the site in an empty form, it and think it changes once every 100 000 years or so. Probably I would activate Google Analytics and XML Sitemap only when the site was finished.
• I would have used a smarter solution for author names. I think single-line text fields with multiple values turned on would be a nice solution, but I haven't tried it out yet. Then I would use Views for listing articles by a particular author, instead of the standard taxonomy lists.
• I would (will?) probably make a link on the front page to a list of all research papers on the site. I have a solution similar to this, but a direct link would be better to get more pages indexed by Google.
• And yeah, it took more time than I planned to finish this writeup. If I had written a skeleton for the writeup sooner it would have been easier to finish it later. I'm glad I waited a week or so before publishing the writeup (after finishing writing), since I then had a chance to make some improvements and correct some errors.