Another DrProject Design Question
May 15, 2008 – 8:42 amWe’re pleased to welcome Liz Blankenship, a Season of Usability intern, to the DrProject team. Liz, a grad student in HCI, is going to help us redesign DrProject’s admin interface. Along the way, I’m hoping she can give us some advice on a few other things as well, chief among them the notion of the “All” project.
The background is this: Trac (DrProject’s ancestor) only allows one project per installation. We weren’t going to install it forty times to manage a class of eighty students working in pairs, so one of the first things we did back in 2005 was extend it to support multiple projects per portal. We then faced two questions, which we decided were related:
- What project does a newcomer to the portal see by default (i.e., what’s “home”)?
- How do reach everybody who has an account with a particular portal (e.g., to nofify them of impending downtime)?
Our solution was to say that every portal has an undeletable project called “All”. Every user of that portal is automatically a member of that project, so mailing “all@wherever” will reach everyone, and that project’s wiki acts as the portal’s home page. As a bonus, this also provides a logical place for people to file tech support tickets: if you need your password reset, for example, you could file a ticket against “All”.
It was nice in theory, but it hasn’t worked out that well in practice:
- Lots of people find it confusing. This might be the project name (some people think that registering for “All” means asking to be put in all of the projects managed by a portal), but I don’t think that’s the whole story.
- There turned out to be lots of reasons not to automatically include everyone in the “All” project. For example, external clients for undergraduate projects really don’t care about administrative matters; they only want email forwarded from their specific project, so we had to allow people to opt out and/or turn off email forwarding.
- Almost nobody figures guesses “ticket All for tech support”. Instead, many users file tickets against “All” that should go against other, more specific, projects. Since we don’t have a way to move tickets from one project to another, this causes recurring irritation.
So what should we do? Options include:
- Change the name of “All” to something like “home”. This would be (nearly) trivial, but it seems unlikely that a simple renaming will actually solve our problems.
- Modify the URLs so that the project is a parameter, rather than part of the path; if a project isn’t specified, take the user to a default project. This would make the URLs harder to read aloud (a test I think any good web application should pass), but it would be more reliable than using URLs that might or might not contain a project name.
- Get rid of “All” and:
- require admins to mark one project as the landing pad, or
- give people a 404 if they don’t specify a project when trying to connect.
- Create a special kind of project for the landing pad with:
- a wiki that can only be edited by the admin,
- that automatically says something informative about all the public projects,
- and whose mailing list includes every user, but can only be sent to by the admin.
As you can guess, #4 is my current favorite. It could even be implemented without significant code changes, by defining a new role and giving every user who isn’t an admin that role in the default project. There’d still be the problem of its name, though.
So, what do you think we should do? And why?
5 Responses to “Another DrProject Design Question”
I was definitely a little bit confused by “all” when I first used DrProject. I agree that #4 is the best choice.
Also, a little usability problem that I ran into several times: when I log in, sometimes I would put my username and password and then select my project before hitting submit. Of course, changing the project combo box would cause the page to reload, wiping out my username and password.
I think you should either make it more clear that project selection has nothing to do with logging in, or else have the combo box submit the login form when it reloads the page.
By Patrick Dubroy on May 15, 2008
I’m coming at this problem as someone who has never seen DrProject, and has limited Trac knowledge. I found it interesting because I’m a data enthusiast, and this appears to be a problem of relating entities, and perhaps the problem is even a limitation of the data model in the database (but again, I don’t know).
It sounds to me like every page in the portal is required to belong to some project. If this is true, it would seem probable that it’s a remnant from Trac, where the only purpose for the portal was a singular project, so anyone with an account naturally belonged to that project, and all is well with the world.
With DrProject, it sounds to me like users should be able to have an account with the *site*, and so there should be a ‘user’ table with nothing much in it but account id’s, passwords, names, and perhaps email addresses (if you only allow one email address, anyway). That gives you a one-stop place for contacting everyone associated with the entire *site*.
The notion of a project, then, is different. There should be a project table that contains *only* the bits of data that describe that entity, like the name and description of the project, a project id, perhaps the user ID of the *owner* of the project, and that’s probably about it. The important bit here is that there should be only one row per project in this proposed table.
To map user IDs to projects, there should be a mapping table that contains two columns: a user ID column, and a project ID column. There should probably be a unique index on this table made up of the two columns combined, to insure one user can’t belong to the same project twice, and you can optionally throw in an autoincrement ID field in the table if you’re just used to using them (it’s not necessary, and isn’t likely to do much to help your application).
So now you have a method by which you can not only email everyone with an account on the site, but also email anyone associated with just a particular project, or a particular collection of projects (and sql for removing duplicate users from a query against multiple projects is trivial).
When people log in, they should probably just be presented with a list of projects they belong to, along with maybe some links to edit their account information, and to join/browse other projects.
The highest level in the navigational hierarchy is not a project. Forcefeeding this to the users is likely to be confusing, as you’ve learned. There *should*, however, be a “site” project where people can go to log problems with the site itself, but it’s not clear to me that someone would need to belong to that project to do so — they just have to have an account on the site.
A long rambling comment about a project I admittedly don’t have any experience with, but I hope something useful comes of it anyway
By Brian Jones on May 15, 2008
What about another option: make the “home” page when users log in a sort of dashboard, like when you log into Wordpress.com or even Facebook.com or something. One obvious thing to include would be a list of projects the user belongs too, but this area could be expanded to include other useful information in the future. For example, with a “news feed” of sorts pertaining to any projects they are involved in (what are the latest tickets that have been filed? completed? what are the most recent changes to the wiki? the most recent commits? etc…)
By Blaise Alleyne on May 15, 2008
#4 is my option, but the dashboard thing is very attractive!
By Walter Cruz on May 17, 2008
We’ve come up with something like #4 ourselves. In our case, we are using DrProject for task and documentation handling betweeen the Library and the Computer Center of our university for different projects. So, we are not using the source tracking or mailing lists. Just wiki and tasks, used by a bunch of librarians and a few computer guys.
We’ve put the ‘All’ project readonly for everybody except a few people, because new users were wrongly adding tickets to this ‘All’ project instead of the correct one. After this permissions issue was changed, things are working much better.
I also think that this dashboard idea, news feed, etc., looks very interesting.
By Ferran Jorba on May 26, 2008