About two years ago, I filed a common complaint about the muddiness of Drupal's terminology. So that blog post was addressing the lack of clarity of terms like story/page/post/content and some other things like the "content construction kit" that doesn't actually make content. As a trainer I get to explain these terms over and over again.

Well, I was thinking back to that post while perusing the admin menus of Drupal 7 and I was pleased to see some of the changes (for the better) that have been implemented since May 2008. I noticed that the "Story" content type is now called "Article", CCK's port into core is now called Fields, and even the area that was called "User Management" is being called "People" which was a thought I suggested that earned me a hearty scoffing. That's fine, I've gotten used to taking a little heat as one of those guys that works at the intersection between developers and other people, but I feel relieved that these terms will make it easier for my trainees gel their understanding of the concepts.

No doubt the people joining the Drupal project now can thank all the usability testing that the Drupal Association facilitated, as well as the influence of the D7UX effort, for not having to suffer through some muddy times.

Of course, there are new terms to use and learn - like the difference between "Entities" and "Bundles" in the Fields API. Let's see how my students approach that vocabulary on May 24.

Drupaltherapy has been on the back burner for a good couple of months while I prepared to get hitched on September 12, 2009. It was a nice affair, held at an outdoor education and retreat center equipped with canoes, kayaks, archery, zip lines, kickball fields, square dances, and a whole bunch of other things that make weekend weddings fun for family and friends.

What is making us very happy right now is our use of Drupal as the platform for our wedding website and the use of some specific modules that are doing some cool things for us, too.

We asked guests to share their photos from the weekend using Flickr and our sanctioned wedding tag. We are using Feed API to pull down incoming Flickr posts and create nodes based on each new item, following the steps in my Feed API screencast, and then leveraging Views to make a neat display.

Flickr already provides nice photostream displays and I suppose guests could just look to Flickr to see the collection of tagged photos, but we wanted to draw our family and friends to a central place where we could control more of their experience ourselves. So, to replicate some of the Flickr features we slapped in a Views Slideshow, a recipe also found in one of my screencasts.

We also tried to harness Twitter for something useful wedding-wise, and the best we could come up with is more Feed API tricks to get similarly tagged tweets into one place. We thought that our friends could possibly communicate with Twitter through our site, so we built a little interface that pulls down tagged tweets into nodes with Feed API and also gave anonymous users the ability create nodes direct through our site.

The only people who used this were the two of us and on occasional luddite family member, so it didn't go according to plan.

There probably are a bunch of tricks that I could have pulled to make this move smoother, but yeah, I my head was in other places. I did want to put it out there that many of the features found in Drupal and in some contrib modules really go a long way for nailing down the basics of a wedding site and I would be happy to talk to anyone who wants to try it out. Connect with us on the Weddings Group and we can talk there.

Anyway, you'll be seeing more of Drupaltherapy now that the big day has come and gone, starting promptly with a new set of Drupal training sessions in San Francisco on not just one day, but two!.

One half meeellion nodes...

Someone out there must have noticed that Drupal.org hit its 500,000th node on June 23, 2009. That's a half million drops in the community pool that makes this project so excellent. The lucky winner is seanr with a module release.

It looks like Drupal.org is ramming through about 1000 posts a day. At this rate a plus the exponential growth of this community, there is no telling how soon we'll hit that one million mark. We just crossed the 250,000 node mark 14 months ago. I'll make a suggestion that someone start a pool for the date of the one millionth node.

I'll cast the first vote for Sept 25, 2010. Yeah, that's soon, but mark my words.

I had the pleasure of arranging for four individuals to present on the topic of Drupal oriented training at Drupalcon on March 7, 2009, in Washington DC. Barry Madore from Advantage Labs, Alex Urevick-Ackelsberg of Zivtech, Lee Hunter from the Drupal Doc Team, and myself from Drupaltherapy, all had about 15 minutes to weigh in on our experiences building building curriculum and training for the different wedges of the Drupal community. All of our presenters' notes are written up through their blogs, now linked from the session page on drupalcon.org.

