Tuesday, April 14, 2009

Expanding Evals Idea

In this post, I sketched out an idea for a new evaluation system focusing on brevity, frequent use, and graphic representation of information. I got a couple comments about it, and both focused on enforcement.


So how do you build policy and enforcement into software? Well, that can easily be done with checks before user actions to ensure the desired outcome has been achieved. To be honest, I don't like that. One of the top goals for my idea is that users should love--or at least not really hate--using the software. Building enforcement rules into the software doesn't align with that goal.


However, in order to be effective, students actually have to use the software to get effective evaluations. As put to me by Nate, if students don't have to do anything, they won't do it. That makes sense. So how do you ensure students use software that doesn't force them to? What makes us use the current evaluations system.


To answer that, I will stick with an idea that I've always carried with me for a while: be cautious when trying to make software do something a human should do. I love software because it helps us be more effective. It enables efficiencies and helps us do things better than we ever thought possible. It can even open doors in some situation. However, as a society, we shouldn't let software cripple us in areas where we should be competent with or without software.


Thus, software shouldn't always replace good policy, human management, and work ethic. In this software, I could easily hide a submit or exit button until the user fills in all the required information. I could write code that nags the user until he or she completes each evaluation. Yet, that is terribly annoying. It detracts from the user experience I want to create. It also eliminates the ability to work in increments--ie, work a bit, save it, and return to it later.


The current evaluation software doesn't have any enforcement rules, yet they get done. That is because there are policies or business rules to ensure things get done. In our context, the policy is "do your evals or something really bad is going to happen to your grade--even though we're going to be mysterious and not tell you what." In this software, the same thing will hold true.


Software should supplement, not replace, business rules. It can supplement management by providing reminders, work flow tools, collaboration and communication features, and a list of other things. But the human side of things can't be replaced by a machine.


Students won't do anything they don't have to, but a piece of software shouldn't force them to do it. If there is going to be a "bad guy" in the situation, it should be in the management and not in the tool. Enforcement will lie in management--or the faculty in this case--and it will not go into my proposed solution. In my opinion, I don't think that's where it belongs.


That being said, I do see some value in creating reminders or feedback to give the student the hint that certain tasks should be completed. I could see having some notification pop up when a user is exiting to inform them that active tasks have not been completed. It might even send an e-mail alert to inform a student that their required evaluations have not been submitted and they have x number of days to complete them.


Edit: This is a late addition I thought I should add
Another thing I see is letting the software make use of data to enable managers to enforce participation. Each point submission and comment will be associated with the user that submitted it. While it probably shouldn't be shown on the interface, the system can record that "User xyz submitted the following evaluation on mm/dd/yyyy". A PM can just look up all comments made by a user and see that there were submissions for all the appropriate categories. Good reporting tools will be essential to making this work.


I think this is kind of a fun idea. I've spent some time looking at the Google Charts API and I think that could be an awesome way to present some information. I haven't put any other design considerations into it, but it might be a fun project to work on.


Any comments, feedbacks, or angry rebuttals? Please leave a comment if you have one. If you think this would be a good project to start, let me know and I'll see if I can set one up. Drew forced me to set up a GitHub account yesterday to share my Change Management software with him, so I'll spend some more time learning about Git.


Thanks for reading! Cheers.

No comments: