A Hack for Teaching Drupal

01.09.2009

How Do You Teach Drupal Without Inducing Confusion/Boredom Triggered Comas? Here's a rule that has never let me down:

Never interact with the drupal site in any way during a lesson

The person you teach needs to click on every menu link, fill out every form, and as they learn, its your job to start taking off the training wheels. At first, you'll have to point them to where to go to add a new taxonomy term, but make it a point to later ask them to add a taxonomy term, and see if they remember how to find it.

This "hack" works well for two reasons:

1) It prevents you from going into conceptual monologues

When I'm at the helm, clicking around, and "explaining concepts", its almost impossible for me to avoid inflicting a salvo of turd bombs on my hapless student. For a moment, read this: (if reading this text doesn't make you want leave this article, there's something wrong with you)

In Drupal, a node is a grouping of data, which we call fields. A node is different from a user, and block, because its content, which leverages drupal's rich nodeapi. On this page you can add, edit, and manage node types using these tabs. By clicking "edit" I can edit node settings, like whether I want comments to be threaded, or flat. Isn't that exciting? By clicking "manage", I can add new fields to my node, which can be of many types including, text, number, decimal, computed. These fields have rich set of options, including setting the maximum length, making the field required, and even entering in custom validation code for node form submits.

Not only is this a terrible way to teach, best case is that your student is completely lost (probably on something as simple as the difference between nodes, and node types, the fact that a "field" is a specific CCK concept, and not a form element), but most likely, they are not paying attention anymore. Monologues + projectors = brain death.

Let your students direct what you are teaching them

Don't teach them about blocks. Teach them how to put that new announcement in the right sidebar. Don't teach them about views.Teach them how to edit their press release page so that it only shows titles, and dates, and a "short blurb" field. As they gain more understanding, you'll find they naturally gravitate towards more advanced concepts. Best of all, you don't have to waste time talking about boring things that they don't need to know, or blabbering about stuff that they already understand.

2) The student is always on the spot (meaning, paying attention)

Nearly everyone has a tendency to worry about asking "stupid questions" (they are never stupid questions). If a student actually has to do all tasks required to teach something themselves, they won't be able to hide the fact that they missed a critical concept. You'll know fairly quickly if you need to do a better job of explaining the admin menu and how it fits together, and the pattern it follows. You also will probably find out that they still have conceptual issues that need to be cleared up between the very similar taxonomy, block, and menu pages. You see, every little task becomes A TEST. Testing is about taking off the training wheels. Even when they *fail*, the very fact that their brain had to struggle before hand means they'll have learned something. Its uncommon for someone to fail tests like "go to the block admin page" more than 2 twice. Eventually, they'll know where to look even when they've never seen it, and you are just now introducing the concept. Just keep testing them. After all, its really a test of your teaching skills, no?

While this makes teaching and learning more challenging, they learn dramatically faster then the monologue projector methods, or constant email support alternatives. .

*There's no exceptions to anything I write, FYI. If there were a lot of variables, a situations where these rules didn't work, I'd cover them one by one. Because Drupal Planet readers love long winded tracts that refuse to take sides.

Comments

I was thinking about your

I was thinking about your comments about party games played by us "white n' nerdy" folks.

I hear 2600 puts on some exciting thrillers like dumpster diving, war dialing, and war driving. It reminds me of Dr Hooks song "Freakin' at the phreakers ball'.

Then there are parties based on software testing and games like 'bug bingo'. Wow!

I'm glad I'm old enough that my partying days are poop.

I was thinking about the

I was thinking about the parties Dimitri throws.
(http://badcamp.net/session/awesome-testing-party)

He makes people half my age feel "old n' useless".

Great photo, and my favorite

Great photo, and my favorite description of the Dmitri:
The 12 year old in the front is teaching the 30 yr olds in the room how to use the programming tool created by the guy in the flannel.

I'm only 26, but yeah -- my

I'm only 26, but yeah -- my partying days are mostly over. I used to throw parties at my house at least once a month (this was before 2005 -- so I hadn't yet learned what CSS was), and if I had a son, I'd tell him to throw a party every monday night when he was college and it was summer, and call it "margarita monday".

However, I can't help but remember the banality of wild parties. My memories of the conversations are all kind of like this:

Tyler (the fat one with the backwards baseball cap): DUDE, turn this song up! I love weaser.

Chase (the long haired blond white boy with the guitar): DUDE, weaser sucks. Its all corporate and overplayed.

Sky (she's ditsy yet pretentious!): You guys are STEWPID!

Tyler: Yeah, well you are a dumb bitch!

Sky: (rolls her eyes, and leaves).

Tyler: Dude, she's totally hot.

Chase: (starts playing his whiteboy blues -- and oh god -- starts to sing...)

I think its an exaggeration to say i'm nostalgic. Still, I wouldn't got as far to call anything that involves fixing bugs a party.

Good article! I am teaching a

Good article! I am teaching a girl one-on-one right now. She has a basic understanding of HTML and CSS and is a good designer so it's not entirely right from the start, but there is a definite learning curve to Drupal!

We are going through building a simple site from start to finish. Each lesson I give her some "homework" to play with at home and we also repeat a lot of information from the previous lesson in the next lesson. I have no time constraints and Im teaching her for free (she's an intern at our company) so I have plenty of time to go over things more than once.

I have it set up so that we are each setting up a drupal site... I direct her, but she is building her own. After I go over something once, I let her try to repeat the process and help her along if she needs it.

I find it quite rewarding.

I find it quite rewarding. The fellows who taught me did so under the condition that I would teach others (once I knew what the hell I was doing). I like that tradition. Its gives the drupal army of world domination more fresh brains to flay in the drupal hooks, altered, then sent to the preprocessors for theming.

Who's hungry?

Good topic. But you don't

Good topic. But you don't always have the option of a one-on-one session.

I'll be giving a small presentation (audience size = 20-30 on average) on injection attacks. Maybe you could give me some tips or point out some mistakes I'm setting myself up for.

My target audience is the developers in a D.U.G. If there is time I'll cover some topics aimed at the administrators.

My outline is:

1) A small demo of leveraging admin mistakes into logging on without a password.

2) The basics of XSS and SQL injections.