My goals for the session were to provide some resources to the community to develop more Drupal training opportunities. There is a gradient of Drupal knowledge with both ends of the spectrum expanding. Our training opportunities should expand proportionally with the base of new learners entering the community.

It's such a broad spectrum but only a small scope of training has really been cultivated. I work and thrive in the entry level learning realm because I saw this as the area with the greatest need. I've been building a very successful model teaching concepts and best practices to new users and I've come to type cast them into a few general categories.

There are people that don't intend to ever use Drupal but need to know enough to understand its potential, like executive directors scouting the software to determine if it's right for their organization. There are people who have just adopted Drupal and have to acquire a new skill set before starting a project. There are organizational, educational, and business staff who found themselves using newly deployed Drupal web applications and need to learn only a tiny portion of Drupal to perform their jobs. And finally there are also small scale developers and/or web hobbyists who roll out a few small projects each year.

One of the points I wanted to drive home is what the process of Drupal skill assessment could look like. I make a point to interview new training clients to determine the amount of Drupal knowledge they have and how they learned it. Many times this includes determining what knowledge a client has to unlearn.

I don't have a linear process. Measuring a person's understanding of Drupal has not been, so far, a system of checking boxes or circling numbers. There aren't many other benchmarks set outside of Drupal that can describe their potential existing knowledge. People with a high degree of PHP knowledge believe they know a lot about Drupal, people with no development experience outside of their Flickr, Twitter, and Facebook accounts all believe they know almost nothing about Drupal - and neither scenario is necessarily true. Drupal is also a moving target that changes all the time - CCK is easy to understand, as an example, but how can we evaluate the potential for a learner to understand future changes in the project, like the Fields API.

It makes a lot of sense to first evaluate a learner's goals. This can tell you a lot especially if a learner is mid-project or task. Then once you understand the goals, you can determine how close to those goals the learner is already. And then build a training based on reinforcing concepts they already grasp and closing the remaining gaps.

I have a basic curriculum that covers the most fundamental concepts of the Drupal project, and I can reshape however a client needs. This comes as a result of answering requests for training in the same things over and over. I recommended in this Drupalcon session that consultants and development shops being to cultivate their own training programs based on the work they do, especially if their clients come from similar flavors of business. There is not only potential to serve the community knowledge void, but also the opportunity to maintain a recurring training program that add value and to their development work. The way I see it, keeping training as an afterthought is missing out on a lot of opportunities.

At some point in the Drupal learning process, after trainees hit a very specific point in the curve, every single one of them needs to branch or fork out in some specialized learning direction and meeting those needs becomes more difficult. That point comes right after grasping core and a handful of the really popular contributed modules. Here is where the other presenters picked up the thread.

Following my comments, Barry Madore of Advantage labs described their Drupal "study hall" mentoring programs in Minneapolis.

Alex Urevick Ackelsberg discussed his recent experience with training members of his fast growing Drupal development shop Zivtech.

Lee Hunter batted clean up with a discussion on developing documentation for training, particularly the difference between code-driven documentation versus doc-driven code.

There were several really good questions and comments to follow the discussion. Some great suggestions were made to aggregate our training curriculum into central places, and to develop standard Drupal certification programs (like we discussed in Szeged last year).

Unfortunately, we were one of the 9 sessions out of 100+ that did not get videotaped for the web. It may have been conspiracy, but its more likely that they put resources into the concurrent Fields API session happening in the room next to us.

Oh well.

Wrapping up today at Drupalcon by pushing 12 hours of tweets tagged with #drupalcon into Wordle. I did have to reduce the instances of "drupalcon" and "2009-03-05" in order to make the other words large enough to be legible, but this is the only processing I did of the tweets themselves. Turned out a pretty sweet image and to get it in a big format then just click.