This project aims to produce a multiuser bibliography application: a tool that will let users collaborate in building a list of resources (with optional annotations), with features for adding, editing, viewing, and searching entries. One key aspect for the user experience is that this application is a tool, and so should accomodate users' existing modes of working rather than dictating new ones. (Some applications can and should dictate new modes of operation; driving a car is not like walking, for example. This isn't one of them.) Another is that it is collaborative. Thus it must be responsive to the needs of multiple users; and it must let those users share data, but maintain reasonable boundaries (for example, by making it clear who has contributed what addition or change).
Collaboration also means that the application should foster a sense of community among the users. Some of that can be done by tuning the user interface (for example, by including a short history of recent edits on the splash page when a user signs on to the system). It's easy for this to lead to feature creep, however. Another way to maintain a sense of community is to make users feel the application itself is a member, through a feature set that emphasizes communal values such as utility (the tool should provide a useful function), trustworthiness (the tool should be reliable), and cooperation (the tool should be easy to use).
These principles have shaped the user experience strategy I describe here. Below are some notes on particular topics I reviewed in formulating the strategy (prompted by a set of questions from Mike McLeod and the discussion in Jesse James Garrett's book), followed by the actual User Experience Strategy statement itself.
For this project, I'm in the somewhat unusual but fortunate position of being both the developer and one of the primary users. The initial task for this application will be to create the annotated bibliography that Kristen and I are producing for our Visual Rhetoric independent study. Thus I'll have first-hand experience with using the application in the real world.
As a developer/user, I want a working system as soon as possible, with sufficient useful features to make it worthwhile for our VisRhet project. That means keeping the feature scope tightly defined and in agreement with the project strategy. (It also means using an agile development process, but that's outside the scope of this document.) By the same token, I want the system to be genuinely useful for Kristen, so that we have real joint use and collaboration.
My other users — Kristen and any future users — will want an interface where basic functionality is clear, or the relatively narrow feature set won't justify the adoption effort. The special advantages of this application over others in its class should be clear, so users can decide whether to invest. Users want an application like this to perform its function reliably; unlike, say, a purely informative site, or even most commercial sites, an application like this one cannot afford to lose user data, as it represents significant user effort. Finally, users will need considerable flexibility in the application, so that they can enter data for many types of resources and not feel that they're coercing their information into an unnatural form.
Besides basic software benchmarks (a running application with useful features that doesn't crash — a goal that continues to elude much commercial software), the primary criterion for this project, at least in its first stage, is its successful use by Kristen and me for our Visual Rhetoric bibliography. In particular, Kristen should be able to report that she finds the application useful and convenient and is using it "naturally", not merely to assist me in satisfying a requirement for this course.
Longer term, if the application proves sufficiently useful to publish it for other users, success could continued to be gauged with bug reports, enhancement requests, and other user feedback.
Aside from my own opinions as a user, the preceeding discussion of user needs is entirely speculative. Given resources for empirical research into user needs in this area, I'd begin by investigating other applications in this class (such as EndNote), to improve my sense of the problem domain and existing solutions in it.
Then, to interrogate user needs, I'd ideally employ contextual inquiry. While I acknowledge the value of self-reported user stories, I think users may not always be fully aware of how they incorporate tasks such as recording and retrieving bibliographic information into their own workflow. For example, citing a source while composing an academic essay is essentially an "out of band" activity — it interrupts the flow of normal writing — and so users may postpone it without even realizing they're doing so. Contextual inquiry would let me observe such behaviors and consider how the application might accomodate them.
Also, there's extensive research on the use of and difficulties with citations, such as the considerable work being done on the "citation cleaning" problem (recognizing that two different citations refer to the same work). While much of this lies outside the scope of this application, it would still be useful to spend some time reviewing it. Sometimes minor changes to an application can avoid a problem that's widely known among domain experts but inobvious to new practitioners.
As the site/application developer, I want the multiuser-bibliography application to meet the following objectives:
Users of the site/application will want: