How Do You Teach Drupal Without Inducing Confusion/Boredom Triggered Comas? Here's a rule that has never let me down:
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:
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.
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.
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
this is obviously a really
this is obviously a really old posting but I am a 12/13 year old who is a self taught drupal addict...my two cents are that to teach drupal, you should first teach how it works (data stored in mysql db, retrieved from db and put into a page template, etc...). Before i understood how drupal or any other db-based software worked, installation and setup was often a confusing process.
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
I'm only 26, but yeah -- my
However, I can't help but remember the banality of wild parties. My memories of the conversations are all kind of like this:
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.