The Designers’ Outpost: Capturing and Interacting with Design History

“Our design study showed that calm, lightweight history provides substantial value to designers.”This research was conducted with Michael Thomsen (PhD, University of Aarhus, 2002) and James Landay (Associate Professor, UC Berkeley).

In a high-tech field like web design, we might expect to find computer-savvy practitioners accomplishing all their work with the click of the mouse and a stroke of the keyboard. However, in our studies of the early stages of web design, we found that good ol’ pens, paper, walls, and tables were the primary creative tools. This is not because designers aren’t comfortable with a keyboard and mouse. In general, we found a keyboard and mouse just aren’t appropriate. Working with paper on large surfaces enables collaboration and informal interaction. However, there are drawbacks. Viewing information in different ways (e.g., a graph and a spreadsheet table) and moving between tools is easy in the digital world; paper doesn’t provide for this. In addition, working with paper doesn’t provide a clean way to keep track of or navigate the history of a design. And paper doesn’t afford for collaboration across multiple sites.

In our group, the Group for User Interface Research at UC Berkeley, we’ve built a system called the Designers’ Outpost [1-3] that bridges the physical and electronic worlds. Users have the same capabilities in the Outpost system as in a paper and whiteboard system. One can create new pages by writing on new Post-it notes, add them to the electronic wall, and organize a site by physically moving Post-it notes around on the board. Paper in the physical world becomes an input device for the electronic world. A rear camera mounted inside the board captures the location of notes, detecting when notes are added, removed, or moved. A front camera captures the contents on the physical notes so that electronic counterparts can be created by means of a rear-mounted projector that outputs electronic information back onto the wall surface in the physical world (see Figure 1).

Field and design studies
Before building this history system, we conducted and learned from field and design studies. Newman and Landay [4] interviewed eleven professional website designers, providing us with two important insights. First, designers create many different intermediate representations of a website. Second, “Designers expressed a desire to have a unified way to manage different variations of design ideas. Variations play a key role during the design exploration phase, and it would behoove an effective design tool to help support their creation and management.” [4]

After building an interactive prototype of Outpost, we conducted a design study with fifteen professional website designers. It became evident that designers really needed support for their design history: they stated that they often forgot the history of how some part of their design came to be, or they would alter their design and then realize that they preferred a previous design. These studies not only gave us insight into the working practice of web designers, but they also motivated our focus on better support of design history.

History interface
Outpost provides three lightweight mechanisms for accessing design history: a main timeline, a local timeline, and a printable synopsis view. The main timeline is a visually navigable set of design thumbnails organized on a timeline. Filters provide for a compact timeline representation. We employ a branched history, presenting the current branch to the user as a linear history. This linear history is annotated with stubs, indicating the existence and position of other branches. It is possible for users to jump to any point on the timeline, including semantic places such as when an object was created. The local timeline enables users to see, in the actual design, a history of the actions relating to an individual object in the design. The synopsis view enables post-design review of key bookmarks. These bookmarked states can be annotated with text and printed as hard copy for easy portability and sharing.

Timeline visualization
The main timeline displays a history of the design using thumbnails, as seen in Figure 2. Each thumbnail presents the contents of the board at the time of capture. To support the user in determining what has changed between adjacent frames, we highlight the elements that were altered in the most recent frame (see Figure 3).

Filtering thumbnails
Designers use the timeline interface to choose the set of thumbnails to display. In the most detailed view, the timeline displays all thumbnails—one thumbnail per single action the users have performed at the board, such as creating a link or moving a note. View all is useful for local undo. More substantive interactions mandate using our other filters: By Actions, By Bookmarks, By Meeting, By Time, By Note, By Focus, and By Author (see Figure 4).

Timeline navigation
Thumbnails not only display information about the state changes of the board, they also provide a direct-manipulation interface for navigating the design history. By clicking on any thumbnail, the system undoes or redoes all commands that have been issued since that point in time, restoring the board to that state. This multi-level undo/redo allows designers to experiment with the information design, because they know that they can always return to a previous state (see Figure 2). Though the electronic touch interface works very well for selection, we found operating electronic GUI widgets clumsy for scrolling. To support more fluid scrolling, we integrated a Contour Design USB jog dial (see Figure 6) for direct physical interaction with our system.

