China WBI

Almost done with the milestones for this month. 

1. Develop paper prototypes. (DONE)
2. Learn problem domain (DONE)
3. Setup development environment. (DONE). SVNserve has been installed on my desktop, and I’ve setup a source code repository for all code and documents for the project. I am using TortoiseSVN as a client app to retrieve and check in files. Highly recommended.

   

4. Finish ASP book. I’m about 3/4ths through skimming ASP.NET 2.0 Step by Step book, and about halfway through Programming ASP.NET. Since my original goal was to finish 1 book, I’m about done with this, but I’d like to read a bit more before the month ends.
5. Model problem domain and solve problems algorithmically. (DONE). See last post.

I think I’ve made pretty good progress, considering some of the unexpected issues I faced in the outset. However, I do think that my March goals are a little too aggressive, so I’ll be relooking at it and making adjustments as necessary.

Upcoming

• Read more in the ASP books
• Re-evaluate schedule and start breaking down tasks for March

I’ve just finished a desktop application that solves the riverboat velocity problems. The reason behind creating this app was to explore how the problem domain would be programmed, and to also serve as a basis for how the problem should be solved when it is presented using ASP. As I’ve mentioned before, the UI — whether a website or a desktop window — should not have an effect on how the problem is actually modeled and solved; therefore, I should theoretically be able to use the same class (or module) I designed and plug it into the website.

Here are screenshots from the app. First, we have a picture of the app when it starts:

After the Solve button is clicked, the solutions appear on the bottom of the screen:

Any of the parameters to the problem can be changed. The new solutions will appear when the Solve button is pressed again:

Implementing this application actually brought up a number of hairy issues. One thing that I realized is that the “answers” were not as straightforward as I thought. For example, for the time to cross the river, you could say that the answer is 1.25 hours. But there are actually 3 sub-answers that make up that answer — the value 1.25, the units the value is in (hours), and how many significant digits are shown as the result. I remember taking physics, and my teacher (and the textbook) heavily emphasizing expressing the appropriate amount of significant digits, based on the information known.

What I originally thought of as one output is actually 3 outputs. For the units, we can go in two different directions — we can allow the student to specify their units, or we can force the student to answer in the units specified. The latter is commonplace in the physics classroom, so we can get away with that. The significant digits issue is a much harder one, though, for many reasons, including the fact that intermediate calculations need to carry an extra significant digit, which is eventually rounded with the final result. If we are truly modeling problems and sub-problems as recursive composites (i.e. problems that have sub-problems which are problem in and of themselves), the “correct” answer for a given problem, in terms of significant digits, is dependent on whether that problem is the original problem or a sub-problem. In this sense, the problem has to be aware of itself and what it is, which complicates things.

For now, it seems the simplest route to ignore the significant digit issue, but we may revisit it if time allows, as our “solution” wouldn’t pass muster with physics teachers. But this isn’t the point of the project.

Finally, the way things are implemented currently aren’t abstract enough. That is to say, I’ve solved the riverboat problem, but if I had to solve a different kind of problem, I could use basically nothing from what code I’ve written. Ideally, we want a framework for solving problems and making solutions so that the same framework could be used for different kinds of problems in different kinds of classes.

I’ve really wanted to design this framework now, but again, in the interests of time, and because this isn’t the point of this project, we’re going to forego designing a very detailed, robust framework, and just try to be as flexible as possible while putting priority on getting the site as a whole working.

A quick status report on this month’s objectives:

