Designing a good course is as hard as designing good software. To help you, this document describes a process based on evidence-based teaching practices:
@owaistiwana456.com
Introduction
Designing a good course is as hard as designing good software. To help you, this document describes a process based on evidence-based teaching practices:
It lays out a step-by-step progression to help you figure out what to think about in what order.
It provides spaced check-in points so you and your Curriculum Lead (CL) can re-scope or redirect effort.
The end product specifies deliverables clearly so you can finish development without major surprises.
Everything from Step 2 onward goes into your final course, so there is no wasted effort.
Getting you to write sample exercises early lets DataCamp check that we can support everything you want your students to do.
We use the design of our introduction to the Unix shell for data scientists as a running example.
Note: 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 answer to a later question or realize that your initial plan isn't going to play out the way you first thought.
Please copy this template to README.md in the root directory of your course repository and fill it in to design your own course.
Terminology and Structure
A course is a self-contained module with its own top-level entry in our catalog, its own GitHub repository, etc.
A chapter is a major section of a course.
Chapters are made up of lessons, each of which has a short video and a handful of exercises.
A course typically has about the same amount of content as a half-day conference workshop, and contains 44-60 exercises (including videos) and 4-5 chapters. A typical breakdown is:
Chapter 1: 8-12 exercises
Chapter 2: 10-16 exercises
Chapter 3: 10-16 exercises
Chapter 4: 10-16 exercises
Chapter 5 (optional): 10-16 exercises
Step 1: Brainstorming
The first step is to throw together some rough ideas so that you and your CL can make sure your thoughts about the course are aligned. To do this, write some point-form answers to three or four of the questions listed below. You aren't expected to answer all of them, and you may pose and answer others if you and your CL think it's helpful, but you should always include a couple of answers to the first.
What problem(s) will student learn how to solve? E.g., "how to draw plots using ggplot2" or "how to forecast product demand".
What concepts and techniques will students learn? E.g., "the split-train-model-predict workflow" or "rolling back Git commits".
What technologies, packages, or functions will students use? E.g., "ggplot2 for drawing plots".
What terms or jargon will you define? E.g., "boosting versus bagging" or "block/factor/sequential designs".
What analogies will you use to explain concepts? E.g., "ggplots are like Lego for graphics". (See Gelman & Nolan for more ideas here.)
What heuristics will help students understand things? E.g., "draw a simple plot then add elements one by one" or "don't use Holt-Winters if your demand spikes on holidays".
What mistakes or misconceptions do you expect? E.g., "changing colors works differently if the color argument is inside an aesthetic or not" or "overfitting models to the data".
What datasets will you use? E.g., "anything but the diamonds and mtcars datasets" or "something from the UCI Archive".
You may not need to answer every question for every course, and you will often have questions or issues we haven't suggested, but couple of hours of thinking at this stage can save days of rework later on.
Checkin: a rough scope for the course that you have agreed with your CL.
Running Example
The questions and answers for the Unix shell course are:
What problem(s) will student learn how to solve? How to combine existing/legacy tools; how to make analyses reproducible.
What techniques or concepts will students learn? History; pipes; shell scripts.
What technologies, packages, or functions will students use? Bash shell; basic Unix commands (cd, ls); basic data manipulation commands (head, cut, grep).
What terms or jargon will you define? Filesystem; redirection; pipe; wildcard.
What analogies will you use to explain concepts? Command-line pipeline is like chemistry pipeline; shell scripts are like snippets of command history.
What heuristics will help students understand things? Use filenames that are easy to match with tab completion and wildcards; build pipelines step by step.
What mistakes or misconceptions do you expect? That the shell shows the same files and folders as the GUI interface they're used to; definition vs. use of variables (especially loop variables).
What datasets will you use? dental records.
Step 2: Who Is This Course For?
"Beginner" and "expert" mean different things to different people, and many factors besides pre-existing knowledge influence who a course is suitable for. The second step in designing a course is therefore to agree on an audience with your CL. To help you do this, we have created learner personas for typical DataCamp students. Each persona describes the person's general background, what they already know, and what they think they want to do.
After you are done brainstorming, you should go through these personas and decide which of them your course is intended for, and how it will help them. While doing this, you should make some notes about what specific prerequisite skills or knowledge you expect students to have above and beyond what's in the persona. If none of our personas capture your intended audience, talk to your CL to make sure you agree on who you're aiming for.
Checkin: brief summaries of who your course will help and how.
Note: Please do not copy the profiles into your course design, since we will update them as we gather more data on our learners. Instead, link to them and comment on how the course relates to them.
Running Example
Alex knows how to do a few things with the Terminal application on his Mac, but now wants to learn how to use the shell to access his company's cloud computing resources. This course will serve as a quick refresher before he goes on to a more advanced course.
Sindhu has never used a command-line shell. This course will give her a basic understanding of Unix so that she can use the command-line tools her colleagues have built.
Chen doesn't need this course, since she has been using Unix for more than twenty years.
Step 3: What Will Learners Do Along the Way?
The best way to make the goals in Step 1 firmer is to write full descriptions of a couple of exercises that students will be able to do toward the end of the course. Writing exercises early is directly analogous to test-driven development: rather than working forward from a (probably ambiguous) set of learning objectives, designers work backward from concrete examples of where their students are going. Doing this also helps uncover technical requirements that might otherwise not be found until uncomfortably late in the lesson development process.
To complement the full exercise descriptions, you should also write brief point-form descriptions of one or two exercises per chapter 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.
Checkin: 1-2 fully explained exercises that use the skills the student is to learn, plus half a dozen point-form exercise outlines.
Note: be sure to include solutions with example code so that the CL can check that our platform can do everything you need.
Running Example
Complete Exercise: Building a Tool to Find Unique Values in Columns
As the final exercise in the Unix shell course, you are given several dozen data files, each of which is formatted like this:
Owaistiwana
commented
6 years ago
@owaistiwana456.com Introduction Designing a good course is as hard as designing good software. To help you, this document describes a process based on evidence-based teaching practices:
It lays out a step-by-step progression to help you figure out what to think about in what order. It provides spaced check-in points so you and your Curriculum Lead (CL) can re-scope or redirect effort. The end product specifies deliverables clearly so you can finish development without major surprises. Everything from Step 2 onward goes into your final course, so there is no wasted effort. Getting you to write sample exercises early lets DataCamp check that we can support everything you want your students to do. We use the design of our introduction to the Unix shell for data scientists as a running example.
Note: 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 answer to a later question or realize that your initial plan isn't going to play out the way you first thought.
Please copy this template to README.md in the root directory of your course repository and fill it in to design your own course.
Terminology and Structure A course is a self-contained module with its own top-level entry in our catalog, its own GitHub repository, etc. A chapter is a major section of a course. Chapters are made up of lessons, each of which has a short video and a handful of exercises. A course typically has about the same amount of content as a half-day conference workshop, and contains 44-60 exercises (including videos) and 4-5 chapters. A typical breakdown is:
Chapter 1: 8-12 exercises Chapter 2: 10-16 exercises Chapter 3: 10-16 exercises Chapter 4: 10-16 exercises Chapter 5 (optional): 10-16 exercises Step 1: Brainstorming The first step is to throw together some rough ideas so that you and your CL can make sure your thoughts about the course are aligned. To do this, write some point-form answers to three or four of the questions listed below. You aren't expected to answer all of them, and you may pose and answer others if you and your CL think it's helpful, but you should always include a couple of answers to the first.
What problem(s) will student learn how to solve? E.g., "how to draw plots using ggplot2" or "how to forecast product demand".
What concepts and techniques will students learn? E.g., "the split-train-model-predict workflow" or "rolling back Git commits".
What technologies, packages, or functions will students use? E.g., "ggplot2 for drawing plots".
What terms or jargon will you define? E.g., "boosting versus bagging" or "block/factor/sequential designs".
What analogies will you use to explain concepts? E.g., "ggplots are like Lego for graphics". (See Gelman & Nolan for more ideas here.)
What heuristics will help students understand things? E.g., "draw a simple plot then add elements one by one" or "don't use Holt-Winters if your demand spikes on holidays".
What mistakes or misconceptions do you expect? E.g., "changing colors works differently if the color argument is inside an aesthetic or not" or "overfitting models to the data".
What datasets will you use? E.g., "anything but the diamonds and mtcars datasets" or "something from the UCI Archive".
You may not need to answer every question for every course, and you will often have questions or issues we haven't suggested, but couple of hours of thinking at this stage can save days of rework later on.
Checkin: a rough scope for the course that you have agreed with your CL.
Running Example The questions and answers for the Unix shell course are:
What problem(s) will student learn how to solve? How to combine existing/legacy tools; how to make analyses reproducible. What techniques or concepts will students learn? History; pipes; shell scripts. What technologies, packages, or functions will students use? Bash shell; basic Unix commands (cd, ls); basic data manipulation commands (head, cut, grep). What terms or jargon will you define? Filesystem; redirection; pipe; wildcard. What analogies will you use to explain concepts? Command-line pipeline is like chemistry pipeline; shell scripts are like snippets of command history. What heuristics will help students understand things? Use filenames that are easy to match with tab completion and wildcards; build pipelines step by step. What mistakes or misconceptions do you expect? That the shell shows the same files and folders as the GUI interface they're used to; definition vs. use of variables (especially loop variables). What datasets will you use? dental records. Step 2: Who Is This Course For? "Beginner" and "expert" mean different things to different people, and many factors besides pre-existing knowledge influence who a course is suitable for. The second step in designing a course is therefore to agree on an audience with your CL. To help you do this, we have created learner personas for typical DataCamp students. Each persona describes the person's general background, what they already know, and what they think they want to do.
After you are done brainstorming, you should go through these personas and decide which of them your course is intended for, and how it will help them. While doing this, you should make some notes about what specific prerequisite skills or knowledge you expect students to have above and beyond what's in the persona. If none of our personas capture your intended audience, talk to your CL to make sure you agree on who you're aiming for.
Checkin: brief summaries of who your course will help and how.
Note: Please do not copy the profiles into your course design, since we will update them as we gather more data on our learners. Instead, link to them and comment on how the course relates to them.
Running Example Alex knows how to do a few things with the Terminal application on his Mac, but now wants to learn how to use the shell to access his company's cloud computing resources. This course will serve as a quick refresher before he goes on to a more advanced course.
Sindhu has never used a command-line shell. This course will give her a basic understanding of Unix so that she can use the command-line tools her colleagues have built.
Chen doesn't need this course, since she has been using Unix for more than twenty years.
Step 3: What Will Learners Do Along the Way? The best way to make the goals in Step 1 firmer is to write full descriptions of a couple of exercises that students will be able to do toward the end of the course. Writing exercises early is directly analogous to test-driven development: rather than working forward from a (probably ambiguous) set of learning objectives, designers work backward from concrete examples of where their students are going. Doing this also helps uncover technical requirements that might otherwise not be found until uncomfortably late in the lesson development process.
To complement the full exercise descriptions, you should also write brief point-form descriptions of one or two exercises per chapter 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.
Checkin: 1-2 fully explained exercises that use the skills the student is to learn, plus half a dozen point-form exercise outlines.
Note: be sure to include solutions with example code so that the CL can check that our platform can do everything you need.
Running Example Complete Exercise: Building a Tool to Find Unique Values in Columns
As the final exercise in the Unix shell course, you are given several dozen data files, each of which is formatted like this: