Weekly Drupal

We've now completed the template site to which we can replicate in order to migrate our 70 affiliate sites into a single codebase, mult-site installation of Drupal (as per this page). Next is to create test sites for our beta testers - 7 of our 70 site webmasters volunteered to be early testers of the system.

Here's what we've done, in a nutshell:

- We have approx. 70 existing, affiliate sites to our flagship site. We needed to give them an easier and more stable way to manage their individual sites. Cue: Drupal.

- We've recreated our home-built, proprietary website builder in Drupal using the infrastructure mentioned above (multi-site install, single codebase).

- We've employed several modules to meet our needs, including:

• Menu item access (Provides flexible menu item access control. Something we needed to control what our webmasters can and can't see in the menus area - we only wanted them to see their site's menu, no admin menus)
• Google Search Appliance integration (self-explanatory - we own a Google Mini Search Appliance that is fully-configured. We want to contintue to use it in conjunction with Drupal Search)
• Menu Translation (also, self-explanatory)
• AddToAny (social bookmarking tool)
• IMCEmkdir (allows users to manage directories via IMCE)
• Region Manager (super cool module that lets users control  block visibility/configuration per page)
• among others...

- Also, we did have to write a few custom modules (only 4 so far) including one that pulls content (a la SSIs) from a non-Drupal site.

Now, we plan to use this basic template site and replicate it to re-create our affiliate sites. Each site will be given a test URL for learning Drupal and evaluating the system. Shouldn't be too difficult for them as we've highly controlled the interface. They only see this:

"System pages" aren't active actually. We're trying to figure out a way to hide that option. So, they can create the three types of content seen above, manage that content (edit, delete, etc.), modify how items appear in their menu and control which feeds are aggregated on their site. That's about it. Highly-controlled environment but that's how we'll use Drupal for now. The previous, proprietary system was extremely limiting. Drupal's WYSIWYG editing is a dream compared to the old system!

After the 7 early, beta testers have had their go at testing the system, we'll tweak it even further and correct and bugs/errors/oddities. Then, we'll migrate the other 60-odd sites to their own Drupal sites. One huge hurdle that we haven't yet figured out is how to enable/disbale modules across all 70 sites without having to go in one-by-one and tick boxes on all sites. The way we have our multi-site installation set up, this is what is required at the moment. So, we want to get the basic template as final as possible, before we create 70 websites from it!

Switching topics, I'm sure everyone has heard this news so far but whitehouse.gov is using Drupal - see Dries post. This is, indeed, something for the Drupal Community, of which I am barely 6 months a member, to be VERY proud of. Drupal's flexibility and modularity are some of the main reasons we chose to use it for managing our sites. Congratulations to Dries, Drupal and to the US Govt. for picking such a great system for managing their sites!

The Weekly Drupal is a weekly column on mavergames.net about Drupal from the perspective of a new user. Use this feed to subscribe.

We're making some nice progress on the creation of a template site to which we can replicate in order to migrate our 70 affiliate sites into a single codebase, mult-site installation of Drupal (as per this page). We have a group of so-called "early testers" who will have their sites migrated first and will then perform some of the basic operations for managing their site: creating content, managing their menu, blocks, etc.

So, it's now time to start a support site. I chose a very simply theme (actually the same theme as this blog) - the Clean theme. Authentication will be based our external user database, as will be the case with all of our sites. We've decided to start the documentation and instructions on the site in a very minimal way and we've enabled both commenting and forums in the hopes that the users (early testers) themselves will give us hints as to what doesn't make sense and what bugs they have encountered.

Also, Drupal's built-in forums are a great way to have users discuss issues and perhaps help each other learn the system. Eventually, our hope is that our support site will become a support community site and our users (the webmasters of each of the 70 sites) will share tips and offer direct feedback to us in an open and transparent manner via comments and forums. The site will be password-protected and we're using Drupal's standard permissions and roles to manage who sees what.

Our next big challenges are:

• integrating our Drupal sites with our Google Mini search appliance (we want to continue use the Google search appliance we have as it is pre-configured to search our many collections of data, many of which will NOT be migrated into Drupal)
• recreating our podcasting apparatus (I have some good info on this already. See this module and this video)
• re-theming our flagship site and re-doing the information architecture (not really Drupal challenges, per se)

The Weekly Drupal is a weekly column on mavergames.net about Drupal from the perspective of a new user. Use this feed to subscribe.

Please note: there will be no Weekly Drupal for the next few weeks as I'm away. So, look for another post in early October.