While our studies have shown many benefits to a paper-centric tangible interface for freeform design, the physicality of a design artifact becomes problematic when engaging its history: it is not possible for the system alone to perform an undo operation for all possible physical actions made by the user, such as adding or removing a note from the board. In our system, a combination of user actions and history manipulations can yield one of two degenerate cases: either the current view calls for presenting an object without a physical presence, or there is a physical object that should not be present. In the former case, we display the electronic capture of the object. In the latter, we give the object a red shadow to indicate it should not be present, hinting that it should be removed by the user.

Branched time visualization
While most contemporary applications support multiple undo/redo, it is most often the case that only one strand of actions is held in the history. Some undo/redo systems, such as the one in Emacs, offer the user a truly branched history. Branched histories have traditionally been difficult to navigate because users have a difficult time building an accurate and complete mental model of the history tree.

Our goal was to preserve the entire history, with all constituent action strands, without introducing unwieldy complexity. Branched histories are normally represented as a tree. While this presents the whole history, the visualization rapidly becomes complex as the number of branches increases. This complexity creates a user burden that is too large for our domain of informal, early stage design.

As a lighter weight alternative, we present the branched history as a linear list of actions, where inactive branches are represented by a collapsed stub, as shown in Figure 2. This presentation preserves the time-wise order of the actions; a frame presented to the right of another frame corresponds to an action that was issued after the other. It also scales well; multiple branches can be shown inside each other by nesting the stub parenthesis markers. A user can open or close any branch, choosing a presentation of the timeline relevant to the objects he is interested in.

Local timeline visualization
The main timeline visualizes the history for the whole board; the local timeline provides a lighter weight history for an individual object. When selecting a note by tapping it, an object menu is displayed (see Figure 7). The object menu supports both common operations such as deleting the note or making it persistent, as well as displaying a small note history along the bottom. This in situ timeline offers the user more detailed information about a particular note without visually cluttering the entire board.

 

Synopsis visualization
One advantage of electronic capture is its ability to support radically different visualizations. We provide the ability to work with history electronically (see Figure 8) or printed on paper (see Figure 9). Users may not always be at the board, and a printout serves as a take-away design record that they can share, discuss and write on. The synopsis visualization fills these needs.

A synopsis can be constructed in two ways. First, it can be constructed via explicit user bookmarks. Bookmarks can be created at design time when a team arrives at a spot worth marking, or they can be created after the fact by going back to a point in the timeline and bookmarking it. Users can view their set of bookmarks when viewing By bookmarks. A synopsis can also be constructed from a filtered history view (e.g., every 12 actions). A user can select bookmark timeline to add that set of states to the synopsis. These two techniques can be combined to manually augment an auto-generated state set. For example, a user could begin a bookmark set with the states produced from the By Meeting filter, augmenting it manually with key points from the meetings.

When viewing the main timeline by bookmarks, there is a button to bring up a synopsis view. The synopsis view displays each of the bookmarks vertically on the left-hand side of the screen. It provides a text-box to the right of each bookmark for entering a description of that state. The synopsis view can also be printed for offline use.

Design study
During the course of development, six professional designers used the history system and offered us their feedback (see Figure 10). When the history system was in an early state, we brought in two designers who worked at the same firm to talk with us about their current practices and to try our system. In pre-study interviews with the pair, we found they currently had a difficult time managing history; their state of the art was to save “bookmarks” and “versions” as files with different names. When working with our system, the history utility was primarily used at a macro scale. Working physically and electronically occurred in cycles. They would add content for a while, work with it, then make the board electronic, and delve into the history. In addition to finding the history useful for reflection and design rationale, the pair commented that they would find value in using the history to make client accountability clearer. Having a step-by-step record of all the changes, along with annotations as to why they were made (e.g., “client asked for advanced search feature”), enables this accountability.

