|
|
Thoreau
Lovell
 Margo Dunlap
Joanna Plattner
IS213 Spring 2001 |
Second Interactive Prototype (Demo--2nd Interactive)
The First Interactive Prototype was designed to support two broad classes of users: 1) those who want to find, view, and use digital images, and 2) administrators who want to catalog images and manage the digital asset collection. To ensure that our design supported our user's most critical tasks we constructed the three "key path" scenarios.
1. Search for a set of images for the purpose of viewing onscreen.
2. Search for a set of digital images and request access to the files
for organizational use.
3. Catalog a set of newly created digital image files.
Since completing the First Interactive Prototype we have received valuable feedback regarding its design in the form of: 1) a heuristic evaluation, and 2) an informal walk-through with our project sponsor. We incorporated a large portion of our reviewer's suggestions and comments into the Second Interactive Prototype. However, most of the changes reflect a marked increase the system's core functionality that was not supported in the First Interactive Prototype.
The new functionality added to the Second Interactive Prototype addresses the problem of how admin users (Image Coordinators and Image Processors) add images into the system and how general users can request something that isn't already in the system, i.e a new digitization of an object for which there is not object record in the database. We also began to explore how to incorporate browsing as well as searching for images (and objects).
Designing the interaction model for both processes required diverting attention away from the UI and toward the database design in general and the interchange of data between the DAM database tables and the museum's Collection Management System (EmbARK). We broke down the process of adding images into 1) Creating new object records and 2) Associating digital image files with those object records. Screens supporting (1) are included in the Second Interactive Prototype, screens for (2) will be included next round. At the same time we were thinking through the database design issues for the prototype, we also created a simplified MS SQL Server database and wrote (or modified) ASP code to query the db and display data for related objects, as well as thumbnails of images of those objects. This work will also be extended for the next round.
With connectivity to the SQL Server database immiment, we decided not to generate a complete set of hard-coded html pages. Therefore, viewers of the Second Interactive Prototype should not expect continuity between the search, request image, add image, and catalog image screens.
Working on the Second Interactive Prototype it became clear that the interaction design of SFMOMA-DAM had reached a level of complexity that necessitated a more systematic diagramming methodology. We adapted Jesse James Garrett's "visual vocabulary for describing information architecture and interaction design" (http://www.jjg.net/ia/visvocab/#sum) for this purpose. Using his Visio stencil file and the ability in Visio 2000 to save in HTML we were able to easily share design ideas. DAM Architecture diagrams
In conclusion, comments on the First Interactive Prototype, among other considerations, directed our focus toward interaction design and database design. Our second priority is developing example ASP code to demonstrate selected Web-to-dB functionality. And third is refining the graphic design of the system.
Modifications Summary
I. Revisions
- Request Image Task
The cornerstone of the "Image Request" process is the "image request" form, which is loosely based on the shopping cart metaphor. Users use search and browse to navigate to a visual representation of the image they need, and they "add" it to an image request in the same way shoppers add books to their Amazon shopping cart.
We modified the interaction design to make it easier for users to view image requests at all stages of the image request life cycle (saved but not submitted, submitted, and complete).
The image request form was extensively revised based on specific feedback from the heuristic evalution. The most problematic aspect of the interface was the location of the Submit/Save/Delete buttons. Originally we placed them at the top of a potentially long list so that users would not have to scroll to the bottom to find them. This was universally panned by our evaluators as being unnatural and confusing. Our solution was to add explicit "step by step" instructions at the top of the form informing users of both the necessity of the last step as well as its "location", and we added a quick "go to bottom" link so users wouldn't have to scroll down the page manually.
Additional image request form changes include:
1. A new "visual summary" of the requested images (origin: SFMOMA)
2. An "add images" link (origin: HE)
3. Redesigned the "remove image" interface. Now users can either "clear" the entire form of detail images, or remove them one image at a time via a "remove this image" button that is repeated with each image. One of our goals with this design was to reassure users that removing an image from the image request would NOT remove it from the database. (origin: HE)
4. Consolidated the Standard/Advanced image request screens into one interface. This simplification was possible because a complex interaction was moved to a new "add image" process (discussed later). (origin: internal)
5. Added a pop-up window that explains unfamiliar terminology and guides users in making their "image class" selection. It dissapears on "mouseout". (origin: SFMOMA)
Search Task
Documentation has been added to each search interface stating that search returns art objects with associated digital images and not contents of the DAM system.
II. New Features
- Browse
Users may search for art objects by browsing artist name by alphabetical order or by collection. The dialogue box is situated below Search on the Home page and Search page, and briefly describes the functionality. The alphabet is presented in lower case letters which link to a Browse display of lists of artist by alphabetical order and by collection. Collections include: photography, sculture, architecture and design, media arts and painting.This is the first implementation of browse. Browse supports recognition over recall in the search and retrieval process of art objects. The intended functionality is to
- Add Image to Existing Image Request
When a user selects an image to add to an Image Request, the user recieves a system feedback indicating that their selection is added to a new image request as a default. The user can accept the default or select from a menu of existing saved image requests. The selected image will be moved into the highlighted image request indicated by the menu.
- Creating New Object Records
Essentially, there were three problems that had to be addressed in order to support adding new object records. First, in order to avoid creation of duplicate records, we had to integrate searching for existing Object Records into the process. Second, we had to allow users to pull object data from the EmbARK, the Collection Management System. Records created from EmbARK need to be read only from the DAM perspective, which adds some complexity to the interaction design. Finally, we had to design a process for indicating the new object's place in a parent / child object hierarchy, and to support adding new child objects at any level in the hierarchy.
- Requesting New Digitization
Our model is that for there to be an object record in DAM that object must have images associated with. How then do users request digitization of a new object? First, just as in Creating New Object Records, we integrate searching for existing images (just in case!) into the request new digitization process. In this way we also support requesting new versions (different shots) of objects already in DAM, as well as new digitization of sub-components of objects, such as a separate digitization of a drawer that is part of a chest of drawers in the Architecture and Design collection. Users can still request digitization of objects that are completely unknown in DAM, by typing a very minimal amount of descriptive metadata, Artist / Maker, Title, Date, for each object, and then preceding through the standard Image Request process. In this case the descriptive metadata they enter for each object is saved to a temporary table, where it can be reviewed later by an Admin user of DA
III. To-Do
- Catalog Image
- Image File Delivery
- DAMfolios
The HE evaluation and SFMOMA walkthrough resulted in a number of very helpful suggestions for revising the Catalog Image, Image File Pickup & Delivery screens and implementing a grouping function resembling portfolios in EMBark. These features failed the "critical path" test for this interaction design cycle. They will be studied and refined as part of Prototype III.