A while back, I wrote about taxonomies in Drupal - see post. We're now at the point where we're creating first drafts of our main taxonomies - a "master" taxonomy for organizing more or less ALL content on our flagship site and a few auxiliary ones for information like news and archives.

So, I'm revisiting some of the links and presentations from my previous post and doing some more research on how best to go about creating our taxonomies. There is an interesting discussion here, by the way, on the whole nodes/content types vs. taxonomy for organizing content in Drupal sites in which I definitely feel, with my limited Drupal knowledge (3-4 months as a user), that making everything a taxonomy is NOT the way to go. Content types and taxonomies are nicely complementary and should be kept that way.

Anyway, we've been in an IARD (Information Architecture Re-Design) process for about 9 months now and have so far created or done the following:

• Domain model
• Content audit
• Personas
• some user interviews in the form of conversation with stakeholders, information gathered through a wiki, some polling and surveys
• Wireframing and prototyping

and are doing some content modeling (slightly out-of-order!) now. The domain model, content modeling exercises and content audit are all informing the creation of our "master" taxonomy. It's tricky stuff. I'm a librarian by training and thus have some significant experience with many classification systems (Dewey, LC, Dublin Core, etc.). But, keeping things simple and allowing for flexibility (not letting the level of specificity get too high or granular) is difficult.

So, here's what I'm reading to help:

• Lullabot: Drupalcon: Information Architecture to Drupal Architecture (and associated presentation)
• Content Modeling article
• Morville and Rosenfeld's Information Architecture for the World Wide Web - beginning on page 313
• Using Drupal - page 59-61

as well as other IA resources. We're still at least 6 months away from the data & content migration phase so we have time to play around with various taxonomies and how they can help fix our confused IA.

We are still commited to only using 2 of the 3 types of vocabularies that Drupal offers, namely: simple lists of terms and organized hierarchies of terms. We are not planning to allow any free tagging of content initially. So, the taxonomies we employ will, at first, only be used "behind-the-scenes" for content editors to organize content and to aid users in navigation and creation of RSS feeds.

This could prove to be the most challenging part of our project so far. But, for me, it will likely be the most exciting and rewarding!

The Weekly Drupal is a weekly column on mavergames.net about Drupal from the perspective of a new user. Use this feed to subscribe.

This week's Weekly Drupal is about themes. We've been working with Drupal now for just under 3 months, migrating a flagship site plus 70 affiliate sites into the system as per this page. So, I'm a relative newbie to Drupal.

One of our big tasks in the next few months is to prepare some prototypes of possible new layouts for the homepage of our flagship site. We want to showcase them at our big annual meeting. Yeah, I know what you're thinking: "you're redesigning your site while migrating it to Drupal!" Not exactly. We have an information architecture re-design process running in parallel to our Drupal implementation and migration. Basically, we need to migrate our sites into the system as is and then we can begin to roll out design changes, new features, etc.

So, themes. Well, I'm surely not the only one that finds browsing for themes on drupal.org less than optimal. For instance, I would love to be able to browse by layout style (top tabbed navigation, etc.) and features (supports x or y, is x or y compliant, etc.). So, when I discovered the Theme Garden, I was ecstatic.

The Theme Garden is a site that lets you browse through Drupal themes based on version with the content staying the same - it's the same site - but you can see how the various elements are laid out and displayed. Brilliant. Especially as I'd imagine many folks "shopping" for a Drupal theme have already done wireframing exercises and mockups and pretty much know what they are looking for, the just need to "see" it.

I can also highly recommend reading the Drupal 6 theme guide on drupal.org. One question I have relates to the use of sub-themes. If, for example, we have one flagship site using one theme and some 70-odd affiliate sites using a slight variation on this same theme, it seems we should use sub-themes for the affiliate sites, no? This way the affiliate sites' theme will inherit the style sheets, Javascripts, template files, etc. from the "main" theme or parent theme. What are the advantages and disadvantages of having the subsites use their own theme versus a sub-theme? I'll have to think about that one...

So, for now, our plan is to create 4 different prototype homepages made by choosing 4 Drupal 6 themes and altering them for our purposes. In theory, if all goes well, one of these prototype sites/themes will later become our new site theme. Again, since we're re-building our current theme and site in Drupal already, we'll have to migrate one of these themes into our existing site when we're ready to go live with the changes. First, on our test site and then on the live site. But, we're a long way away from that move. First, we have to get Drupal managing our sites and their content.

The Weekly Drupal is a weekly column on mavergames.net about Drupal from the perspective of a new user. Use this feed to subscribe.