DrProject was originally derived from Trac.  I have a lot of experience with Trac before it hit v. 1.0, which is also before it had any web administration.  I just recently discovered a Trac demo site that includes their new web administration. I find it interesting that our versions of web administration are nearly completely disjoint. Trac has ways to edit the basic ticketing system, while our web-admin contains virtually nothing about tickets but a lot about roles, creating, editing and deleting projects and users. I guess since Trac only manages one project at a time, and the user list is basically whoever has access to the subversion repository the site is linked with, that leaves very little to administer.

It’s really cool, reflecting on it all, to see how far DrProject has come in extending Trac’s capabilities and becoming more suitable for a classroom environment.  Though there’s still a lot that could be done to make DrP better (just look at our list of tickets), I can appreciate all the additional functionality and hard work it’s taken to get there.  It will be really neat if the new ticketing system and IRC integration are added in.

Summer’s end

In any case, I’m happy to have contributed to the effort this summer and hope I’ll have time to keep up with the project and give some more input in the future.  I’ve made up a page to summarize my efforts on this project under the About this project link in the blog navigation.  It’s mostly complete now though I’d like to add some sort of before and after screenshots to show off me and Qiyu’s changes.

Thanks to everyone I worked with this summer, it’s been great!

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!

Mingle Card Wall

Greg mentioned Mingle to me, so that was my starting place. One of their neat ideas is to have a card wall. I had seen card walls used to track where a client was in a process before, but using it for tracking software issues and new features makes sense too.

If a professor sees it as important for students to be thinking about different steps in the development process, this is a good approach.  While Mingle has many steps, I think just a few such as Development, Testing, and Completed might be sufficient, with possible also Planning and Need Help. The Need Help column could put the students on the professor’s radar (this was an idea from one of the students I interviewed). The other great thing about this view is the simplicity. You’re not seeing a big table with all the details of each item, and yet, the details are available at a single click that gives you focus without losing the context.

(See also: Video including interaction with Mingle card wall.)

Hierarchy

During some further brainstorming, I realized that it would make sense in many projects to drill down deeper into more details as the semester goes on, breaking up larger items into the many pieces or resulting issues that are discovered as the learning process goes on. For instance, at the beginning of the semester you may only know that your final version must have a shopping cart, while a little later, you may realize that your shopping cart needs to be secure, calculate a subtotal of the cost of all the items in it, and calculate shipping. These ideas may also have sub-ideas.

Well, I thought that my friend and I were coming up with something unique, but it turns out Mingle also has “card trees” that allow you to organize cards into trees. Their idea is more restrictive, however, in that each level of the tree must be composed of a specified card type. I think a looser organization without necessarily “typing” the cards would be appropriate for students.  The visual organization and a drag-and-drop environment would make it effective an easy to use such a tool.

(See also: Mingle’s Card Tree Video)

To do lists plus labeling

While all these Web 2.0 things are pretty neat, and drag-and-drop interfaces make them relatively easy to learn, I think I favor an even simpler solution.  Check out  this quick demo of Basecamp’s to do lists. The cost of having such a simple system is that it only gives a limited level of organization; you have lists, and optionally, owners of each to-do item.

I would suggest taking something like Basecamp’s to do list and adding the smallest amount of other features necessary to serve students’ needs. We don’t want the system to get too busy and visually distracting. One suggestion that I have is to add a tagging or labeling system, similar to that used by Google Code and Gmail. Google Code takes labels one step beyond what I think most student groups would want by allowing categories of tags to be defined such as Priority, while Gmail keeps things simple and color-coded.

In-line editing

TargetProcess has in-line editing of lists – a must have for simplicity.

I have a mockup in progress that I’ll share soon, but I wanted to share some of my thoughts so far as a status update for this week.

I’m struggling with this a bit because I feel like my technical knowledge isn’t enough to really give me what I need regarding Dojo, etc. In fact, I don’t really understand what parts of our interface are determined by Dojo code or widgets’ default settings and what parameters were defined by our programmers. An example of this is a misconception I had about the menu. I noticed that it had tabindex=-1 for many of the menu items which prevents keyboard access, but I assumed it was assigned by Dojo and that there was a reason for it since I couldn’t see what ARIA support was in place. Wrong. Apparently it was assigned by a developer who was most likely thinking of users who have both keyboard and mouse access. Most of us wouldn’t want a menu to be included in the tab order because we’d use the mouse to click on it, but we need to keep the design at a level where it is accessible for more. Without learning Dojo and/or digging through our code, it is challenging to try to understand enough to make recommendations. I still have a few pages to investigate furtherthat don’t read properly with WebAnywhere.

