Informing Design with Data

After spending so much time working with the results of our exploratory rules study, I was pretty excited to apply some of what we found to the design of the mentoring system and interface. Patrick did a lot of work on the interface design this summer, so I wanted to first make sure I understood all of what he worked on to pull out the pieces that really connect with what I saw during user studies. 

Specifically, I want to work on the problem of mentors writing rules that are just not quite right- how can we design the system to help them see the issues with their own rules and also edit other mentors' rules so that kids get relevant and useful suggestions?

While a lot of the prior work that has been done in Mentoring was on the system design as a whole or specifically on creating the API, I think a few pieces may be really useful to this aspect of Mentoring. One of these is the ability for a mentor to see the existing rules that pass for their mentee's world. This is probably useful for two different reason. First, it may help to reduce redundancy, as a mentor would see that a suggestion already exists and that they can edit it, rather than making another one that is almost the same but "better." Second, a mentor is most likely invested in their mentee and cares that their mentee receive appropriate and useful suggestions. Since it is important to them, they may be more likely to invest time in editing problematic suggestions or rules. I can imagine the mentor thinking about the small scale, but in actuallity, improving other mentor's rules would have a positive effect on the rule system as a whole. 

In exploring possible ways to enable this collaboration between mentors, I considered the two main systems where this type of collaboration exists, Wikipedia and Open Source Software. Both of these have extensive communities that create structures and coordinate the collaborations. While the goal of the mentoring community in writing rules is also to create something of the highest quality possible, it seems like quality in this case may be more subjective than whether Wikipedia facts are correct or whether the software is secure and robust. After all, Looking Glass worlds can't really be wrong. Learning programming is one facet of Looking Glass, but creativity also plays a role in creating worlds and staying engaged. I've been thinking about things like Wikipedia talk pages, git commit messages and revision histories, trying to figure out what kind of solution will work here...