November 2007


This story went much faster than expected, so I let a little feature creep occur and expanded the implementation. The original story had me creating a new field in the Lessons DB table, which marked a lesson as deleted. I don’t want to actually delete the lesson record, just mark it as delete, so after adding the new field, all I had to do was retrieve only the non-deleted lessons and update that field when a lesson was deleted.

deletelesson

This would have been fine, except I wondered whether it would be useful, then, to support undeleting a lesson, which is presumably what marking a record as deleted is for in many cases. So, I set out to make a new page called Deleted Lessons, which shows all the deleted lessons for a particular class. From here, the user can click on the Undelete button to restore the previously deleted lesson.

undeletelesson

This story demonstrated the dangers of feature creep, however, as the story took about 3 times as long as what it took to just implement the original story… but oh well.

I enjoyed this release, as there were no major surprises. Things still took a little longer than expected, but I attribute most of that to the rust after coming back from vacation, and also for not properly scoping the large amount of database fields that were involved for lesson administration.

Since I have another release of stories to go for the lesson model, I’ll be more cognizant of this issue. The remaining stories, which will comprise Release 0.1.9, are:

  • Allow teachers to delete lessons from classes. This should not delete the lesson record from the DB, but only mark it as deleted.
  • Allow students to see all the lessons when they view a class, and their mastery status on it.
  • Allow students to see their study group’s mastery status on the lessons for a particular class.
  • Allow teachers to see their students’ mastery status for a particular lesson.
  • Allow teachers to see study groups’ mastery status for a particular lesson.

I don’t have to touch all the new fields for these stories, so I think they should be doable for the last release.

Release 0.1.9 will be the last release for this semester. I had hoped to start getting into the actual curriculum model, but I will have to save that for next semester (or maybe even during vacation, but I wouldn’t bet on it). I plan to have 0.1.9 finished and also my new literature review done by the end of this semester.

This is the last story for this iteration. It wasn’t too bad, but again, the sheer number of fields made this take a bit long, but it was mostly busy work.

At the end, just for good measure, I added a Cancel button, which was surprisingly hard to implement… it lied in the fact that I only wanted to pass the LessonID in the URL and not the courseID, since lesson IDs are supposed to be unique… however, the Cancel button needed to direct back to the course page, which required a courseID, so I ended up having to make a database call to retrieve the appropriate courseID. Not the most efficient solution but it sufficed. If I did it again, I’d probably just store the courseID on the URL or I’d write it out into a hidden field.

Here is the edit lesson form, which is very similar to the add lesson form:

editlesson

This story was similar to previous stories on creating study groups and courses, only this time the scope was much larger because there were many more fields that belonged to a lesson. So although things went a lot faster than figuring things out for the first time, there was a lot of busy work to get things up and running.

I made some design compromises, knowing that I am only trying to build the admin section to have the minimal functionality. For example, it would have been nice to have a Javascript Date calendar selector to choose the dates, but a simple text box does just fine. I could spend extra time to do all the validation to ensure properly formatted values, but life is short and that’s beyond the scope of this project.

Here’s the create lesson form. Many values are populated by default to avoid guesswork by the user:

addlesson

This ended up being a fairly substantial story, mainly because there wasn’t any lesson-related code set up in the project yet, and because it required a new service class to implement from scratch. It wasn’t too bad as it is the same kind of thing required for the course and study group services, but it did add time to what I thought it would take.

One new thing here was dealing with DateTime objects and SQL datetime types. I wanted to know how to convert between the types, and did a quick Google search, using the 1st result as a way to do the code. This was a bad idea, and I learned to be a little more thorough in my code research…luckily it didn’t even compile, because I couldn’t introduced a more subtle error. Instead, all that was required was a cast, which makes sense as if Microsoft owns both SQL Server and ASP, they shouldn’t require some jumble of bloated code to communicate with each other. At least one would think.

Anyhow, I got it working, and below is the admin view of the lessons for a particular class. The edit button doesn’t do anything, as that is just a placeholder for a later story.

viewlessons

This story was relatively straightforward — just a little rusty after not programming ASP for awhile. I tell you, it’s just not very intuitive, and I always have to go back and think, is that really how it’s supposed to work? Fortunately, I’ve built up a lot of code at this point that I can go back to for reference. I didn’t do anything patently new in this story, so I was able to figure it out eventually.

As shown below, I’ve create a temporary study group called “sg to delete”, and assigned 2 students to it.

delete SG

After deleting the group, the entry disappears, and the students are automatically moved to the Unassigned group.

delete sg after

I’m now back from my honeymoon, and still a little unaccustomed to my new status as a married man. Anyhow, now it’s time to get back to work on this project, and specifically, release 0.1.8.

This release involves one leftover story from the previous release, as well as stories dealing with the curriculum data model. If you remember, we had an extra iteration to complete the student/class model, so the curriculum data model was pushed into the post-honeymoon schedule.

What does the curriculum model entail? A curriculum must correspond to a course (one-to-one), and each curriculum can have multiple lessons. A lesson, under Bloom’s mastery learning model, consists of two phases. In the first phase, students attempt to achieve mastery by demonstrating competence for a particular learning area. If they succeed, they use the 2nd phase to attempt to build on their learning, while students who do not achieve mastery in the first phase have a second chance to do so. As discussed earlier, in our particular model, in the 2nd phase, students will achieve more complex learning by becoming tutors for their fellow students in their study group who did not achieve mastery.

So what does the web-based tool need to do?

  1. Allow teachers to create lessons, with start and end dates for the 2 phases.
  2. Allow/disallow students to drill/test a particular lesson, based on the current date and the dates for the phases
  3. Determine which students have achieved mastery for a particular phase, based on the threshold for mastery for that lesson, and the student’s score
  4. Allow students to see their mastery status in relation to the class’s lessons, as well as the mastery status of their study group members

Let’s see how this breaks down into stories (including the last iteration’s leftover story):

  • Delete an existing study group. Students in that study group should automatically be moved to the Unassigned study group. The Unassigned study group should not be deleted.
  • Create the DB for lessons. A lesson has a name, a corresponding instructional module, a start and end date, a Phase 1 end/Phase 2 start date, and a threshold for achieving mastery. Add some test data.
  • Allow all lesson information to be viewed for a class in chronological order (based on lesson start date).
  • Allow teachers to add lessons to classes.
  • Allow teachers to edit lesson information.
  • Allow teachers to delete lessons from classes. This should not delete the lesson record from the DB, but only mark it as deleted.
  • Allow students to see all the lessons when they view a class, and their mastery status on it.
  • Allow students to see their study group’s mastery status on the lessons for a particular class.
  • Allow teachers to see their students’ mastery status for a particular lesson.
  • Allow teachers to see study groups’ mastery status for a particular lesson.

This is quite a bit of development that needs to be done, and is looking like it will take two iterations to complete. We will start with the first 5 stories as iteration 0.1.8, and add or remove stories as necessary from this iteration.