I now have a mockup to share of my idea for a to do list.  It is similar to Basecamp’s to do list: a simple list with optional ownership indicated for each item.  However, each item may also have colored labels, the way that Gmail uses them.  Labels may then be applied to signify which component an item is in, or what the priority level or due date of the item is.  (You can see the urgent label in my example below, set to red, stands out as an important label.)

To do list mockup

To do list mockup (click for full size, then click by green arrow for detail)

About the mockup

The basic idea behind the screen I created should be evident, but here are some further ideas for how the interaction might work that I can’t do quickly in OmniGraffle. Hovering over any item in the list would highlight that item, then clicking on it (as you can see from the mockup example with the green arrow) would expand the details for that item. Clicking on a label in the labels box would filter the list to show only those items that use that label, and the note at the bottom about what is hidden would change to describe what is hidden accurately and link to all active items. The filtering could be much more complex, but in the interest of keeping things very simple, this is what I designed.

Needs analysis

When I was brainstorming, I needed to figure out what the smallest set of features was that would fit students’ needs for a class project, so my first problem was to understand what both the students and the professor need out of such an interface.

The first difference I identified between traditional project management sites like Trac and student projects is that their projects are usually more about the creation stage than the maintenance stage.  In other words, planning is more important than bug tracking by far.  There are also deadlines, deliverables, and grades.  Those are usually beaten into their head by their professors and teammates, so while they’re important, they’re probably automatically part of the student’s plan for success (unless they failed to go to class and don’t know the requirements).

Since the students probably won’t be generating 100’s of items, I thought that they would only need a few ways to organize their to do items: ownership and custom labels.  That way if priority is important to them, they can create a priority tag, but if it’s not, there’s less visual clutter.  They can forgo labels altogether if it’s not their style and just add them if they find it necessary to further organize their plans.

Wrap up

One final question I would have before I wind down on this design activity is whether or not comments and discussion need to be possible “on” or associated with a specific item, similar to how you can currently have a progression of comments associated with a ticket. I’m unsure about this. I think that the mailing list may be sufficient, but I would appreciate input from anyone who has experience using DrProject for student projects. Did you make use of the ticket commenting feature, or did you just e-mail about issues? There’s always the question of whether there should be one more feature. I think for simplicity’s sake, I’ll reject the idea for now, but I would appreciate feedback.

Other than that, I think I’ve met the challenge Greg gave me; to think about how we could create a simple, student-friendly to do list feature to replace ticketing.  I would be excited to see something like this implemented, but I also really thought the work Nick Jamil did with creating an extensible ticketing system was neat.  It would be especially beneficial for higher level or longer term programming projects.  I guess only time will tell what direction DrProject decides to go, maybe we can have both!