Well, this does it for the project… at least, the programming part. I should celebrate, but I have to get a paper draft in as soon as possible, so I’m going to jump into the rest of that.

This release was very difficult in the beginning. As I feared, ASP does not provide the greatest support for CSS. There is something there, that once I got used to, was usable enough. But I was very frustrated with the way ASP got in the way

My main peeve is that ASP tries to build an HTML presentation model on top of HTML through its custom tags. The reason this is so irritating, is that it is an abstraction on top of HTML and CSS, which is more complicated than the underlying technology. There are hundreds of asp custom tags, and while their attributes may be similar in many cases, there are enough exceptions that require someone using it for the first time to look up what tag supports what each time.

I shouldn’t have to look it up in the first place. Ideally, I want to specify a CSS class or id on any given tag. This works reasonably well for individual tags, but I also want to specify rules for embedded tags as well, and this is where ASP breaks down. Because the ASP implementation of its custom tag is an abstraction, I don’t know what type of HTML tag it is ultimately using to implement the style. Of course, I could find out, but what’s to say that the implementation will change in the next version of ASP? It’s dangerous to depend on such implementation details for maintenance purposes.

I will concede that the ASP designers really did not have much choice. Once the decision was made to create the whole WebForms abstraction and to encourage non-use of standard HTML tags, the CSS model breaks down, because it is strongly coupled to HTML. Without knowing too much about the ramifications, I’d like to put out the idea that perhaps it would’ve been better to try and extend the attributes of standard, existing HTML tags for as much of the base functionality of ASP as possible. But alas, from what I hear, one of the primary motivators of the ASP form design was to mimic WinForms terminology and behavior. While this might have increased the chance of ASP adoption by developers who were already versed in Windows development (which naturally is the #1 priority), it’s made the HTML-CSS-Javascript model (something that is not that easy to learn in its entirety and with all its quirks across versions and browsers) hellishly more complex and non-intuitive.

One last rant… the overarching complaint I have about ASP throughout the process of this project, is that there is very little carryover value to learning ASP. Let me clarify that. If you were to learn the implementation details of ASP and how it works under the hood, it would translate into a lot of knowledge about the underlying implementation of HTML, CSS, JavaScript, and general web-related concepts. But if you were to learn how to use ASP (such as what you would find in a beginner’s and intermediate book about ASP), you would get very little knowledge other than how to use ASP. I haven’t used JSP since it’s earliest incarnations (and before CSS became standardized and ubiquitous), so I can’t speak with any authority on it, but I do some dabbling in PHP, and the experience is profoundly different.

Anyhow, this is getting longer than I wanted it to be. I’m not profoundly unhappy with ASP… just a little disillusioned maybe.

Moving on. I’m done with the UI rework. I didn’t go for something too elaborate — just something that was simple and organized as possible. If I had more time I would make it a little more graphic (icons and such) so that it wasn’t just a series of tables from page to page. But I think I got it in enough reasonable shape.

Here’s a sampling of some of the pages:

Student View Class Info

Admin View Class Info

My Account

My Classes

Edit Lesson

Drilling Module

Now that the UI rework is done, the final step is to deploy to a live site. I was hoping to find a free, temporary ASP web hosting site, but I might have to do something low cost if I want to avoid hosting that requires something like embedded their ads.

This release is slated to be a UI-only release. The last release completed the features slated for the scope of this project, and at this point, I wanted to do a major design touch-up. I don’t think there is much point in breaking this down to stories, as I find that my UI design time can be fairly unpredictable. Sometimes a design can go well on the first try, but more often than not, there are little details that just feel missing or out of place, which can take a considerable amount of time to fix.

That being said, I do have a time limit on this project, and am itching to finish the rest of my paper so that I can get a draft to my advisor and 2nd reader by April 1, or sooner if possible.

The major goal for this release is that the website not be just so plainly ugly. I made virtually no effort on design-related work throughout the project, in faith that it would theoretically not be too difficult to apply design changes separate from implementation, through CSS. Of course, that’s the theory, but I’m a little wary of how well that will carry over into what ASP allows.

We’ll see how it goes.

This iteration went very well, and I’m happy to say that I was able to accomplish my stretch goals as well, in fairly good time.

Here are the major changes:

1) First, I expanded the riverboat problem curriculum to include calculating drift distance. I could have gone further to implement other problems, but felt that it wasn’t going to add a lot to the project for where I want to take it for now. A screenshot from the new problem supported:

In this case, only one answer is necessary, so the problem was fairly simple to support.

2) I then wanted to show the student their mastery status as they were progressing through the assessment. Because I’m not smart enough to figure out the answer to these riverboat problems in my head, I opted for testing in the Arithmetic section.

Here’s a screenshot from someone working on their mastery status:

And then someone who has achieved mastery level:

3) I then wanted to allow the user to see their mastery level status for all the lessons in a class they were enrolled in. While I was making these changes, I also took a little time to organize the layout into two columns, as the page was getting pretty long. I also started also displaying the mastery level goal for the lesson.

The second part of this was to also show the percentage of the user’s study group that had achieved mastery.

Looks like this student is not doing so great, and neither is the study group.

Admin users got a similar layout change:

4) Finally, student users needed to be able to drill down to look at their own study group and see the mastery level of their study group peers:

Admin users needed to see this for the whole class and for each study group:

So, I’m pretty happy with where I am now in this iteration, as I’ve given myself a little breathing room for next month’s iteration. At this point, I just need to take a step back and tweak the user experience a little in terms of each page, and then start on a comprehensive UI rework, the one I’ve been promising all along that has excused the general ugliness of the entire project.

I also have a significant amount of writing to do so that I can get drafts into the hands of my advisor and second reader by April 1.

It’s February and time for a new iteration. This month’s projected goal was to finish up the riverboat problems and code the assessment policy. This breaks down into the following stories:

• Implement 2 more riverboat problems as instructional units. The current riverboat lesson only has one type of problem supported.
• Implement middleware to calculate a score average and update the user’s score total for the last 10 problems, hardcoded. (This would probably be more in real life, but we’re limiting to 10 scores evaluated for easier testing and verification).
• Implement the middleware in previous story to access the DB.

Although these stories will encompass the projected features for this month, I wanted to add some stretch goals to ease next month’s iteration, if possible. They are:

• Determine and display the user’s mastery status for each instructional unit in the class view.
• Determine and display each student’s mastery status to admins in the lesson view.

I’ve finished what I set out to do for this release — it did take longer than I thought it would, but I’m actually ahead of schedule in terms of coding, as this finishes up my scheduled coding for the month. Of course, I have quite a bit of writing to do for my final paper, so I’ll be kept busy.

Here are screenshots from the major changes in this release:

A page for doing an assessment/drilling…

I started with simple math problems so that I could focus on getting the assessment page to work properly.

If the user’s answer is correct, the page loads the next random problem, and also indicates the user’s success.

If the user’s answers are incorrect, the results appear with the correct answers, and the next problem is asked. For the purposes of this project, users don’t get partial credit.
After I got the assessment pages working, I tried implementing the riverboat problem, which resulted in the following:

Finally, I had to modify the admin pages so that the teacher could specify which problem generator would be used for a particular lesson. I called this a “curriculum” but in retrospect, it probably would be better to relate it to a set a problems within a curriculum. Anyhow, here is the create lesson page, which allows the user to specify the curriculum. The same format is used for the Edit Lesson page, and the view class page also displays the selected curriculum.

We’ll return with 0.2.1 planning after I’ve finished my writing tasks for this month.

Spring semester hasn’t officially started, but I’m on the hook to get this system running and ready by May 1.  That means it’s in my best interest to start now.

I’m going to take a different approach now that I have limited time. Although I’ll still be presenting my iteration planning, the focus is not so much on meeting a particular iteration deadline, so I’m not going to worry about estimating in even chunks, and I won’t be reporting on each story as I complete them, as this adds a lot of overhead. Instead, I’ll just be writing up my planning and retrospectives, and the iterations will be anywhere from 1 to 4 weeks. Bottom line is that I need to meet my monthly goals to stay on track.

For this month, I need to complete the framework for the drilling module, with an arithmetic-based curriculum for easy testing, and then start on a riverboat curriculum.  I’ll divide the month’s goal into two iterations, leaving a lot of the administrative aspect of assigning lessons for the 2nd iteration.

In the 1st iteration, I want to:

• Create a ProblemGenerator and ProblemSet interface framework, that is modular enough to be used with both arithmetic and riverboat problems.
• Implement the two interfaces with 3 arithmetic units — addition, subtraction, multiplication (division adds a wrinkle with decimal/remainders that makes it more difficult, and the point is just to make something easy for testing)
• Create a drilling UI that calls the appropriate generator, hardcoded for now in the lesson DB.
• Implement the two interfaces with 1 riverboat unit — TBD which kind of problem will be done.

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.