Multiuser Bibliography User Strategy

This is a multiuser bibliography, a tool to let people collaborate in building a list of resources (with optional annotations). Users will be able to add, edit, view, and search for entries.

What is this application trying to do?

Researchers need to keep track of resources they find. This application aims to help them do that.

Specifically, it should:

  1. Be a place where users can record resources as they come across them, or whenever else is convenient. In fact, it should become their preferred place to record resources; if they'd rather just jot them down on scraps of paper, then the application isn't providing them much value.
  2. Let users look up resources that they or their collaborators have recorded. They should be able to look them up by browsing or searching. A bibliography isn't any good if you can't get information back out of it.
  3. Help users collaborate on a bibliography. This is the application's main advantage over pen & paper or other single-user systems, so it has to be obvious, easy, and effective. Collaboration includes both enabling joint work where it's appropriate (such as the ability to comment on other people's entries), and maintaining boundaries between users where necessary (by recording who contributed what, for example).

What other needs should this application satisfy?

  1. It must satisfy the requirements of the WRA 410 Module Two assignment, since it's being developed under that mandate. (This is really no different than having to satisfy a government regulatory regime, for example, and it's a perfectly reasonable, even useful, objective.)
  2. It needs to enable the annotated-bibliography portion of the joint project Kristen and I are doing for our Visual Rhetoric independent study. It needs to do that naturally, as a convenient solution for that task, and not simply to exercise the application for WRA 410.
  3. It needs to fit with the overall look and feel of the site, and with the site's design principles: conformance to applicable standards, clean and robust underlying implementation, aesthetic appeal, and clarity.

What will users want to do?

When people use an application like this to keep track of the resources they're accumulating for a project, they'll need to:

  1. Add entries in some way that fits their workflow. That might mean adding them when they come across them, or entering them in batches later.
  2. Browse through and look up entries. They'll need to be able to search based on any sort of information — not just author or title, but also things like when an entry was created.
  3. Export entries into other forms — print them, include them in articles, etc. Sometimes that will just be one entry, and sometimes it will be several or all of them. If users have to retype information from the application, it's not saving them much effort.
  4. Edit entries, if they find they've made a mistake or need to add more information.
  5. Look at entries added by other people, and comment on them.

That's what users will need to do. What else might they want?

  1. A system that's more convenient for the job (creating a joint annotated bibliography) than the readily-available alternatives, such as pen & paper (or machine alternatives) — probably the most common mechanism — or a blog, such as the one Kristen and I are using now. That means it must provide better collaboration than personal tools such as pen & paper, and be more suited to bibliographic data than the blog.
  2. The ability to get into the application as quickly as possible, so it should be accessible from a wide variety of locations, and signon should be simple.
  3. A form for entering new entries that's quick, easy, and most importantly clear for a variety of types of sources.
  4. An interface that does not impose an inappropriate structure on the data. For example, not all resources have explicit authors, so users should not feel required to enter an author's name.
  5. Assurance that their data is safe. Bibliographic data is precise, complicated, difficult to remember, and expensive to recover. It's well-suited to being maintained by software — as long as that software is reliable. Losing information is unacceptable.