With the software completed, we brought in four more designers in three groups: one pair of colleagues and two individuals. The participants were very enthusiastic about our bookmarking features and the ability to generate a synopsis view.

Participants found the View all filter distracting, reminding us of the need for calm interaction. Viewing every single command is only useful for local undo, rare during fluid brainstorming. (The one time it was useful was when the system misrecognized the users’ input.) One finding from our previous study was that calm interaction is essential to an effective electronic whiteboard. Beyond its limited utility, View all is the antithesis of calm; it renders a new thumbnail for every command the user executes. This makes for a hyperactive electronic whiteboard. Based on this, we have changed the default filter to be the By Actions filter. This provides visual locations the user can move back to at a coarser interval (the default is every 6).

One participant commented that his favorite aspect of using computer-based tools was the easy saving which enabled him to try new ideas and have different versions. After three of the participants had worked with the system, it became clear that save and bookmark should be integrated. We eliminated a separate save button, and included the save functionality as part of the bookmarking process for the last participant. He found this integration intuitive.

Timeline usability
The participants were very enthusiastic about the history in that it enabled easy capture of different states. Having a simple, touch-based visual interface with the ability to negotiate the history of the board was highly appreciated as well.

The participants used the history smoothly for the most part, but sometimes the presence of branches was confusing. As a solution, one designer suggested that sometimes it might be valuable to see the entire branch structure as a traditional graph.

Need for visual comparison and merging
The designers encouraged us to provide facilities for simultaneous comparison and merging of history states. One participant said, “It is very important to view multiple versions in juxtaposition, at the same time and at a scale that we can make sense out of. Much of the impact is visual.”

One designer commented that in his current practice, “When I’m working, I’ll do the information architecture on Post-its, and draw links on the whiteboard. I’ll take snapshots at different points in time. And then I’ll project earlier states onto a wall, and go from there.” This was a current practice uncannily similar to what Outpost and its history support. (The other participants’ practice for dealing with history was not this advanced, possibly because such a practice is difficult with current tools.)

Conclusions and future work
Our design study showed that calm, lightweight history provides substantial value to designers. They were excited about the functionality with the exception of garish interactions like constantly updating history thumbnails, which encouraged us to make the default based on calmer interactions, such as manual bookmarks and infrequent auto-bookmarks.

We plan to integrate informal audio capture techniques into our history system, structuring the audio using board work, and using the timeline as an access interface. We have found that in brainstorming sessions, the discussion among designers often creates information sometimes not expressed in the resulting visual artifact.

Our studies have shown that design teams are very interested in remote collaboration. Many designers we have spoken with either work in a firm with multiple offices or sometimes work with clients who are far away. We are building a synchronous remote collaboration system, and we are studying how a combined physical/electronic collaboration tool like Outpost can be used to facilitate early phase design practices among distributed teams.

1. Everitt, K.M., et al., Two Worlds Apart: Bridging the Gap Between Physical and Virtual Media for Distributed Design Collaboration (PDF). CHI 2003, Human Factors in Computing Systems, CHI Letters, 2003. 5(1).
2. Klemmer, S.R., et al., The Designers’ Outpost: A Tangible Interface for Collaborative Web Site Design (PDF). The 14th Annual ACM Symposium on User Interface Software and Technology: UIST2001, CHI Letters, 2001. 3(2): p. 1–10.
3. Klemmer, S.R., et al., Where Do Web Sites Come From? Capturing and Interacting with Design History (PDF). CHI 2002, Human Factors in Computing Systems, CHI Letters, 2002. 4(1).
4. Newman, M.W. and J.A. Landay. Sitemaps, Storyboards, and Specifications: A Sketch of Web Site Design Practice. Proc. of Designing Interactive Systems: DIS 2000. New York, NY. pp. 263–274, August 17–19, 2000.

Scott Klemmer is a doctoral candidate in the Group for User Interface Research at UC Berkeley. He has an MS in Computer Science from Berkeley, and a dual BA from Brown University: in computer science and art-semiotics.