We'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?