Multiuser Bibliography Advanced Web Authoring Module 2

The assignment for Module 2 is to build an application that uses PHP and MySQL on the back end (and XHTML and CSS on the front end). It needs to provide various views and controls for the stored data to different user segments. The development process emphasizes user experience and objectives.

For this project I've elected to implement a multiuser bibliography, which will let some users create, view, and edit references to sources. Of course there are many existing bibliography applications, from personal bibliography systems (BiBTeX, EndNote) to online citation indices (CiteSeer, Google Scholar) to hybrids that combine the two (Zotero). I'm not looking to replace any of those. This project is primarily a learning exercise, not a full-featured citation database. It will offer basic functionality to let a few collaborators work together to document resources.

But it will have some practical value as well. I will be using this application in collaboration with Kristen Flory to create an annotated bibliography for another project. We'll each be able to view, add, and edit entries from any system with Internet access. I don't know of another bibliography application particularly suited to that mode of work (though I haven't looked for one, either).

User experience design

The right sidebar contains links to the various documents that comprise the user experience design for the application.

The User Experience Strategy document is a high-level view of the application. It provides short answers to two questions: What is the application trying to accomplish? What will users want it to do?

More detail emerges in the Functional Requirements, a list of anticipated requirements for the application in various categories, from infrastructure (hardware and software) to implementation (functionality, security, etc) to the development process (such as testing). The functional requirements list is a technical document, rather than being written for a general audience, so while the implications of its contents need to be vetted by users and stakeholders, they may need to be explained to non-experts.

Use Cases describe things users might want to do, how they do them, and what might happen in the process. Use cases are used to guide the behavior of the system as it's being developed, and to anticipate potential problems that may not be apparent from the descriptions of features in the functional requirements.

The actual design of the system begins to emerge with the Architecture document. It shows the various parts of the application—viewing, searching, adding, and so on—and how they relate to one another. It's a short series of diagrams in the visual notation developed by Jesse James Garrett. Like the functional requirements, the architecture is primarily aimed at implementors (and to a lesser extent designers, who will refer to it in constructing navigation tools, for example). It's possible, though, that users will also want to see whether it matches their existing or intended workflow.

Of more interest to users are the Information Views, which show what kinds of information will be presented to users on particular pages of the application, and how it's likely to appear. These aren't mockups of complete pages (those appear in the Design Comps below); instead, they demonstrate how the application might present particular kinds of information and controls on a page.

The Database Design is purely an implementation detail, and should not be of interest to users (though stakeholders with the appropriate expertise might want to vet it). It shows how data will be organized in the database. Here too, though, there are implications that users should be aware of, particularly since the database design may or may not support particular new features in future releases.

Users can finally begin to get a sense of overall look and feel with the Wireframes. These sketches outline the significant areas of the main pages of the application. They show little of the actual formatting or content, but suggest the layout and basic elements of the page. Wireframes let users see whether the application will present related material conveniently, whether the application's design is consistent from page to page, whether pages look too sparse or crowded, and so on.

The final piece of the user experience design are the actual Design Comps (or "Composites"). These are mockups of the actual application pages as I think they might appear in the final product. The design comps give users an opportunity to see and critique the formatting and aesthetics of the application design. It's not an actual usable prototype of the application, but it does provide the visual experience.

Project Journal

Progress on the project implementation is tracked in the project journal.

HTML documents were composed by hand using the Vim editor with syntax highlighting. PDF documents were created in OpenOffice.org's Writer (Use Cases and Database Design), Impress (Architecture), and Draw (Wireframes) applications and exported to PDF.