I’ve also been trying many of the pages on DrProject with keyboard-only navigation with a fair amount of success. The tabindex on the menu was the only significant problem I discovered.

Thanks to David Bolter for some help with getting started understanding Dojo and accessibility. Only two weeks left… I hope to get further in that time!

Forms

I think the chapter on forms and user input in Web Accessibility: Web Standards and Regulatory Compliance has been one of the readily applicable.  I’ve made some initial suggestions for making fields more accessible and Qiyu has already implemented them in some places.  (Thanks!)  I’m sure I’ll find additional accessibility issues in our forms with a little more looking, so I’m keeping that on my to-do list.

Navigation

I was hoping for more solutions out of the chapter about navigation, but I think I’m going to have to do a little side-research on what’s the best thing to do with drop-down menus.  Right now, when you load DrProject.org with WebAnywhere, you see that all 30-some navigation items and sub-items are displayed (and thus read) to the user.  While it was useful to learn that users can easily skip to the first heading using header navigation, I think 30 items is too many to force a user to go through if they do want to find a menu item.  In addition, the screen reader reads the disabled menu items amidst all the menu items without telling the user what they are.  I will have to think about if there is an auditory equivalent to the visual cue for being disabled.  Title text on a link to nowhere, perhaps?  There may also be a way to structure the items so that chunks are skippable using screen-reader commands.  Maybe putting the sub-menus in lists?

Knowledge Transfer

One of the things I’ll need to accomplish during my last few weeks is to summarize some of what I’ve learned so that others can pick up work on accessibility knowing where DrProject’s problem spots are.  I’ll probably create a new wiki page on our Accessibility efforts.  It would be neat if there were a way to embed an auto-generated list of all open tickets tagged usabilitiy…

Only three weeks remain of my summer in Seattle and thus of Season of Usability!  I hope to be able to spare some time to continue work on DrProject, but it will have to take a back seat to my coursework.

The biggest design challenge DrProject has is the All project.  It’s just another project, but sort of more than a project.  Let me explain a little better.

Each project in DrProject has several components including Tickets, a mailing list with online archive, milestone tracking, a wiki, and of course, access to the files in version control as appropriate.  The “All” project is a project in which (in theory) all users have membership.  Thus, there is a site-wide mailing list and wiki, and site access issues, etc. can be tracked using tickets.  Basically, a project solely for the purpose of site-wide communication and coordination.

Problems with having an All project

There are several problems with this approach.  For one, the information architecture is confused; it’s sort of overlapping multiple levels of the site hierarchy.  “I’m a project!” “No wait, I’m a site-wide tool!”

Another problem is that we’re trying to extend the project metaphor beyond its natural application.  While all the other projects on the site likely correspond to things referred to as “projects” in the real world, the “All” project corresponds to the class or organization in which all of these projects are taking place. We need to find a better mapping or help users make this leap.

Possible solutions

I probably shouldn’t say “solutions,” but these are some of the ideas I currently have for improvements.

1) Keep the current project structure, but rename it and re-frame the ways in which a user perceives it.

• When a DrProject site is created, have the user define a name for the site.  Give the All project this name instead of “All”.  It could be a class name or company name.
• (Optional, but I think I like this:) Change the upper right navigation: all other projects would still be accessible by some kind of dropdown, but there would also be a link to “CPSC101 Home” or whatever the site name is followed by home.
• Add a note anywhere that the special project might cause confusion, or restructure appropriately.  (For instance, make sure that there is no way to delete the special project.)
• If technically possible, override the Wiki Home for this project to include things (should I call them widgets?) like the dashboard below.

2) Delete the All project.  Add simple dashboard like that seen below, and a site-wide mailing list.

• This lacks a ticketing system.
• It’s hard to have pages that aren’t part of projects without restructuring the way urls for DrP work.  (Greg blogged this.  I’d be interested in more details.)
• You would need new controls implemented for people who need to be registered on the site but wish not to receive site announcements.

3) Instrument an easy way to make any project a “special” project

• Have a setting for each project that indicates if they are special, “All”-like projects.  I.e., once marked as such, all future self registered users will be automatically added to these projects.
• Has the benefit of allowing multiple projects that all users can be a part of
• Would still need a special dashboard page for site-wide announcements

It was really helpful to brainstorm with Paula on Thursday.  I feel like I had a reasonable approach so far to thinking about this problem, and we might have made some progress toward a solution.

