Designing the DrProject User Experience

The All project

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!