1. Develop paper prototypes. (DONE)
2. Learn problem domain. (DONE)
3. Setup development environment. Thank goodness that I started reading the new ASP book, because I found that there is a server built into VS2005 that I can use for development purposes. Even though I can’t use it when I actually deploy, it’s certainly a better option than trying to downgrade my laptop to XP Home and install my XP Pro on my desktop. The other thing I discovered is that my desktop isn’t much faster than my laptop in terms of pure speed, so it wasn’t going to be for much gain anyway. This still leaves the question on where I will be able to deploy once I have the actual site up for testing, but I can deal with this question a month or two down the road. The last remaining task for this area is to setup my source control server (svnserve) for version control on my source code, which I plan to do before the end of the month.
4. Finish ASP Book. As I mentioned in the last update, I’m just skimming my original book, of which I’m halfway through, and instead focusing on Jesse Liberty’s Programming ASP.NET 2.0. I’m liking this book much better, in terms of its thoroughness, clarity, and technical strength. It’s a pretty long book, however, so this area may not be done by the end of the month, but I will still have done more than I projected, since I have the other book as another reference.
5. Model problem domain and solve problems algorithmically. I’ve done the initial conceptual model for the riverboat problems, so I’d now like to actually program a few classes that translate the mapped out concept to actual code. These will not be web pages, but just C# classes which demonstrate the solution to the riverboat problems.

Upcoming:

• Continue reading ASP books 
• Setup SVN server for source control
• Code solutions for the riverboat velocity problems in C#

Here are paper prototypes of the main pages listed in the sitemap. I’m not artistically gifted, but this was a quick way of visualizing an end goal. One thing I’m realizing already is that the “smiley face” convention may not be the best one for indicating progress. Among other things, it may not have the same connotation in different cultures. Anyhow, I can’t think of a compelling alternative at the moment, so it will stay until I do.

Here is a draft sitemap for the China WBI project. I don’t have an official name for the project yet, so it’s “China WBI” until I have that name.

One issue becomes obvious when visualizing the sitemap — to do practice drills of a particular unit, or to take a test on a unit, you have to go down to a depth of 4 levels, which is not terrible, but can get a little irking after a few times. (Incidentally, this is one of the things that irks me about WebCT).

One of the ways we can collapse the tree is to provide quick links on the My Classes page (which is the page that the user should get to after logging in). These quick links could have direct links to the last unit the student is working on, and since each unit has the same structure with both practice and test pages, the direct link to the currently working unit can be immediately followed by links to its practice and test pages.

Now that I’ve selected the riverboat velocity problems as the problem domain, and understood what is involved with solving the problem, I need to come up with a way to abstract the solving of this problem. As it turns out, the concept of solving a mathematically-based problem is inherently the same as what a computer procedure or function does. You have a set of inputs, which you run through some kind of algorithm, and produce a set of desired outputs.

Accordingly, I could just map a riverboat velocity problem onto this directly, such as a programming procedure akin to:

Vector CalculateResultantVelocity(Vector boatVelocity,
      Vector currentVelocity);

The strength of this approach is that it’s simple, straightforward, and easy to code. But there are several problems with this approach. The biggest weakness is that it’s just too simple. The reality is that many problems in physics (and other domains) are actually composed of other smaller problems. You often find that solving a problem involves breaking down a large problem into several steps or components and solving them. For example, here is a diagram of a problem which is actually done in two steps.

Each step has its associated input and output — and notice that the output of the first subproblem becomes the input of the second subproblem. Even a simple equation like

a = 2 * ( 3 + 2 ) – 4 / 2

can be broken down to individual arithmetic operations, arranged in particular orders. The point is that for a complex problem, part of the solution is breaking down that problem into appropriate components, each of which are simpler to solve.

So what does this look like for a riverboat velocity problem? Here’s a diagram for calculating the resultant velocity of the boat and river current:

There are several inputs — the speed and direction of both the boat and the river current. The output we are aiming for is the resultant velocity, both speed and direction. As it turns out, this problem can be broken into two parallel components — calculating the resultant magnitude of the velocity (or speed), and calculating the resultant direction. The first problem only needs the magnitudes to solve, while the 2nd requires all four inputs.

