OpenSourcery

The session I was most excited to see at this conference happened to be on the very first day, "Training: Boosting our raw capacity to provide Drupal training". It turns out, as OpenSourcery Training and Quality Assurance, I was drawn to pow wow with the presenters after we ran over time.

Barry Madore, Sean Effel, Lee Hunter, and Alex Urevick-Ackelsberg each gave a short talk, followed by panel Q&A, around the different styles of training they employ and their varied methods for improving the trainings through feedback. The training perspectives varied from speakers dealing with training drupal users every single day, to training a drupal development and sales team in how to work well with the drupal community. I will focus more here on the end-user.

One of the more potentially obvious take-aways from the talk was something I've seen folks miss the mark on: know your audience. When we start building tools to be used to understand the product the end-user has, we can lose sight of the user's goals. What is most important to the user of the software is nearly never the shiny piece of code, or a loving explanation of why it is fantastic. The exact function of the code or application may also be missing the mark of what a user really wants to know. They want to know how to use the system everyday. Your users really don't want to know how they can hack the code, but how they can interface with it without fear.

That which we are thinking about as software devs has already been invented and re-invented by teachers. The art is assessing knowledge, and then creating education and curriculum from that assessment. What we need is practice as educators, and the same education principles apply to drupal as apply to any other classroom. How much do they know? What else do they need to know? What might need to be un-learned? Are there different learners in the same group? Those questions get you close to having an assessment on which to found your curriculum.

Again, looking to the educators on curriculum, we should start by covering the concepts in the best logical order. That might not be in numerical sequence, but probably by associated concepts. One of the best parts of creating a plan like this is the exposition of concepts. This can increase confidence in knowing the right answer before a user would need to push a button. The last piece is, of course, cementing the lesson. Repetition is excellent to get you used to a new pattern of thought. Having 2 shorter trainings with time between is more effective than having a single day long training.

My hope is to bring fearlessness to software users through education. With the right tools, the hardest problems look easy. What is the worst we could do, break it? That'd be sweet!