I think #1 is pretty much what Greg proposed a while ago, and now that I’ve thought more about it and learned more about DrProject and a little about the technical side, it’s probably our best bet.  I still feel like I’m struggling here because I don’t fully grasp the technical requirements or feasibility of various choices. I wish there weren’t any technical restructions…   I let my imagination go a little more for the next two portions of this post.

Dashboard

Here’s the basic idea I have for a dashboard-like landing page:

Information Architecture

While thinking about the All project dilemma, I spend a lot of time thinking about the information architecture for the site.  I did a cardsort using a tool I found on online.  While perhaps this technique benefits even more from being iterated with multiple users, I found that it helped me better understand the site and break out of the existing site organization to consider other possibilities.

I found that with this approach, I discovered ways to drastically reduce the complexity of the main menu for DrProject and make it much clearer to understand.  There are many things to consider about restructuring a site – number of clicks, page loading time, ease of understanding, technical limitations.  I was redesigning ignoring pretty much everything except for ease of understanding, a shallow but user-centered approach, but perhaps something can be learned from it regardless.

The following image and the Dashboard image above illustrate my concept of an easier to understand architecture for DrProject.

A few things to note:

• I relocated Wiki navigation to local navigation within the wikified pages.  Users would only see those wiki actions that they are able to perform.
• Tags are similarly relocated from being in the main menu (at the third level) to having a simple “Tag cloud” link wherever you are able to apply tags.  The tag cloud page would need an additional control to switch context from a single project to the site-wide tag cloud.
• All menu items are at the top level of the navigation, no drop downs.  When you have a project selected, the navigation is for tickets etc. that are only in that project.  When you’re on the site level (which you can get to via the “Home” link) you can access the Dashboard and stats/tickets etc. for all projects at once.
• The Admin link would also only be visible at the site level when the user is an Admin.

I think that sums up most of it.  If anyone else is interested in cardsorting DrProject pages, I’d be happy to send you the “cards” to sort if you’re willing to download the cardsorting program!

I’ve neglected to post over the past few weeks, but that doesn’t mean I haven’t been keeping busy. I’ve done several informal user tests, and rather than posting my results here, I wanted to give them directly to the dev community and make sure they were searchable from within our development site. You can view them in the e-mail archive here:
User 1
User 2
Video clip of user 2 creating a user, and discussion of the “All” project
Video clip of user 2 creating roles
User 3

For my own future reference, I want to note my technical problems.

1.  Problems with my computer setup:

• My keys are rearranged into the Dvorak layout.  I need an external keyboard so that if users want to look at the keys, they can.  (I have one, but it didn’t make it to Seattle because of my minimalistic packing.)  This also ends up being a small handicap for me if I need to type during the test.
• External mouse would be nice, too.
• It’s a Mac, and sometimes people are used to Windows.
• Make sure to turn off e-mail notifier, instant messenger, any other potential interruptions.  (I did most of this…)

2. Problems with software:

• iShowU, my screen recording software, apparently crashes when you get up toward an hour of recording.  Thus, the video that I would have had for user 3 is lost.  I should take more detailed notes, though I think I did an adequate job, and if I’m going to have long tests, take a break in the middle!  It’d be good for the users too.

3. Test structure

• There are advantages and disadvantages to testing your friends.  I did not structure the tests very much and left them very informal, and thus I have much background noise and informal dialog to sift through when parsing the video for user 2.
• I loosely structured some tasks on the fly, but for the most part I let my users wander and they may have benefitted from a greater sense of purpose.
• There is also the risk that they’re saying “That interface ROCKS” because they know I designed it and they’re being nice.

Despite these obstacles, the tests were quite successful in gleaning a lot of useful reactions to DrProject current and potential interfaces.

Approve users

Before I got around to user testing, I had been continuing to create redesigns for the Approve users interface.  My current favorite is this:

The tooltip would show when you hover over “More.”

This interface does several things I like:

• Combines existing user requests with current user requests, but has a visual distinction between the two (note the “New user” text under some users’ names)
• Hides “extra” user information.  For some existing users, the admin will know who they are.  If they have any doubts, they can hover over More to learn more about the user.
• Powerful handling of all requests at once.  You can approve all, deny all, or set all roles to a certain setting.  In a classroom setting, all of these features would benefit a professor trying to take care of a bunch of requests quickly (the role setting option will only provide a significant benefit if they set all of their students to the same role).