3) A list of code from fixed problems in live modules (ubercart) and core modules for examples of what not and what to do.

4) A run through of functions to sanitize input; check_plain(), check_markup(), filter_xss(), etc.

Well, D.U.G.s are special in

Well, D.U.G.s are special in that everyone there is generally as freakishly nerdy as you and me. I've given 5 or so big talks (back when I knew much less, ironically) and learned only that I said "uh" way too much (listening to recording), and that the audience always has a lot of questions, so you can always fall back on QA -- BUT: there's nothing like watching 90 eyebrows turn down in confusion (AT THE SAME TIME) to make one feel like they need to improve their skills...

Kathy Sierra -- the blogger who's articles more or less taught me to teach suggest this as a defensive messure:
http://www.flickr.com/photos/53359511@N00/416823679

Its really true, a face or two, a funny image, anything to get a reaction from the audience makes ALL the difference.
**
But beyond that, XSS is an import subject. I feel one of the biggest blockers to teaching safety is trying to teach TOO much. No need to go into details about XSS attack: how to avoid it seems to be all thats relevant.

Maybe make it a game. Show a piece of code and let the audience compete for who can say "see it" first (man, that may be the worst party game anyone has ever thought of... still better than monologues.)

In any case, keep your audience involved, otherwise they won't pay attention. YOu have the advantage of "fear" being the reason people are bothering to listen to you. No reason not take advantage of that, though I probably wouldn't go 24-news-network "we're going to all die" intensity.

With subjects like that, I think perhaps WInston Churchill's advice is best:
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time-a tremendous whack.

Nick, thanks for the

Nick, thanks for the encouragement and the link. I'm not at Kathy's level yet, but I hope to be in a year or two. BTW: taping your presentation so you could criticize it later and not dismissing little things like ahs/ums were both smart moves on your part.

Attend a local ToastMasters meeting (http://www.toastmasters.org/websiteApps/). They are as passionate about public speaking as you and I are about coding. Actually I am both. I love the adrenalin run a podium gives you as much as I love the thrill of the hunt for good code.

As you probably already know, a big audience is easier to handle than a small one. As long as you know your stuff and have some basic communications down (eye contact, crutch word control, etc), it is easier to talk to a bunch of heads than to look at individual faces. Just be sure to find one encouraging face in the first few rows.

I was going to make the talk more human-like by starting with a cartoon (exploits of a mom, http://xkcd.com/327/), and capitalizing on the audiences fear with a hacking demo. Like you suggest, audience interaction would be covered by making the list of live code a before/after guessing game and I only give enough XSS info to get people's attention. Just in case my timing is off I've identified details I can sacrifice, organized it in a pyramid like a news article, and I have some material on admin policies.

Getting back to the one-on-one teachings: the hardest part to me is to not say "Gimme the effen keyboard. This is how you do it, ya n00b." Just stand back and direct the users actions. If they can't get it after 2/3 tries then take note, either you or the UI is lacking!

No big deal, but in your RSS

No big deal, but in your RSS feed there's a "read more" link that's present even when the whole article was presented in my reader. I *thought* the article was finished, but clicked just in case there was more ...

Anyway, thought you'd like to know; little things like that bug me when I find them on my site.

Its a bug that I don't really

Its a bug that I don't really mind since usually the comments on my articles almost always contain better info than the actual article.

So how would you teach a

So how would you teach a class of say 15 people how to add content for instance?
-without a projector
-but not doing it person by person

First some light conceptual stuff (how does Drupal work, some Drupal jargon) then tasks?

I'm asking because I'll be teaching in the summer.

Thanks!

Really, I'd like to know more

Really, I'd like to know more though:
1. What age group?
2. Why are they there?
3. How much time do you have a day?
4. How many days do you have?

Sounds fun! Here's some ideas

Sounds fun! Here's some ideas that may be worth thinkingn about it:

If the whole's day's agenda was "how to create content" (assuming they'll have a computer) I would build basic instructions into a drupal site that everyone in the class is using, and then more or less let them go wild. If they are young, it might be fun to let them just joke around with content types and a wysiwyg building whatever strange things may amuse their young minds. Somehow I have this image of them having a content war over who can find the funniest picture that the school filters will let them get.

Regardless, if they are all working on the same drupal site, it seems like it would be fun to give them a way to talk to the entire class, in a block in a sidebar or something. Make their time social time -- people tend to learn just about anything if it means they can crack a joke in class through it.

In general, I'd see my big priorities as
1) offering good examples of what you can do with a concept,
2) keeping them from feeling overwhelmed... don't be afraid to introduce the term "node" in air quotes that mock it. It puts people at ease, and opens things up with some good old fashioned empathy.
3) giving 1-1 help to those who have trouble.
4) giving 1-1 tips to those that are ahead of everyone else. And beyond that its play time ( and they'll probably leave with a solid understanding of how to add content ).

See, its ideas like that probably keep me from being allowed to teach large groups.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • You may post code using <code>...</code> (generic) or <?php ... ?> (highlighted PHP) tags.
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.