CMS

I have now taught my Content Management Systems class twice for the University of Kentucky. This time it was online, taught to library and information science students. I have already written up my thoughts on Drupal as an LMS.
Now I want to describe the class itself and compare it with the first time I taught it face-to-face.

'Third boy, what's horse?'
'A beast, sir,' replied the boy.
'So it is,' said Squeers. 'Ain't it, Nickleby?'
'I believe there is no doubt of that, sir,' answered Nicholas.
'Of course there isn't,' said Squeers. 'A horse is a quadruped, and quadruped's Latin for beast, as everybody that's gone through the grammar knows, or else where's the use of having grammars at all?'
'Where, indeed!' said Nicholas abstractedly.
'As you're perfect in that,' resumed Squeers, turning to the boy, 'go and look after MY horse, and rub him down well, or I'll rub you down.
- Charles Dickens, Nicholas Nickleby

The foundation of the class is hands-on development, which means the following:
- you don't learn Drupal or CMS by talking about, but by creating a CMS of your own on your own
- the instructor is there to facilitate your learning and get you unstuck when you are confused
- even though it is all about practice, we don't teach the students where to click in the GUI; we teach them why to click there
- following from the above, even though the ending two thirds of the semester are all about practice, we start with the foundations - understanding what content management is, and what web technologies it relies upon.

Class structure

You can see a full syllabus and schedule here; let me point out the key elements:
- 40 "tiny tasks" throughout the semester - small applied checkpoints to monitor your mastery of the skills
- 3 short papers based on readings (mostly selected from the excellent A book apart series) that illustrate adjacent fields - knowledge management, content strategy, and mobile development
- a Drupal Sprint - a 24 hour window to create a CMS from scratch, to test students' strategy and time planning skills, as well as their knowledge of Drupal
- a final project - a full-blown CMS on which we work throughout the semester - from the initial ideas to one-on-one consultations, to peer reviews, and finally to a complete product.

Online or face-to-face?

Having taught it twice in both formats, I can say it can be done either way; I liked the online version better - probably because it was my second time doing it and some of the original bugs have been worked out the first time around. There were two big changes I had to make going from face-to-face to the online environment:
- write down explicitly as many ideas and explanations as possible and provide them as resources on the course support site
- deliver more of the materials (videos and articles) early in the semester since the students need the resources up front to start working on their ideas and kept coming back to them throughout the semester and asking questions.

Next steps

Here are a few things I would like to do differently next time:
- run the course sites and the student sites off of a robust platform optimized for Drupal rather than a generic shared hosting solution
- have full transcripts of all videos; improve the video delivery interface taking cues from the beautifully designed and beautifully usable interface of coursera
- have more guest speakers (ran out of time this time)
- add a private communication tool for students at the course support site (private messages rather than forum messages or comments)
- connect the course into a two-course sequence with our Information Architecture offering, moving all the theory out into the first semester (like our discussion of content strategy) and then going more in-depth into Drupal in the second semester.
- scale the model I have developed for Drupal to teaching other IT skills (computational linguistics, analytics, usability, etc)

If you are interested in learning more about my course or if you would like to collaborate on any of these ideas, let me know or just post a comment here!

Part of my job is helping UKIT develop a Drupal support infrastructure. To that end, I sometimes meet with Drupal developers on campus to help them with their projects. Last week I talked to a web developer (I will protect her identity) in a large unit here at UK.

She has very limited familiarity with CMS or with Drupal, very little time, and a list of duties so long it is hard not to entertain suicidal thoughts when looking at it. She is expected (single-handedly) to migrate their existing web presence into Drupal, and along the way to build a ton of new functionality - some of which will require the interaction with other systems on campus, which most likely means additional programming (in which she has zero experience). And as a little aside, her boss asked her to add functionality for both mobile phones and tablets.

This sounds like full-time jobs for at least three people with high end IT skills, and instead we are going to have part of the time of one regular employee. Why does anyone think this could work?

I think the most likely candidate is management's ignorance of the complexity of the problem. They see the switch from a web brochure model (=a bunch of static pages organized into a simple tree) to a CMS as something similar to selling a Ford and buying a Toyota; while in fact it is more like trying to give up a bicycle and getting a submarine to do the same work.

But even below that is the problem of technology in general and information technology in particular being offered as a magic solution. The late Steve Jobs is perhaps the finest example of spreading the myth - in fact, the original iPad advertising copy described it as a "magical device". He was so fond of pitching Apple software and hardware as fast and easy to use, that there is a whole video made of clippings from his keynotes over the years where he always concludes the demo of a feature with "Boom!" to show how a task that used to take forever is now super easy: http://www.youtube.com/watch?v=r8L39UwOS-Y

This approach is not new - as early as 1888 George Eastman famously claimed to be doing the rest if you just press the button. But it is ubiquitous and because of that very harmful to the professionals working in the field.

It is no surprise that modern CEOs and administrators think that switching to a CMS involves pushing a button (and BOOM! - it is done). That means that as you work on these projects, you want to be very clear up front with your clients about the complexity of the task. You have to educate them about the time and resources that it takes to create complex systems like CMS. The best project may fail if you don't educate the client and set the expectations right.

I have been doing Drupal 7 training for UKIT since last December. I have taught 6 sessions, 60 people, most of which were beginners in Drupal.

I always start the session (after my introduction) by asking the participants to tell us who they are, and answer two simple questions - What project brings you here? and What do you think Drupal is? These questions let me adjust to the needs of the participants, and also to gauge their IT knowledge level.

There are a few answers that are recurring:

University supported CMS
Since UK is now behind Drupal, people want to know what it is all about, they want to evaluate the solution for their needs. This one is particularly common if their sites are at the end of the cycle and they are looking for an upgrade path.

Ability to delegate
This is probably the most common reason - not wanting to be the sole gatekeeper on a site, but being able to delegate content editing and creation to several people in several different users. A variation on this from more advanced users is to expect an editing path - setting up different roles and approval processes.

No HTML by hand
People want a high-level tool that will do the dirty tagging for them. They are then very disappointed when you tell them Drupal doesn't come with a WYSIWYG editor out of the box. I like to tell them that Drupal is so much more than a web-based Dreamweaver, but they usually refuse to listen.

Modern technology
This one has many flavors - SEO, analytics, social media, video, flash, PHP, HTML 5 - people want a system that would support all the modern stuff, and that would not lag behind. They are usually not disappointed - they see how easy it is to integrate "modern" into Drupal, and how fast the community responds to change.

Magic
This one shows up every now and then unfortunately. Perhaps Drupal is that magic tool that we have been promised all the time by IT people - one that would do all the work for us? These hopes must be squished, which I do right away. You still have to do the work, and if you want a big complicated site, it is going to be a big, complicated job.

Only occasionally do I hear anything about advanced ideas - something like integrating with other systems like Blackboard - but that is to be expected since we are dealing mostly with newcomers.

I have just submitted the final grades for my content management systems class. It was a semester long class - hands-on training, 70-80% Drupal. The students were journalism seniors mostly. Their final projects are up online.

This was the first time I taught a semester long class on Drupal 7 and CMS; it went well for a first try, but I learned a few things about what to do differently next time.

- Group project - this time everyone had a final project that they did on their own, a full blown CMS site. Most of the students ended up creating single user / single admin sites with a limited amount of content; it would be great to expose them to working on a multi user, multi admin site with hundreds or thousands pieces of content. With lots of content the actual problems of content management and the advantages of good content management tools (e.g. taxonomies) become more apparent. It is hard to explain Views and Node References when you only have three nodes; but when you have tons of stuff it is easy to argue you need tools to navigate through it. A big site like a group project site can have different types of content, including a full blown calendar. I am thinking it is going to be a travel recommendation site - this takes care of photos, dates, blogs, geolocation data, videos, numbers (prices for example) - and the need to relate them all together.

- Theming - yes it is all about content management; it is all about content, but theming cannot be completely avoided - once the final projects were submitted I found myself saying repeatedly to students how the theme limited what they can do. But I haven't really taught them how to modify themes outside of the provided GUI. I need to spend at least a week on showing how to do at least basic modifications in CSS.

- Other CMSs - I was planning to cover Sharepoint and WordPress but I ran out of time. Now that I am a bit more organized and most of the course content is created and ready to go, I can go back to covering at least 2 other CMSs besides Drupal.

- Cutting edge code - I taught the class in Drupal 7 two weeks after it was released. We started talking about Views and then the Views GUI changed and I had to say, forget last week, let's start again. We never covered Calendars because during the time when we needed it the Date / Calendar / Views / Ctools combo was about as predictable as Fukushima 3. One of the students started working with Views Slideshow and it broke his site. It was a good lesson for me and for everyone else. I knew it could happen - that's why it is in beta / alpha / dev. I am not blaming anyone, just thinking I should take one step away from the very edge next time.

And last but not least, a big big thank you to all Drupal developers - I am just spreading the word, you are doing the actual work. We are all very grateful.

Today I taught the first 90 minute Drupal 7 Crash Course for the University of Kentucky employees. I will be teaching two more sections this week, introducing over 30 people to Drupal 7. Today's interactions with course participants triggered some thoughts about how to extend the training - 90 minutes is barely enough to introduce Drupal functionality, one can easily teach a half-day and a full-day crash course. Here's how they would stack:

Drupal 7 Crash Course: Basic Functionality
Length: 1.5 hours

Goal: Give participants enough hands-on Drupal experience so that they are able to decide if they want to learn it in depth; give enough knowledge to build a basic web site or enough knowledge to begin self-instruction by trial and error.

Content: Drupal as a CMS / Users, content, permissions / Content types / Nodes / Fields / Custom Fields / Creating Content / Editing Content / Comments / Themes / Blocks / Visibility Rules / Menus / Third-party modules: Views / Q&A

Drupal 7 Crash Course: Basic Functionality + Customization
Length: 3 hours (half-day)

