Drupal

I've fallen in love with the wiki tools for Drupal. I've long wanted to abandon the PMWiki and Jot Wiki I've used over the years in favor of something that's utterly simple, integrates well with the set of tools I currently use, and works like a wiki should. The set of modules currently offered for Drupal finally lets me do this with the forward linking and MediaWiki syntax that I come to expect from a wiki.

To see how this all works in Drupal, you have to check out the demonstrations and simple documentation for using wiki_tools and the pearwiki_filter modules. Getting up and running will require a few steps to install the right modules and get everything configured—this isn't a single module plug and play task. That How To page gives you the recipe for configuring everything, including installing some nice experimental plugins like the section_edit module. I installed my wiki on a separate Drupal site rather than under my blog in order to keep things simple, but you shouldn't need to if you want all your content accessible in one place.

Try it out. While it lacks some of the more advanced features of Jot, e.g. date-related functionality like creating to dos, it's more than adequate for most note-taking wiki needs. For light project management activities, I might prefer something like Jot's PM module instead (or BaseCamp, but I'd prefer free over fee), but for now I'm trashing my wiki notes on Jot and using my own Drupal wiki instead.

In a week I will be leaving Alcatel-Lucent after 8 years to help start up a new web business for a tv electronics manufacturer. More on that later. This move means that I will no longer be offering consulting services.

For the time being, I'm stripping down this site, by using the white skin, removing the home page, the splashy top graphic, and all references to consulting services. Oh, and have finally upgraded to 5.x since the contributed modules I use are all up to date now. Call this phase 1. I'll most likely evolve the design of this site to use graphics and extraneous navigation a bit more minimally, and will focus on the blog again. That will be phase 2, but don't know when I'll find the time to do that.

Luckily, my new office is in Manhattan, and I'll be bike commuting most of the time, so I'll have a lot to blog over at love & sprockets, the new bike blog. Anyway, hope you enjoyed my orange phase. On to the white and gray site for the time being.

Moshe and merlinofchaos for pointed me in the right direction for the function to modify if you want to remove divs that are output in a list view block via the Views module. To strip out those divs, do something like below in your PHP Template's template.php file:

Thanks to everyone for the suggestions.

It's the little details that make the difference in a clunky design and one that communicates with brevity and elegance. One thing that I've always hated in my Drupal blog is the wordiness of my author/date/comment line. You know what I'm talking about. In node.tpl.php it's the stuff you get when you print out $links.

Well, I resolved to make things cleaner in the next blog theme I work on, so that I can get displays more like this:

By jibbajabba on 21 Feb | 1 comment

Rather than this:

February 21, 2007 - 10:06am
jibbajabba's blog | 1 comment

I know it seems like such a minor thing, but it's little things like wanting to change that, but being too lazy to go figure out how to do it that keep me using the default display in my themes. Well, no more. On the bike blog (Love & Sprockets) I'm going to do it this way:

Or using the format_plural function, which chx pointed out:

Ahhh. I feel better now.

It always bugged me that the a destructive button like Delete has the same weight in Drupal forms as Preview and Submit. To try and prevent clicking on destructive buttons, I find it a good practice to make those buttons less important, yet still available. To do that, you can simply style each of the button types Drupal puts out--edit, submit and delete. Here's an example making the submit button boldest, and removing the button style of delete.

How sweet is this color picker:

I installed today to try out that those new themes and nearly wet my pants. The web-based wizard for the installation process is the best. It really is about time that Drupal gave users an installation process this simple. The new Garland and Minelli themes are sweet, as is the ability to pick a custom admin theme via the system configuration options.

I installed my urlgreyhot theme and it looks like no changes to my PHP Template theme are required. Yes.

I'm loving it. I've been using Drupal for 5 years, and this version looks like the one that will really get the attention of the holdouts. Usability improvements in the installation and admin UI can really be felt here. There's no reason not to use Drupal now.

Kudos and a lot of appreciation to all who are making this happen.

I found an interesting post on the Drupal support list about finding the right method for using taxonomy in Drupal.

I am using the taxonomy module and have several vocabularies added , several look like this: 'Politics' which has Single Hierarchy and Multiple select, and has several Terms such as 'Countries', 'Groups', 'Ideas', and Item such as countries has 'sub' Items such as 'USA', 'England', 'Germany' etc. Now.. whenever I post a new article or blog entry and tag it, say.. USA, I still need to tag Countries and Politics as well or otherwise when clicking Countries it will show an empty list. Is this the right practice?

I think this is probably the biggest issue when approaching description problems with a content management system. In large enterprise CMS, the problem might require maintaining taxonomies using the sophisticated tools for finding and grouping content based on rules created by the taxonomy tools included with or added to the CMS. But people dealing with Open Source CMS have been left to the task of figuring out how to deal with these same problems with a less sophisticated set of tools tools and plugins.

Fortunately, Drupal has recently added the Views module to at least help admins deal with display issues more easily. Taxonomy management is an area that still needs more attention. But for most people, the basic question about what practices are best suited to taxonomy use in the more full-featured systems like Drupal persist. Do you use hierarchy in taxonomies? Do you just free tag everything? How do you set up taxonomies for the outcome you expect or desire?

Of course it depends on the type of description/categorization you intend to do. To pick the right method for creating taxonomies you need to focus on how you want to extract or display that information and on how much effort you want to expend on maintaining it. The Views module seems like it will give you the flexibility you need in most cases for creating display rules. But what you want to consider is whether or not the structure you are creating will require you to spend time maintaining the views over time. For instance, given the Drupal Support example above, say the admin starts with the following structure in his Politics taxonomy:

• Countries
  • Afghanistan
  • Algeria
  • Andorra
• Groups
  • Al-Qaeda
  • Amnesty International

Now, say that he wants to display all of the content that comes in under the Groups category, including all of its subcategories. He can create a Groups View and select each descendent term in the taxonomy filter. But I don't believe there is a way to simply say "give me every descendent of the Groups term and show that in my view". If there is a way to do that with Views, I'd love to see it. So instead, he has to select the terms in the filter's select field.

But, say he adds "Animal Rights Advocates" under Groups. Now he wants to update his View. What I think he would need to do to update the view is go back to the Views filter and now select "Animal Rights Advocates" as well. He would need to do that for every term added to Groups.

In the example above, Countries and Groups are facets of description. And while he can choose to create a taxonomy for each facet, he's chosen to create a single taxonomy for the Politics domain and insert facets under each one.

In the past -- prior to the release of the View module -- I've worked around the display maintainenance issues by creating separate taxonomies for each facet. See the taxonomies in use on my blog for instance. Yikes, right? I've used that separation to break up the display of my metadata below each entry so I can show terms broken up by taxonomy, e.g. Subjects, People, File formats. The output looks like this:

Works for that display need under each blog entry. But you'll notice when you look at the taxonomies for each facet that I also added some complexity by using hierarchy within some of the taxonomies, e.g. Subjects and People. Taking the People example, if I wanted a view that only showed Groups of people rather than individuals, I'd run into the same maintenance problem you see in the Politics taxonomy of having to manually update the Views filter again.

To make matters more complex, I am starting to use and love the new free tagging capabilities of Taxonomy for selecting my terms. I started to do this because my Subjects taxonomy is rather large and choosing multiple options in a form Select can be problematic. The free tagging options allow me to select terms much more quickly. The problem is that I've also become accustomed to adding terms using this tool. This change in behavior of "tagging as you go" conflicts with my previous behavior of first adding terms to the hierarchical taxonomies before I blog because as I now add free tags, they end up in the root of the Subject Taxonomy, requiring me to still go back and file each term I add under a parent for the hierarchy to continue to make sense. And because the Taxonomy module doesn't presently provide a way to filter terms in the admin view, e.g. to find the term I just added without paging through the list, this task has become cumbersome as an after-the-fact activity.

Here's what I see in the Categories section when I create entries in Drupal:

This is a tricky issue, because I'm at a point where I could decide to go two different ways: to dump the hierarchy within taxonomies because of the level of effort it requires to maintain; or to continue to maintenan the hierarchy within taxonomies because it provides some value in terms of browsing. I'm sure the browsing of hierarchies is only valuable to me, but when I think about the amount of energy expended compared with value, my gut tells me that it's not worth the effort to maintain.

Doing this kind of hierarchical taxonomy management on a blog is probably unheard of, but in certain applications, e.g. enterprise content management it can be absolutely warranted and/or required. As an information worker I tend to try out different methods for describing and organizing information to help me understand which practices work in different contexts. The last several years of using taxonomies on this blog and now introducing free tagging have helped me see that each method holds utility in different circumstances, but getting both to work together nicely is a bit tricky.

So, this may not be a very clear answer to the question about best practices for taxonomy. It does serve as a cautionary tale about how being very descriptive and maintaining relationships within one hierarchy can leave you with maintenance concerns as you scale up. In terms of ease of entry using Drupal, creating facets within one taxonomy might make it easier to select terms when you are creating new content and doing free tagging using one field in Drupal. But organizationally speaking, that approach seems to presents you with some challenging display and maintenance issues, for now at least.

I had been looking for literature comparing the behavior of Intranet vs. Internet users as follow-on research from a blog entry I wrote about Ze Frank's Web 0.2 presentation and in reponse to a colleague's comment on the subject. The harder questions came up when I began exploring the topic of Internet/Intranet culture. As the increasing community of prosumers push the use of technology, as Internet users flock to social software and collaboration sites, how does this affect users of technology in the enterprise. Are business users taking risks with information technology? If they're not, why not? How does this all impact the evolution of collaborative technologies and how does that information feed back into products.

What I ended up reading didn't really answer all of these questions, but did get me to start thinking more about the evolution of blogs as social software. But, first, I want to talk about what I did find in the literature. The observations I found about intranet users were totally obvious. Culture and politics are key influencers when it comes to collaborating on the intranet. I'd already been saying that in my blog presentations. It's obvious. No major surprises there. Nothing in the research or academic literature seemed to be illuminating beyond that.

In the middle of attempting to read through papers, Boris Mann pointed me to a comment referring to karma as a motivator for collaboration in Drupal. Boris suggested that we might get to a point using Drupal where karma could be the basis for incenting collaboration.

I began wondering how these ideas apply in the corporate enterprise if at all. "This is excellent", I thought to myself after reading through this. Drupal developers thinking about more complex problems related to collaboration and how they can be solved with technology. But, to return to my problem, is this type of enabling technology pointless given a culture where people are not inclined to share? I once called this type of space a clenched-fist knowledge culture.

This is the space I was most concerned about when this inquiry started, because I perceive large companies that don't have a rich participatory information ecology to be positioning themselves for failure when it comes to knowledge management. But, while I'm generally interested in the topic of how to help transform clenched-fist knowledge cultures into open ones, that's not where I want to spend my valuable cycles these days. Instead, I'm interested in what to do to enable participants when the cultural space is open. How do you help them express themselves in that space?

I was reminded of some KM vendor presentations I had been to a few years ago where monetary incentive was mentioned as one key to sustainability. I don't remember the names of the products, but I found the suggestion interesting, but philosophically wrong. Years later, the explosion of blogs as the 99 cent KM solution emerged. The idea of incentive was interesting, but using money as the motivator was wrong-headed. With blogs we see that individuals may be more driven by selfish and unquantifiable incentives, e.g. self-promotion, prestige, authority, participation in a communal system because it gives back what individuals put in. These are not external motivators. They arise organically from within individuals -- from the grassroots.

In spaces where open knowledge sharing exists and where people seem to be getting as much from collaboration as they give, social software seems to fluorish. On the Internet, people take to Wikis, Weblogs, social networking communities and social bookmarking communities like mosquitoes to still water. Viewing the enterprise as a cultural petri dish, all you can do is set up the right environment and watch to see what grows.

For the most part, you can't simply drop social software into any cultural situation and expect it to "take". (I'm thinking about eggs attaching themselves to uterine walls as I write this. Sorry. Enough with the bad metaphors.) Install an enterprise wiki into a cold corporate space and no one will hear it die it's slow death. Perhaps a few users will exploit the technology, but if if the technology doesn't fit in with the culture, you're probably wasting valuable time. At a local level, this might not be the case, but in a large enterprise this might not cut it. Think of behemoth enterprises that drop SharePoint into the mix just because they can. Creating the pre-conditions for the right culture may seem to require withcraft or alchemy rather than business savvy. I can't tell you how to get that kind of change, although I'd like to see literature that talks to that issue.

If and when the cultural pre-conditions are right, then the enabling collaborative technology can be introduced. But we need to be certain that it focuses on objectives that provide value to users, that design for ease of use, efficiency, and relationship formation. When the object of the technology is relevant and the tool is implemented correctly, expression within an open culture may happen naturally and a rich, diverse ecology may emerge.

IBM Internet Technology Group chooses Drupal to deploy of a collaborative Web site. The article series describes their project requirements and why they chose Drupal among other CMS frameworks including Mambo, Typo3, Ruby on Rails, Movable Type, WordPress and TextPattern.

If you've been using Drupal's new freetagging option for the taxonomy module, you may have run into a problem I have as someone who tags items richly. The fields for entering categories as freetags is only 100 characters long. Without doing any overrides in the template files, the quick fix I took was to modify this line in taxonomy.module's taxonomy_form_alter function.

Find this:

'#maxlength' => 100,

Change to something like this:

'#maxlength' => 200,

Yes, I know this will get removed when you upgrade. But I'm lazy, so this is how I did it for the moment.