The two respective problems are actually are just geometry/trigonometric calculations applied to a real world situation. You could argue that translating from “Calculate Resultant Magnitude” to “Use Pythagorean Theorem” isn’t a problem — that both algorithms are the same thing mathematically. But you could also argue that part of the problem in solving the real world problem is knowing which formula to apply, and which parameters apply to which information you have. In fact, some of the other riverboat problems require only arithmetic — what students get wrong is which values to plug in.

What consequence does this have for programming these problems? One of the patterns that emerge immediately from looking at the last two diagrams is that the problem and its subproblems are recursive in nature. That is, there really is nothing to distinguish a subproblem vs. its parent problem. They are all just problems, really — they have inputs and outputs, and an associated algorithm that is operated on to convert between the two.

This means, in programming speak, that we’ll probably want to model the “idea” of a problem as a class (actually an interface) that both subproblems and problems derive or implement. And, that a problem can have child problems (the subproblems). I’m not all too sure right now whether a problem also needs to have a reference back to its parent problem, but the answer will probably emerge later as coding begins.

The point of this exercise was to do a little thought before coding, but not so much that we fall into an analysis paralysis funk. It will be interesting what kind of class design eventually emerges after a few iterations on the problem domain, and how flexible it will ultimately be, when trying to add support for other algorithms and problems that are very different.

The title of these updates have subtly been changed from “Weekly Update” to “Project Update.” Well, not so subtly anymore I guess. But since my work schedule seems to fluctuate a lot on a week-to-week basis, the updates won’t be consistently one week apart.

One step forward, two steps back

My project has hit a few snags here and there, but they were inevitable snags, which I suppose is better than avoidable snags. I don’t think that this month’s commitments are in any jeopardy, though. Here is the status of each area:

1. Develop paper prototypes. I started some sketches for a few pages, but started feeling like I was lacking some context. Then it occurred to me that I’m not following the usual process I’ve come to be used to in my web design consulting, which is to start with a sitemap proposal. Although a sitemap at this point is likely to be changed many times as the site is developed, it helps to have that big picture in mind. The power of the web is in interaction, and so when designing the UI, extra care has to be given to establish the user in the appropriate context.To make a long story short, the plan now is to put a draft sitemap together before I do more work on the paper prototypes, which should be done within the week.
2. Learn problem domain (DONE). I pretty much have nailed the understanding I need for the riverboat velocity problems I will start with, as referenced in the last post.
3. Setup development environment. As mentioned earlier, running Visual Studio 2005 and IIS in XP Pro has been insufferably slow on my laptop, which makes me think that I will need to use my more powerful desktop instead as my development machine. The huge problem I have now, though, is that I need to upgrade my desktop to XP Pro. I shelled out a lot of cash to buy an XP Pro upgrade, but there is no way to revert back to XP Home from XP Pro. Essentially I have to do a clean install of XP Home on my laptop to free up my XP Pro license key (Microsoft’s EULA for XP is one install on one computer), because there is no previous OS to fall back to. Which is a huge pain since I need to backup all my files and reinstall all my software. Anyway, it looks like I have no choice, but I’ll need a full day to reinstall in case things don’t go smoothly during the process, so either this weekend or next weekend. I’ll suffer with the laptop until then. The only other thing I need to setup on the development environment is source code control (SVN). I’ll need to setup an SVN server, which I prefer to do on my desktop, after I’ve done the XP Pro upgrade. I already have VS 2005 with Resharper running on my laptop and desktop, so everything else is setup for now.
4. Finish ASP book. I’ve been reading Microsoft Press’ ASP.NET 2.0 Step by Step book, but liking it less and less as I go through it. It doesn’t seem to be much of a rigorous book, mostly taking the reader through trivial examples. On top of that, following the instructions in the book for one of the chapters is repeatedly causing VS2005 to crash. This is all the more irritating since VS takes over 1 minute to restart on my slow laptop.I’ve decided to skim through the rest of the book, and instead start reading another book, Programming ASP.NET by O’Reilly. I’ve always had good experiences with O’Reilly books, and this one is co-authored by Jesse Liberty, who also wrote Programming C#, which I really liked.
5. Model problem domain and solve problems algorithmically. I should clarify what this task is. When designing an application, the real design task is to take one’s understanding of the application domain, and figure out how to model it. Any problem that an application is trying to solve should be explainable without reference to program- or implementation-specific details. For example, I should be able to describe how a riverboat velocity problem should be solved, independent of whether it will be solved with a web-based application or a desktop application. I should also be able to program an application component that can solve a given riverboat velocity problem, without any code that deals with web pages. My main goal with this task is to come up with a basic, but robust and flexible design and architecture that will accommodate more than just riverboat velocity problems. My goal is also to implement a component which solves the riverboat velocity problems within the framework of that architecture. Sound too abstract? Hopefully it will make sense in my next planned post, which will introduce my thoughts on the domain model for this problem, and some of the complexities associated with it.

 Upcoming

