0.2.2 Retrospective

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.

 

0.2.2 Release Planning

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.

 

0.2.1 Retrospective

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.

 

0.2.1 Release Planning

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.

 

0.2.0 Retrospective

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.

 

0.2.0 Planning

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.

 

Spring 2008 Timeline

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

 

0.1.9 Retrospective

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!

 

Release 0.1.8 Retrospective and 0.1.9 Planning

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.

 

Edit Lesson

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: