China WBI

EDITED (1/2/2008): I have some new dates and changes to the timeline due to new information from my advisor and the program director.

My advisor has asked me to come up with a workable timeline for spring semester, as my stated goal is to finish up this project by then so I can finally graduate.

My aim is to have the project complete by May 1, 2008 — but I will need to accelerate the coding a little, as I need to do a write-up of my thoughts and lessons learned through this project. I also hope to try out my system with a few test users.

Here is a rough timeline month-by-month:

January

• Coding: Drilling module with arithmetic unit, and start riverboat
• Writing: Write on issues encountered thus far — communication between practitioner and designer, difficulty of codifying classroom management policy through a generic administrative interface
• EDITED Writing: start writing project summary
• Other: Find out necessary tasks for graduation filing

February

• Coding: Finish riverboat, assessment policy
• Writing: Write on issues encountered thus far — difficulty in expressing the problem domain generically; the economics of creating a usable, appealing, customized site.
• EDITED Writing: finish writing project summary

March

• Coding: Records and student/study group status, begin UI revamp
• Writing: reflections on the project as a whole
• EDITED Writing: : conclusions and recommendations

April

• EDITED Draft finished by April 1st
• Coding: Complete UI Revamp
• Writing: Trial w/real users and feedback; paper revisions

I think this was probably the first release that I came pretty close on my estimate — I’d say within 5%. I didn’t keep track down to the minute, but for the first time I felt pretty comfortable with what I needed to do. I think this means I’ve been relatively successful now in refining my estimates.

That being said, as more and more gets added to this website, I’m realizing that things are actually quite complex… not only from a programming perspective, but more importantly from the user interface perspective. I’m realizing how important it is to really nail down exactly how the interface is supposed to flow from one page to another, especially for web applications.

Unfortunately, it’s out of scope to do an entire revamp of the UI workflow. I’m going to try to make minute adjustments in future iterations to at least make things a bit palatable… and it’ll also help to reduce the scope of some of the planned features. It’s better to have things simpler but intuitive, than “full-featured” but confusing.

This is the last iteration before the end of this semester, and I’m hoping to finally finish this project in the spring. There’s quite a bit more left to do, so hopefully we can start picking up the pace in January!

As mentioned in the last post, there were several opportunities for code reuse from the previous stories, that I could leverage for later. What I had planned for 2 separate stories ended up taking up about 1 1/2 stories in terms of how long I guesstimated. Consequently, I’m just combining the last two stories into one post. It’s about time that I finished a story ahead of schedule!

These two stories involved the admin view, being able to see the individual student and study group mastery status(es). I indicated this early in the iteration, but because we don’t have any DB structure for student records on any of the lessons, I am just making up figures. However, the mastery level for students should correspond to their performance on the drill/test, and the percentage shown for the study group mastery level, should be the percentage of study group members who have achieved mastery by the allotted deadline.

The view of the mastery status of student and study group is combined into one lesson view page, but to fit on this display, I’m cropping each relevant section:

1st, the view of the class enrollment’s mastery status:

And the study group’s mastery percentage:

This story involved quite a bit of legwork, but after it was all said and done, there was a significant amount of reusable code that I will be able to make use of in the next few stories, so it was a good investment of time.

There’s not much to say in regards to this story except that right now, it’s a little messy with studyGroup, course, user, and lesson IDs floating around. I think if I were to start all over again, I would aim for a simpler DB structure, but then again, I’m not sure that a real-life implementation would be able to make do with a simplification.

Anyhow, I was able to implement a link from the view class page, which is the display of the percentage of study group members who have achieved mastery; this links to a new page showing the individual mastery status of each study group member.

This story involves displaying all the lessons for a student for a particular class, and showing that student’s mastery status. This is basically just a percentage which represents the level of the student according to the drilling/testing he or she has been performing.

Actually I probably should have designed the DB and data structures for the student records, as I don’t have any existing information in the DB on how well a student is doing. For now, though, I’ll stick with my original plan, and I just am using a temporary dummy value for the student mastery level. However, this is something that would be determined differently, once the student records structures are finished.

Here is the display of the new lessons table in the student view, along with a placeholder for the study group mastery status.