Problem Statement.
I’ve finally been making some progress towards building a Sage-based ‘problem server,’ as we were talking about way back in January. It’s clear that the tools developed have a wide scope of use. Before building something that gives open questions and reacts in really interesting ways to input, a stepping-stone is to build something that serves up individual math problems and asks for an answer. In some sense, such things are already done by Webwork and Moodle with varying degrees of success, but building a nice implementation would allow some new directions.
Now, I should stress that I think WeBWorK is pretty awesome, and has some really transformative potential. I’ve been encouraging its use in Kenya, and it’s been extremely interesting seeing it used in service courses in Strathmore University and now Maseno. These are places with ever-increasing class sizes, and a well-designed online homework tool promises to greatly improve student comprehension of the course material. The big database of existing problems in WeBWorK is also really helpful; there are over 26,000 problems in the Open Problem Library. There are three issues with WeBWorK that a new implementation could/should address:
- Modularity: WeBWorK is a pretty monolithic piece of software. It includes three essential components: a problem server, a problem database, and a learner management system (LMS). Basically, these should be busted out into three genuinely separate components. Breaking out the problem server allows easy integration into Moodle or another well-thought-out LMS, or else integration directly into things like online textbooks.
- Modernization: The WeBWorK codebase was mainly developed some time ago, and new versions are slow to come out. (The last stable release is from December, 2010, over two years ago.) The interface is also decidedly… Clunky. There’s a natural question of how one could improve the system using modern AJAX-type tools. Better interactivity will lead to a much better user experience. Things like one-button signup with Google or Facebook accounts is one thing I can think of off the top of my head that would greatly improve the user experience.
- Ease of Writing Problems: Currently, WeBWorK problems are written in a highly idiomatic version of Perl. I was interested in writing problems a couple years ago and got the feeling that it was, in the end, a bit of a black art. The documentation is a bit scant, and most mathematical objects have their own idiomatic libraries. Switching to a python/sage framework would mean that writing problems should become much easier: Sage already recognizes all of these mathematical structures. And if the problem definitions are in python, we’re really using the same syntax as our Sage work. This should make it much, much simpler to pick up a bit of Sage and then start writing problems.
Interestingly, I stumbled on an antique design philosophy document for WeBWorK. The first principle is building on the work of others wherever possible; Sage is doing this for the math backend. The third point outlines the reason for the choice of Perl as a language, citing wide use among web developers. In fact, I think we see at this point that most WeBWorK developers are mathematicians of one stripe or another; Python and Sage are heavily used in this community, much more so than Perl. In thinking about making it easy for a broader audience to write problems, it’s well worth considering that AIMS (for example) is giving about 150 African students a year a basic grounding in Sage. This is a large group that could be developing problems to fit secondary and university courses.
But the user-experience and difficulty of writing new problems are the limiting factors on WeBWorK. It’s easy to get educators really interested, but then the gap comes in thinking about developing problem sets for the full Kenyan secondary school curriculum. The cheap solution is to find interested, technically competent teachers, and get them writing problem sets for their classes. But the overhead and technical ability involved are currently much too high. It’s an open question as to whether a switch to python/sage would lower that overhead enough, but I think a real improvement is possible.
It’s also super easy to imagine something like Project Euler or Rob Beezer’s online linear algebra book incorporating knowledge-check problems; building in flexibility to deploy in radically different contexts than a graded academic environment would be a real plus. Combined with the sort of quick-to-develop login systems one gets from Django, this would mean that an online textbook could track your progress on the exercises! This could lead to getting hints when stuck, or be used in a course as an ad-hoc online homework system. A real improvement over paper books…
Work So Far.
Thus far, I’ve been getting a handle on a few different technologies. But basically I’ve been focused on learning Django (a great python-based web development backend) to play ball with the Sage Cell Server, developed by Jason Grout and Ira Hansen. The interactions involved are illustrated up top. Basically, Django is already good at interacting with browsers and databases, and using a template system to serve up custom content, and I just need to learn how to use it effectively. Luckily, there’s a pretty good free book for that, so really it’s just a matter of time and effort.
The chunk that’s new is building up the interaction between Django and the sage cell server. Jason Grout has already written a basic python client for the cell server, which is a good starting point but it’s clear that it needs some further fleshing out to be ready for prime time; the main difficulty is figuring out good and web-friendly interactions with the websocket interface. This has already been solved on the client-side for the main sage cell server, but here we need to have most-all of the cell server interactions happening on the client side. (We can’t expose the problem definitions to the client browser, or else different kinds of cheating become possible.)
On the bright side, the server side is a lot easier to control, and it’s easy to imagine using some of Sage’s coercion framework to validate student input, instead of relying on sketchy ‘exec’ statements to evaluate submitted code. In a problem setting, unless we’re running something like CodeAcademy, we usually expect certain kinds of student input, and can try to coerce their answers into the expected context. For example, using something like ‘QQ(s)’ we can try to coerce a string ‘s’ into being a rational number. This fails loudly if you try to pass it something (like, say, a function) that isn’t a number, and we don’t have to worry about any sneaky code inside of ‘s’ being ‘exec’ed.
In any case, there’s still lots to think about and play with, so back to work with me….
Inventing Situations. 