Goal: Provide a more in-depth Drupal experience, with a detailed survey of the many customizable parameters; give enough knowledge to plan and build advanced sites.

Content: A more careful and in-depth treatment of the topics of the 1.5 hour course, plus: Installing Drupal / Input formats / Date and time formats / Image styles / Working with images / RSS / Social media integration / Customising search

Drupal 7 Crash Course: Basic Functionality + Customization + Extension
Length: 6 hours (full-day)

Goal: An in-depth coverage of the Drupal core and some of the essential third party modules; provide a full range of skills and knowledge for advanced content management systems

Content: All of the topics of the 3 hour course, plus: SPAM protection using Mollom / Usage statistics with Google Analytics / Surveys and feedback with Webforms / Custom content representation with Views / Filters and Sort Criteria with Views / Exposing Filters in Views / Page layout using Views and blocks

This site has been running on Drupal 7 for over a month - on the beta version of the code. On December 2, the code has reached the release candidate status. Short of a few missing documentation sections and other things, Drupal 7 (http://drupal.org/project/drupal) is ready. So what has changed compared to Drupal 6?

I have worked with Drupal 6 for over a year, developing a large site on it. I don't know much about the code; but I do know what it is like to use this code. I can write HTML and CSS code from memory and I have some knowledge of PHP and MySQL; but I never tried to understand how Drupal works at the code level. So this review is from a site creator / administrator's perspective, not from a programmer's.

1. It is better.
Version 7 is cleaner, better looking, better structured - it is a much more finished and streamlined product than Version 6. It came at the expense of more lines of code, but partially because some of the 3rd party modules of the v.6 days are part of the v.7 core.

2. Installation process is simpler and faster
Installing v.6 involved messing with permissions and configuration files; v.7 does all of that automatically. Not a big deal, but makes life easier. There is also a new minimal install that loads just the essential modules and none of the fluff (at which point the admin menus look a lot like the stark backbone of v.6).

3. CCK is now part of the core.
V.6 shipped with several content types such as article, page, blog entry, or image. To create new content types, you had to install an additional module called Content Creation Kit (CCK, http://drupal.org/project/cck). Being able to create new content types was one of the best things about Drupal; it is great to see that it is now integrated in the core, where it belongs. The integration is done well - it is not just an afterthought, not the icing on the cake - the cake has been rebaked with CCK thoroughly mixed in.

4. Fields and field weights make more sense.
Content types are built with fields - such as title, body, comment, user reference, and so on. These fields can be used in more than one content type, and users can create new fields. There is now a cleaner implementation of sharing the fields - a new admin menu to see what fields you have, and a far better way to order the fields in a content type using weights. You can order things differently during content creation vs. content viewing. For example, if you have a content type called "cartoon" with fields like title, image, body, taxonomy, and comments and set it so that when you create a new cartoon, you are first presented with the image upload field (that way you won't forget the file), but to the reader you present the title first, then the cartoon.

5. It is easier to work with images.
It is easy to set up new image formats - so if you load a big 10 megapixel photo but need to present it smaller on different pages, you can create new templates to fit your needs. You may have one where you need to fit things into a landscape oriented 800x600; or you may need a square 300x300; or a tiny 50x50 thumbnail. You can create as many of them as you please, and then retrieve the needed size for your particular page. When working with Views (the-best-Drupal-module-ever, http://drupal.org/project/views), you can access your file formats directly from Views. Building a gallery of all socialchicks cartoons (http://lensyoga.com/socialchicks) with 200px thumbnails and titles is a five-minute job with v.7 and Views - and you don't need to write a single line of code to do it.

6. Core themes are better.
The new themes that ship with the core are awesome. Bartik http://drupal.org/project/bartik (that I am using), is minimalist without being too stark, and flexible without being too complicated. This is a subjective opinion, but the themes don't get in the way - it is clear that this is high end CMS, not a web-based Dreamweaver. There is a focus on clearly presenting the content rather than on the fluff to frame it.

7. Admin themes are better.
There is now a very clean admin theme; tasks are much better organised, and the theme that is fed to the user is clearly different from the backend that an admin sees - and yet it maintains enough stylistic similarity to not make you feel like you suddenly got to another planet. You can even run all of the admin tasks in an overlay hovering above the content pages. To me that's fluff, but some people may welcome it; and I welcome the easiness with which the overlay can be turned off.

8. Module installs and updates are easier.
Previously you had to FTP new modules and module updates from outside Drupal; in v.7 you can just feed the system the URL of the compressed module folder and it will load it to the server. Small but very welcome change.

9. Cron tasks are automated.
You don't need to run the cron with a server command; there is now an admin panel where you can set up the cron from inside Drupal and specify how often you want it to run. Again, a small but a very positive change that makes the admin life easier.

Drupal 6 was great; Drupal 7 is better in every respect and ready for prime time. For those of us who haven't given up on the open web and who have escaped the Facebook quick sands, Drupal 7 is a superb tool for single-handedly creating systems that five years ago would require a team of programmers and seven figure budgets.