When I did the user testing, I had one user who couldn’t explain why, but he preferred the current Approve Users interface over this and one of my previous designs.  His only explanation was that the verb came first (Postpone/Approve/Deny) and that made the most sense to him.  I feel that the checkbox interface is more intuitive and requires less clicks than dropdowns.  If only I could have a fully functional implementation of each of the interfaces in question to do some real user testing.  I am thinking about trying out CogTool, which seems to take prototyping one step farther to allow things like checkboxes and dropdown menus added on to mockups of screens.  If I do that, I will need to find a new round of users for testing to get some better results.  Right now, I don’t think the Approve Users redesign merits that kind of additional time input because there are so many other parts of DrProject I’m also working to improve.

User administration

Qiyu has done a great job implementing the create users screen and I think beyond a few more tweaks and some testing, it is completed.  It’s a great improvement from before, and the changes should hopefully carry over to the Register Users screen fairly easily.  He’s also started to tackle the List users screen and has been working with Greg to nail down the requirements.

Challenges beyond the Admin Panel

Several of my concerns about DrProject usability were solidified by seeing new users wading through DrProject for the first time. One of these concerns is that there is little indication of where you are within the structure of the site. I feel that something like breadcrumbs will be the solution here. I have noticed some other project management sites use this as part of their solution to a cumbersome navigational structure. I also hope that we could make the navigation more intuitive. Users often asked, “Does this mean for the project, or for the whole site?” Finally, the biggest issue left on my plate for this summer is what to do with the “All” project. I’ve been stewing on this and paper prototyping a bit. Paula, my usability mentor, has offered to meet with me next week and I’m hoping that the “All” project will be one of the issues we have time to work on together. It will be nice to have another HCI person to work with for a change, and one I can learn a lot from, I am sure!

Throughout the first half of the summer, I was focused on learning DrProject in and out, identifying the easy to spot usability issues and possible solutions, and redesigning the Admin interface based on my own experience. Now that I’ve been exposed to DrProject for so long, it’s harder to put myself in a “new user” perspective. This is why I’m turning back to more user-centered design techniques now such as user testing and fleshing out the usage scenarios and personas I’ve had in mind. I also feel a little better about asking my friends to contribute their time as usability test subjects now that I have some ideas for the new interface fleshed out to show them and get input on both the existing and hypothetical designs.

Updated Prototype

I’ve updated my prototype to include a new idea for Approve Users:
http://www.lizblankenship.com/drproject/admin_panelv6/Approve_users_1.html

Personas

Personas, for those not familiar with this user-centered design technique, are fictional characters created to help keep typical users in mind.  They help to make some of the attributes and needs you expect your target user audience will have more concrete and prevent you from designing a product solely for yourself.  Since DrProject is primarily intended for classroom use, I’ve created several simple personas in that context, which you can see here:

CS professor
Herb Sidek

• Techie, comfortable with linux and command line tools
• Busy, teaches a lot, and doesn’t want to have to spend much time with administering the tools he offers his students
• Wants to expose his students to things like version control and project portals
• Has a system administrator install DrProject and then administers it using the web interface

Student
Sam Yarti

• Uses DrProject to coordinate with classmates because the professor set it up
• Has a few informal development projects with friends that he might consider using DrProject for in the future
• Likes using DrProject because it helps keep his teammates accountable

System administrator
Ed Johanson

• Installs DrProject on one of the school’s servers as part of his job
• Is very busy at the beginning of the semester with setting up software upgrades and technical support for newly arrived faculty and staff

Project manager at small software company
Jennifer Lang

• Organized, but busy with juggling projects, she wants to have a way to keep track of multiple small scale development projects at once
• Is a networker: she heard about DrProject from a friend who uses Trac but was thinking of switching when they heard of DrProject
• Enjoys her job of 4 years, currently overseeing the 23 technical employees at MiniComp and pitching in on projects as necessary

I’ll post some scenarios soon, and the results of the user testing I’ll do tonight. I’m looking forward to testing some more friends. (And sharing my delicious ginger cookies with them! A little bit of gastronomic bribery since I don’t have any real payment for them.)

Note: This post was written on July 9, but somehow skipped being published, so I’m doing so now.

Check it out: Prototype

This prototype incorporates the recent mockups I’ve posted here (Approve users, create users) as well as some ideas for the Project/User details screens, suspend/reinstate users, and more. I also tried out a different approach to using the Admin panel and added in bread crumbs that are local to the admin panel.

I think I have enough now to do some informal user testing of the original interface and this prototype with a few of my friends. I would welcome feedback from anyone who reads this as well!