Model Course Notes

Notes from Web Conference 3

Agenda:

1. Good problems follow-up
2. Problem authoring discussion
3. NPL
4. Model Courses

Good Problems

• The heuristics that we discussed last time shape fairly easily into a "rubric" that may or may not be useful to think about when writing problems and thinking about what existing problems might have or lack.
  • Learning objective -- could be very simple; it may also be that this should also be available to students
  • "Nice enough" numbers -- distinct values allow tracking of student work
  • Test suite? Can we check for nice numbers? For robustness?
  • Students and nice numbers: is there information about how students react to problems, to figure out what problems are effective and which turn students off?

• Metadata for problems: could be part of a new NPL, and could include
  • Learning objectives (possibly available to students, in some cases this might not be a good thing)
  • Quality measures
  • Information on problems that have substantial added information, hints, or instruction. These might be problems that should be embedded in a set.
  • A measure of the difficulty of the problem---maybe the number or percent of incorrect submissions seen on the problem
  • A measure of the number of uses of the problem

• We may need a better mapping of problems to course sections---e.g., a better generic course/chapter/section list

Good NPL Problems

• Are solutions good for students? Are there data that substantiate the value of solutions to student learning?
• The solution -> new problem model. This may be very useful in some cases, though not necessarily all.

Library Browser

• Note that searching on problems is dependent on the tagging, and that the displayed directory structure may not reflect the actual database chapter/section/problem numbers (this may be a fault in the organization of the files in the NPL)
• Finding problems that are similar to a given model problem, or that have characteristics that we want. The keyword search might be a good option for this

Model Courses

• One aspect of developing model courses is that of translating problems from textbook problems to problems that are parameterized, algorithmic WeBWorK problems
  • This translation allows us to do more with the problems---e.g., allow negative parameters, or change the problems to challenge students
  • Testing problems becomes an issue: ensuring that the problems are consistent and have no singularities
  • Making the format and numbers that show up in the problems "nice" can be a significant time drain

• There are some model courses currently available: calculus I
  • For the calculus I model course, the problems are set up so that the problem paths are visible, and the source for the problems is visible

• Things that we might want in a model course:
  • Sample problem sets
  • Textbook notes
  • Assumptions about how the problems are picked and assigned
  • Assignment information and related data that are provided to students when using the problems
  • That it be a course that actually has been used (and tested)

• How are these stored?
  • A courses repository? This could include metadata, including textbook information, philosophy, etc.
  • The moodle course model is a good one: it allows viewing of a lot of metadata about the course and the sets that are given
  • Problem sets can be stored in an archive file that can be downloaded and installed in a course. Is there a better way than a tgz file?