• Map out the problem domain
• Create draft sitemap
• Start new ASP book
• Start paper prototypes
• Migrate XP Pro to desktop machine

Well, I finally took the plunge and sat down to understand what’s involved with solving riverboat problems. Here is the basic premise:

A boat is going from one end of a river to another. We assume several ideal conditions; for example, that the river is nice and straight, and that going from one end to another is always the same distance, as long as we are going directly across.

Here is the problem — we know the speed and direction of the boat. But there is also a river current that is perpendicular to the direction of the boat, which is either going up or down the river. So we know what the speed and direction is of the current. Finally, we know the distance between one shoreline of the river to the other.

 There are several questions that can arise from this setup:

1. From the perspective of an observer standing stationary on the shoreline, what is the effective speed and direction of the boat (also known as the resultant velocity)?
2. How long does it take to cross the river?
3. How far upstream or downstream will the boat travel in the process of crossing the river due to the current?
4. What is the effective distance travelled by the boat in one crossing?

Problem #1 involves vector addition, but actually a much easier form of it, because we already know that the two vectors we are adding are perpendicular (or normal) to each other. This makes the magnitude of the resultant vector easy to calculate with the Pythagorean theorem.

Finding the direction of the resultant vector requires trigonometry. Again, since we know the we have a right triangle, it’s not too hard to calculate the angle. In short, theta, as shown above in the diagram is equal to the inverse tangent of the current speed divided by the boat speed. Or,

theta = inverseTan ( currentSpeed / boatSpeed )

Not too bad.

Problems #2 to #4 are ridiculously simple arithmetic problems involving only multiplication and division. The only difficulty is in understanding the problem correctly and knowing which values to use.

My goal will be to use these 4 problems as a starting template for an instructional unit. There are variations that can complicate the problem. For example, we might ask what angle and velocity the boat should go in order to have a resultant velocity which is perpendicular to the river, and negates whatever drift is caused by the river current. This would definitely be harder, but the immediate goal is to get something working — we can always expand on what we have later.

It’s hard to predict what the schedule will be for an exploratory project like this, where most of what I am coding will be with technologies I am using for the first time. After creating a draft schedule, I’ve realized that indeed, the scope of the project is fairly big, and it’s definitely going to extend beyond the end of this semester, if I’m intent on keeping the level of features I originally thought of. At this point, I would hope to be done with the technology portion by this summer, and then run through with some test users and write up a lit review and report sometime in late summer or fall semester.

Here is a stab at some of the things I expect to be working on til June:

February

• Develop paper prototypes
• Learn problem domain
• Setup development environment
• Finish ASP book
• Model problem domain (vectors) and solve problems algorithmically

March

• Setup basic login and user authentication
• Develop drilling and test modules

April

• Prototype drilling module
• User profiles (teacher & student)
• Create and manage students, study groups

May

• Prototype testing module 
• Report and progress display functions
• UI design

June

• User acceptance and usability testing
• Performance testing
• Live deployment