Capstone: Gamification of the UI of Learn2Mine

Learn2Mine has been deployed in the AI and Data Mining (CSCI 470 and CSCI 334) classes here at the College of Charleston. In the past, we deployed Learn2Mine in Data Science 101 classes so the students that will be using Learn2Mine should be far more advanced than the users in the past, by just sheer experience in the field.

One thing became very clear, very quickly, during this second piloting of Learn2Mine - students do not like having to use multiple tabs or windows when using Learn2Mine. To me, this seems like a very innocuous problem that really should be overlooked because of the complex nature of the backend of this system. But at the end of the day, your users are your life when it comes to applications such as this. So we decided to take an evolutionary step with our software.

Now Learn2Mine is primarily being used a teaching and learning tool, which is great - so let's simplify the interface that students have to use whenever actually learning. You may have read earlier posts and saw where I've talked about Galaxy being built into Learn2Mine. If you're a student, then you never even have to know about Galaxy. Galaxy is strictly back-end now and the interface students were using with it in the past is going to be completely unbeknownst to them now. Dr Anderson worked furiously to get an API call set up to run Galaxy jobs programmatically (through a python call). 

So, if you have read and become versed with the basics of how Learn2Mine works, you may be wondering how exactly students can get their work graded and receive feedback. Below you will see a screenshot of where students submit their code:

Now there are a few things that will jump out at you if you have been keeping up with the way Learn2Mine works.

First, it can be seen that there is now compatibility for Python 2.7, in addition to R. The initial need for this came about through the AI class since the work they are doing will all be in python. But what really sparked the "need" for this came from the data mining class. A lot of the students are not comfortable working in R and some of them feel that they can work a lot better, quicker, and easier in python, even if it means utilizing multiple third party libraries. So now we have to code solutions in two different ways in order to allow students to code in either language when trying to progress through our system. 

Second, it looks like there is just a button that grades your code. So what happens when you submit? 

So I inserted some text and clicked "Grade R Code" - obviously this should raise an error, but that is part of what I want to show you here. The output here is the exact output you would get if you were to try and run my text through an R interpreter. So you can get the exact trace. Also, though, if you submit code that is syntactically correct, then the feedback box will contain feedback pertaining to why your submission was wrong -> maybe you didn't define the function the way we specified, maybe your signature for your function was incorrect, maybe you were not able to produce the correct matrix, etc. Whatever your problem is, we tell you.

Alright, so we let you submit your code in bulk. Big whoop. That is only going to promote the idea of people trying to code entire solutions at once. Well, to combat this, I have been working on an interface upgrade for Learn2Mine to go side-by-side with Dr Anderson's R/Python upgrades in order to promote the breakdown of coding problems into more atomic pieces.

So the page I have been screenshotting and posting here is for the "Empirical Naive Bayes" lesson. Learn2Mine is set up so the last problem on a page is effectively a "Boss Fight" (we're trying to come up with better nomenclature for this, but that's on the backburner) and you really only get credit for getting the problem correct if you defeat the boss. But what are the problems before it? Well, in the same vein of video games, we give students the opportunity to practice and hone their skills in order to take on the boss. For example, in the Empirical Naive Bayes lesson there are two problems before the boss problem that break down the process into 2 smaller steps. In this naive bayes problem your ultimate goal is to compute the posterior probabilities, but in doing that you will compute prior probabilities and densities. So we have abstracted out the computing of the prior probabilities and densities. So if students write these as separate functions, then they can verify if they have those steps correct by running their code through the non-boss forms. Then they can just add that function to their code for the boss and just call the function when it's needed, rather than having errors in all kinds of crazy places.

Lastly, as a motivation tool for doing this more atomic parts of the problem then working toward the boss, I have created a visual progress bar. If you complete the earlier problems then this bar will start to fill up and give the user a sense of achievement (hopefully). Of course, though, if a user goes to the boss problem and just conquers it, then the bar will fill all the way up because you shouldn't be punished for already being able to do the final part of the problem. Below you can see the bar after having completing the 2 non-boss problems for the empirical naive bayes lesson:

Music listened to while blogging: Kanye West