Functional Prototype

We developed our application using Microsoft Visual C# and the Microsoft Surface SDK.

The information architecture of our application is given by the following classes:

• SurfaceWindow class, which handles tag-related events and calls upon the following classes to generate ScatterView objects
• Word class, which populates Word objects on the main ScatterView in the form of ScatterViewItems and defines the associated event handlers
• Panel class, which populates Panel objects on the main Scatterview in the form of ScatterViewItems and defines the associated event handlers
• Response class, which populates Response objects on the main ScatterView in the form of ScatterViewItem and defines the associated event handler
• Art class, which populates Art objects contained within Word, Panel, or Response objects and defines the associated event handlers

Phase 1

Our development process was comprised of two phases. During the first, we established medium to high fidelity in the look and feel of our application and medium fidelity in the functionality. Using canned data, we successfully implemented event handlers that populated most of the ScatterViewItems on the surface. The following are descriptions and screenshots of the basic functions of our application during the first development process:

In the native state of our application, shown in Figure 1, there is a “word cloud” in the center of the Surface which displays the themes by which the artworks are sorted in the collection. The Words objects are "scattered" across the screen, inviting users to come over to play with them.

From the word cloud, the user selects a word by touching it, and the associated artwork thumbnails are populated around it, shown in Figure 2. For the purposes of this prototype, we limited each word to four surrounding thumbnails.

When the visitor touches a thumbnail, a panel emerges, shown in Figure 3, prompting the user to respond to the artwork. Depending on the prompt, the user is be invited to "draw" on the painting itself or leave a written response. For a social and collaborative experience, multiple users can respond to the same artwork at once. In order to expedite the testing of our XML I/O functions towards achieving a milestone in functionality, we initially implemented the response feature using a simple TextField at the cost of a GUI-like appearance of our application.

After saving his or her response, the user can view the response or look through the submissions of previous users. In Figure 4, the user chooses to view previous response submissions, and they are populated on the surface. The look and feel of this interaction is improved upon greatly in the Phase 2 of our application development.

Phase 2

We continued to implement and improve the important functions of our application, finessing the look and feel and streamlining the organization of our code.

After writing functional and robust XML parse code, we replaced the canned data with dynamic content from the XML files. From the Artwork.xml file, which contains the tombstone (i.e. metadata) and file information of each piece, we generated the appropriate thumbnails associated with each Word object and the subsequent Panel content. From the Collections.xml file, which contains lists of words and the IDs of artwork associated with them, we generated the appropriate "words" for the native screen and for each surface interaction with the physical tokens.

We replaced the GUI-like design of the response panel with a drawable/editable canvas to allow for a more novel interaction when the user responds to an artwork.

We also implemented the option to search for art by under different categorical queries. To change the way in which the artwork is sorted, the user picks up a physical token and place it on the surface, at which point the word cloud changes to reflect the search query and its results. The tokens represent common groupings of artwork such as "movements," "medium," "place of origin," etc.

We also implemented the following response-related functions:

• Add Response: Rather than saving each response by touching a GUI-like button, users drag responses to an "Add Response" token placed upon the surface.
• View Responses: Users view the 3 most recent responses by placing a "View Recent Responses" token placed upon the surface
• Remove Object: Users remove Response and Panel objects from the screen by dragging them to the "Trash" token placed upon the surface.

The result is a social and novel experience that enhances museum learning by engaging visitors in ongoing discussions about the art in the collection.

Video of Functional Prototype

Strengths

In 3 weeks, we completed all of the main functions and objectives for our application, which include:

• Browsing for and choosing artwork in a natural and intuitive way,
• Exchanging artwork across the surface to other users for a collaborate and social experience, and
• Answering prompts associated with artworks through gestural and multi-touch interactions to move away from traditional GUI-like interactions.

We were able to build a strong base for an application that we think could succeed in improving visitor experience in the Davis Museum in the future.

Weaknesses

For the purposes of this application prototype, our system is built to display up to only four thumbnails per Word object. We understand that in a museum setting, it would be necessary to support the display of more thumbnails. Generally speaking, work can be done to increase the scale of our application.

While we can successfully retrieve the most recent responses to an artwork, we hope to support the randomization of responses and a system of cycling through responses.