We're pressing ahead with our redesign and migration into Drupal of our flagship site. We created a .jpg image of the basic layout and "look-and-feel" we want for our new site that now needs to be realized as a Drupal theme.

So, I put out the word on groups.drupal.org, Twitter and in a few other more local spots online and the response was immediate and plentiful. Seems there are many individuals and firms that do custom Drupal theming. We were pretty sure we just needed a custom themer to adapt something like the Zen theme but lacked the specific skills here (nor the time for that matter) to do it.

I chose an India-based firm called Designs2Drupal and the experience, so far, as been excellent. They were very professional extremely fast - after a 20-minute Skype call and a few emails explaining what we needed, they produced an initial theme from a simple .jpg mockup at no cost for us to evaluate in under 24 hours hosted on their servers. They are now doing some "final" tweaking and will deliver us the theme and then we pay. A very smart way to do business, I reckon, as when people see the work you do before payment, they are more likely to follow with your services. I would definitely recommend them.

We will, of course, be tweaking the theme over the next few months to get it just how we want it, but we have in-house staff that know CSS, etc. and will likely work with a local design firm for the more complicated bits. But, to get us going with this process quickly, I highly recommend having a custom Theme developed quickly via a service like the one mentioned above.

We are still working on re-doing our IA and writing and developing our taxonomies in Drupal - what I like to call "the intellectual work." Not that design and theming don't require intelligence - of course they do. It's just that re-labeling menu items and re-doing a confused information architecture are task that no amount of technology can complete for you. So, we're wrapping up our IA processes with taxonomy creation and moving from our content audit > content modelling > personas > user journeys into some hands-on content migration and re-design. To do this, it helps to have a functioning theme in one's Drupal installation!

Note: I have retired 'The Weekly Drupal' column in favor of simply writing about Drupal as topics arise. During our first 6 months of development this year, I could easily write weekly posts as I was new to Drupal. As we move into our content migration phase, I have less time but will still write about Drupal often. You can see my old Weekly Drupal posts here.

Finally, I have a window of time, albeit a brief one, to write about something OTHER than Drupal on this blog. I am, after all, a librarian by training and am interested in, among other topics, metadata standards, cataloging and information retrieval as well as the so-called Semantic web.

For a while now, I've heard about projects involving the use of DBpedia to link data sets and function as a validation tool for information on the web. This concept isn't unfamiliar to traditional librarians or information science folks. In MARC, one has name authority records to facilitate standardization of names, of people, places, buildings, etc. So, the way I see it, DBpedia has the potential to be the (semantic) web's name authority file, or one of them at least.

Indeed, many organizations are already using DBpedia in this manner - see DBpedia Use cases for examples. I did a quick Google search before beginning this post for "dbpedia name authority file" and came up with 2 interesting blog posts that are relevant.

One, on the Catalogablog, about a DBpedia Faceted Browser which "allows you to explore Wikipedia via a faceted browsing interface. It supports keyword queries and offers relevant facets to narrow down search results, based on the DBpedia Ontology." Also on Catalogablog, I noticed this interesting post about the VIAF (Virtual International Authority File), a linked data set of many authority files. Could one use DBpedia in conjunction with something like VIAF? Or, rather, ARE people already doing this?

Another post on 'Modeling your data with DBpedia vocabularies' appeared on this blog. As a relative newcomer to linked data and RDF (well, not really. I've been reading about it for years but never actually WORKED with any!), this post illuminated several points for me, namely, this notion of how some URIs are, relatively speaking, "better" than others as they might provider "richer" ways of linking data. See the example of the Truffaut film in the post...

So, I'm noticing that I'm slightly rambling with this post, and I'm asking more questions than answering. So, I'll conclude with more questions :-)

Is the idea that DBpedia is/could be one of many vocabularies in a linked data web context that could be used to serve the "name authority" function for the semantic web?
So, via SPARQL queries, one could use DBpedia to verify names in other linked data sets?

Wow, I really need to obtain some "hands-on" experience working with some of these standards, data sets, queries, etc. Any suggestions on workshops, conferences or where to begin are very welcome?

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.

Back from 2 weeks of holiday...

We've nearly 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). One of the last bits of work is to get our Google Mini search appliance, which is fully-configured to search all of our sites and subcollections within our sites (thus, why we don't want - right now at least - to replace it as some of our sites and subsites will NOT be migrated to Drupal just yet), to work with our Drupal multi-site install.

Basically, our programmers simply took the Google Search Appliance module and tweaked to accommodate our subcollections and the configurations we have set in our Google Mini search appliance.

We made the following changes to the code of the Module:

modified google_appliance.module line 872 and following
DIFF:

REMOVED: $gm->setQueryPart('client', $client ? $client : variable_get('google_appliance_default_client', ''));

ADDED: $gm->setQueryPart('client', $collection ? $collection : variable_get('google_appliance_default_collection', ''));

ADDED: $gm->setQueryPart('restrict', $client ? $client : variable_get('google_appliance_default_client', ''));

We don't have it working perfectly yet but the basic setup seems to work. It required reassignment of some variables in order to properly handle our subcollections.

Once we get it fully-operations at a basic level (returning good, granular search results), we can then hopefully take further advantage of the above-mentioned modules' other features including meta-tag contstraints, the setting and theming of meta-tags, various display options for results, caching options as well as what seem to be many many great theming options, which has been a big sticking point with the way we currently use the Google Mini - we can't get the search results page to work with our Dreamweaver template to display the results the way we want them. Annoying. This Drupal module seems like it might help in this regard.

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.

This week's Weekly Drupal is all about menus in Drupal. We're using a single codebase to migrate roughly 70 websites to a single Drupal installation as indicated, more or less, here. We're close to having the basic site template for replicating to create the 70 sites and then, in stages, migrate data and roll out the Drupal sites to our users.

As we're controlling the "platform" that is Drupal, we are trying to limit the "Administer" options that our webmasters are offered. For example, we don't want them to be able to administer users, permissions, modules and many other "backend" parts of their Drupal sites. We'll control that central as all 70 sites are using a shared template (theme). So, yesterday we discovered a conundrum: how to allow them to administer their menu (we want them to be able to re-label and re-order their navigation menu) without confusing them with the ability to administer the "navigation" "primary links" "secondary links" etc. menu choices that come standard in Drupal.

This, as it turns, is not easy to do (or, if it is, it's not intuitive). We could not find anyway to hide these other menus and only show their live, public menu. So, when one clicks "Create content" and then clicks "Menu settings," all possible menus, even ones NOT visible to them with the permissions we've allotted, are seen as here:

We only want our webmasters to see what's at the top of this dropdown under <Entity Menu> and not anything after <Navigation> - we will control that as admins. Nothing in the menus area seems to allow for this, nor in permissions or roles. We also checked in blocks and can't seem to figure out how to control the menu settings.

We have investigated some modules including Menu per role but Menu settings per content type to no avail. I hope we won't have to find a custom solution but it's looking likely. Anyone have any ideas?

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

A colleague of mine passed on this presentation. There are some interesting statistics in there on the growth and influence of Web 2.0 and social media on the web. It has become clear to me in the last few years that many aspects of so-called Web 2.0 are "game-changers" in that they aren't just fads that will come and go (though some services certainly will), but that they will and already are changing the way we work and interact on the web. Something like Twitter, Facebook and Netvibes will always be there in some form, I reckon.

For example, I would have never predicted 2 years ago that in a typical work day I would:

• use Facebook to chat with colleagues in other time zones to quickly pass on information related to our work
• use Twitter as a resource discovery tool and to interact with others in my field who I have never met and in some cases aren't even sure where they are in the world!
• write a blog (as I'm doing now!) about Drupal, Web 2.0, etc. and receive so many good tips, hints and feedback that is ultimately helping to build our Drupal system
• be recording, editing and publishing podcasts
• that Facebook and Wikipedia are in the top 15 referring sites to our flagship site

For me, the biggest "game-changers" all revolve around the ease of which the above is facilitated by Web 2.0 and social media. The technology has (finally) gotten so simple that anyone so-inclined can:

• create a website using a web content mgmt system
• write a blog (or microblog - Twitter)
• create a wiki
• create a podcast
• share everything from videos (YouTube, Blip) to PowerPoints (Slideshare.net) to articles and links (Facebook, del.icio.us, etc.)
• and many other examples

Clay Shirky's "publish then filter" mantra is now the norm. The "conversation" as I like to call it when I teach workshops about Web 2.0 has begun and anyone is welcome to contribute. And, Drupal, IMHO, is the perfect CMS for this environment. We're about 4 months into our development and are very impressed by the ease with which one is able to create blogs, wikis, RSS feeds and other collaborative and "social" web environments.

For more on Drupal, I write a weekly column,The Weekly Drupal, about Drupal from the perspective of a new user. Use this feed to subscribe.

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 blocks. In our project, where we are migrating 70 websites into Drupal as indicated here, we will be using many blocks to create panels in various regions of our theme. So, a question has come up that we assumed Drupal must have an easy solution for: how to control block visibility per page.

For example, we want our 70-odd webmasters to be able to turn on/off blocks in the context of a given page. It seems the only built-in way to do this, as the default behaviour for blocks is for them to be displayed site-wide, is to use this part of the block configuration:

which we find to be not so user-friendly. Ideally, when users create content for their site(s), they should be able to specificy which blocks should appear on the page they are creating AT the time of creation.

So, we did a little research and chatted with our consultant and have as of yet not found any pre-existing modules that easily facilitate this. Odd, considering that it seems like something many people would prefer for their Drupal sites.

So, for now, we're looking at options such as using CCK fields that control this behaviour per page with some php that tells the block to appear. Or, we'll simply provide very detailed training on how to use the configure option above and list the pages where a particular block should appear, though I could imagine this getting VERY cumbersome if you have 100 or 1,000s of pages on your site.

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.