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.
Field and design studies
Before building this history system, we conducted and learned from field and design studies. Newman and Landay  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.” 
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.
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.
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).
Thumbnails not only display information about the state changes of the board, they also provide a direct-manipulation interface for navigating the design history.
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.
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.
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.
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.
During the course of development, six professional designers used the history system and offered us their feedback (see Figure 10).
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.
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.
- 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).
- 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.
- 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).
- 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.