checklists.tex

\chaplbl{Checklists and Templates}{s:checklist}

\cite{Gawa2007} popularized the idea that using checklists can save lives,
and more recent studies have generally supported their effectiveness~\cite{Avel2013,Urba2014,Rams2019}.
We find them useful,
particularly when bringing new teachers onto a team;
the ones given below can be used as starting points for developing your own.

\seclbl{Teaching Evaluation}{s:checklists-teacheval}

This rubric is designed to assess people teaching for 5--10 minutes
with slides, live coding, or a mix of both.
Rate each item as ``Yes'', ``Iffy'', ``No'', or ``Not Applicable''.

\noindent
\begin{longtable}{p{.25\textwidth}p{.75\textwidth}}

  Opening
  & Exists (use N/A for other responses if not) \\
  & Good length (10--30 seconds) \\
  & Introduces self \\
  & Introduces topics to be covered \\
  & Describes prerequisites \\
  \\ [-1.5ex] \hline \\ [-1.5ex]

  Content
  & Clear goal/narrative arc \\
  & Inclusive language \\
  & Authentic tasks/examples \\
  & Teaches best practices/uses idiomatic code \\
  & Steers a path between the Scylla of jargon and the Charybdis of over-simplification \\
  \\ [-1.5ex] \hline \\ [-1.5ex]

  Delivery
  & Clear, intelligible voice (use ``Iffy'' or ``No'' for strong accent) \\
  & Rhythm: not too fast or too slow, no long pauses or self-interruption, not obviously reading from a script \\
  & Self-assured: does not stray into the icky tarpit of uncertainty or the dungheap of condescension \\
  \\ [-1.5ex] \hline \\ [-1.5ex]

  Slides
  & Exist (use N/A for other responses if not) \\
  & Slides and speech complement one another (dual coding) \\
  & Readable fonts and colors/no overwhelming slabs of text \\
  & Frequent change on screen (something every 30 seconds) \\
  & Good use of graphics \\
  \\ [-1.5ex] \hline \\ [-1.5ex]

  Live Coding
  & Used (use N/A for other responses if not) \\
  & Code and speech complement one another \\
  & Readable fonts and colors/right amount of code on the screen \\
  & Proficient use of tools \\
  & Highlights key features of code \\
  & Dissects errors \\
  \\ [-1.5ex] \hline \\ [-1.5ex]

  Closing
  & Exists (use N/A for other responses if it doesn't) \\
  & Good length (10--30 seconds) \\
  & Summarizes key points \\
  & Outlines next steps \\
  \\ [-1.5ex] \hline \\ [-1.5ex]

  Overall
  & Points clearly connected/logical flow \\
  & Make the topic interesting (i.e., not boring) \\
  & Knowledgeable \\

\end{longtable}

\seclbl{Teamwork Evaluation}{s:checklists-teameval}

This rubric is designed to assess individual performance within a
team. You can use it as a starting point for creating a rubric of
your own. Rate each item as ``Yes'', ``Iffy'', ``No'', or ``Not Applicable''.

\noindent
\begin{longtable}{p{.25\textwidth}p{.75\textwidth}}

  Communication
  & Listens attentively to others without interrupting \\
  & Clarifies with others have said to ensure understanding \\
  & Articulates ideas clearly and concisely \\
  & Gives good reasons for ideas \\
  & Wins support from others \\
  \\ [-1.5ex] \hline \\ [-1.5ex]

  Decision Making
  & Analyzes problems from different points of view \\
  & Applies logic in solving problems \\
  & Offers solutions based on facts rather than ``gut feel'' or intuition \\
  & Solicits new ideas from others \\
  & Generates new ideas \\
  & Accepts change \\
  \\ [-1.5ex] \hline \\ [-1.5ex]

  Collaboration
  & Acknowledges issues that the team needs to confront and resolve \\
  & Works toward solutions that are acceptable to all involved \\
  & Shares credit for success with others \\
  & Encourages participation among all participants \\
  & Accepts criticism openly and non-defensively \\
  & Cooperates with others \\
  \\ [-1.5ex] \hline \\ [-1.5ex]

  Self-Management
  & Monitors progress to ensure that goals are met \\
  & Puts top priority on getting results \\
  & Defines task priorities for work sessions \\
  & Encourages others to express views even when they are contrary \\
  & Stays focused on the task during meetings \\
  & Uses meeting time efficiently \\
  & Suggests ways to proceed during work sessions \\

\end{longtable}

\seclbl{Event Setup}{s:checklists-events}

The checklists below are used before, during, and after events.

\subsection*{Scheduling the Event}

\begin{itemize}

\item
  Decide if it will be in person,
  online for one site,
  or online for several sites.

\item
  Talk through expectations with the host
  and make sure everyone agrees who is covering travel costs.

\item
  Determine who is allowed to take part:
  is the event open to all comers,
  restricted to members of one organization,
  or something in between?

\item
  Arrange teachers.

\item
  Arrange space, including breakout rooms if needed.

\item
  Choose dates.
  If it is in person, book travel.

\item
  Get names and email addresses of attendees from host.

\item
  Make sure everyone is registered.

\end{itemize}

\subsection*{Setting Up}

\begin{itemize}

\item
  Set up a web page with details on the workshop,
  including date,
  location,
  and what participants need to bring.

\item
  Check whether any attendees have special needs.

\item
  If the workshop is online, test the video conferencing---twice.

\item
  Make sure attendees will have network access.

\item
  Create a page for sharing notes and exercise solutions (e.g., a Google Doc).

\item
  Email attendees a welcome message with
  a link to the workshop page,
  background readings,
  a description of any setup they need to do,
  a list of what they need to bring,
  and a way to contact the host or teacher on the day.

\end{itemize}

\subsection*{At the Start of the Event}

\begin{itemize}

\item
  Remind everyone of the code of conduct.

\item
  Take attendance
  and create a list of names to paste into the shared page.

\item
  Distribute sticky notes.

\item
  Make sure everyone can get online.
  
\item
  Make sure everyone can access the shared page.

\item
  Collect any relevant online account IDs.

\end{itemize}

\subsection*{At the End of the Event}

\begin{itemize}

\item
  Update the attendance list.

\item
  Collect feedback from participants.

\item
  Make a copy of the shared page.

\end{itemize}

\subsection*{Travel Kit}

Here are a few things teachers take with them to workshops:

\begin{longtable}{p{0.45\textwidth}p{0.45\textwidth}}

sticky notes & cough drops \\
comfortable shoes & a small notepad \\
a spare power adapter & a spare shirt \\
deodorant & video adapters \\
laptop stickers & their notes (printed or on a tablet) \\
a granola bar or some other snack & antacid (because road food) \\
business cards & spare glasses/contacts \\
a notebook and pen & a laser pointer \\
an insulated cup for tea/coffee & extra whiteboard markers \\
a toothbrush or mouthwash & wet wipes (because spills happen) \\

\end{longtable}

When travelling,
many teachers also take running shoes, a bathing suit, a yoga mat,
or whatever else they exercise in or with.
Some also bring a portable WiFi hub in case the room's network isn't working
and some USB drives with installers for the software learners need.

\seclbl{Lesson Design}{s:checklists-design}

This section summarizes the backward design method
developed independently by~\cite{Wigg2005,Bigg2011,Fink2013}.
It lays out a step-by-step progression
to help you think about the right things in the right order
and provides spaced deliverables
so you can re-scope or redirect effort without too many unpleasant surprises.

Everything from Step 2 onward goes into your final lesson,
so there is no wasted effort;
as described in \chapref{s:process},
writing sample exercises early helps ensure that
everything you ask your learners to do contributes to the lesson's goals
and that everything they need to know is covered.

The steps are described in order of increasing detail,
but the process itself is always iterative.
You will frequently go back to revise earlier work
as you learn something from your answers to later questions
or realize that your initial plan isn't going to play out the way you first thought.

\subsection*{Who is this lesson for?}

Create some learner personas (\secref{s:process-personas})
or (preferably) choose ones that you and your colleagues have drawn up for general use.
Each persona should have:

\begin{enumerate}

\item
  the person's general background;

\item
  what they already know;

\item
  what they think they want to do; and

\item
  any special needs they have.

\end{enumerate}

~\\
\noindent
\textbf{Deliverable:} brief summaries of who you are trying to help.

\subsection*{What's the big idea?}

Write point-form answers to three or four of the questions below
to help you figure out the scope of the lesson.
You don't need to answer all of these questions,
and you may pose and answer others if you think it's helpful,
but you should always include a couple of answers to the first one.
You may also create a concept map at this stage (\secref{s:memory-concept-maps}).

\begin{itemize}

\item
  What problems will people learn how to solve?

\item
  What concepts and techniques will people learn?

\item
  What technologies, packages, or functions will people use?

\item
  What terms or jargon will you define?

\item
  What analogies will you use to explain concepts?

\item
  What mistakes or misconceptions do you expect?

\item
  What datasets will you use?

\end{itemize}

~\\
\noindent
\textbf{Deliverable:}
a rough scope for the lesson.
Share this with a colleague---a little bit of feedback at this point
can save hours of wasted effort later on.

\subsection*{What will learners do along the way?}

Make the goals in Step 2 firmer by writing full descriptions of
a couple of exercises that learners will be able to do toward the end of the lesson.
Doing this is analogous to \hreffoot{https://en.wikipedia.org/wiki/Test-driven\_development}{test-driven development}:
rather than working forward from a (probably ambiguous) set of learning objectives,
work backward from concrete examples of where you want your learners to end up.
Doing this also helps uncover technical requirements
that might otherwise not be found until uncomfortably late.

To complement the full exercise descriptions,
write brief point-form descriptions of one or two exercises per lecture hour
to show how quickly you expect learners to progress.
Again,
these serve as a good reality check on how much you're assuming
and help uncover technical requirements.
One way to create these ``extra'' exercises
is to make a point-form list of the skills needed to solve the major exercises
and create an exercise that targets each.

~\\
\noindent
\textbf{Deliverable:} 1--2 fully explained exercises
that use the skills people are to learn,
plus half a dozen point-form exercise outlines.
Include complete solutions
so that you can make sure the software you want learners to use actually works.

\subsection*{How are concepts connected?}

Put the exercises you have created in a logical order
and then derive a point-form lesson outline from them.
The outline should have 3--4 bullet points for each hour
with a formative assessment of some kind for each.
It is common to change assessments in this stage
so that they can build on each other.

~\\
\noindent
\textbf{Deliverable:} a lesson outline.
You are likely to discover things you forgot to list earlier during this stage,
so don't be surprised if you have to double back a few times.

\subsection*{Lesson overview}

You can now write a lesson overview with:

\begin{itemize}

\item
  a one-paragraph description (i.e., a sales pitch to learners);

\item
  half a dozen learning objectives; and

\item
  a summary of prerequisites.

\end{itemize}

Doing this earlier often wastes effort,
since material is usually added, cut, or moved around in earlier steps.

~\\
\noindent
\textbf{Deliverable:}
course description,
learning objectives,
and prerequisites.

\seclbl{Pre-Assessment Questionnaire}{s:checklists-preassess}

This questionnaire helps teachers gauge the prior programming knowledge
of participants in an introductory JavaScript workshop.
The questions and answers are concrete,
and the whole thing is short so that respondents won't find it intimidating.

\begin{enumerate}

\item
  Which of these best describes
  your experience with programming in general?

  \begin{itemize}
    
  \item
    I have none.
    
  \item
    I have written a few lines now and again.
    
  \item
    I have written programs for my own use that are a couple of
    pages long.
    
  \item
    I have written and maintained larger pieces of software.\\
    
  \end{itemize}

\item
  Which of these best describes
  your experience with programming in JavaScript?

  \begin{itemize}
    
  \item
    I have none.
    
  \item
    I have written a few lines now and again.
    
  \item
    I have written programs for my own use that are a couple of
    pages long.
    
  \item
    I have written and maintained larger pieces of software.\\
    
  \end{itemize}

\item
  Which of these best describes how easily you could write a program
  in any language
  to find the largest number in a list?

  \begin{itemize}
    
  \item
    I wouldn't know where to start.
    
  \item
    I could struggle through by trial and error with a lot of web
    searches.
    
  \item
    I could do it quickly with little or no use of external help.\\
    
  \end{itemize}

\item
  Which of these best describes
  how easily you could write a JavaScript program
  to find and capitalize all of the titles in a web page?

  \begin{itemize}
    
  \item
    I wouldn't know where to start.
    
  \item
    I could struggle through by trial and error with a lot of web
    searches.
    
  \item
    I could do it quickly with little or no use of external help.\\
    
  \end{itemize}

\item
  What do you want to know or be able to do after this class
  that you don't know or can't do right now?

\end{enumerate}