In this paper, the authors expanded the functionality of Designers’ Outpost, a system designed for web development using a whiteboard, post it notes, and cameras. With their improvements on the system, they capture the design history amongst collaborators located in the same physical space. Their system has three main mechanisms: 1) a main timeline, 2) a local timeline, and 3) a synopsis view. They validate their system with four use cases that follow the trajectory of a group using the system in a realistic way. Overall, their work was promising and productive, especially considering when it was conducted, in 2002.
A deeper understanding of the present is formed from a good grasp on the past is their main motivation. For web designers it is really useful for looking at design history. However, the project or concept also has a lot of potential to be used for other domains or have a similar implementation for another system used by people in a different field. This system allows users to have a detailed understanding of their history with multiple layers. The notion of branched histories also preserves all user actions which is lost in many history and information capture systems. Comparing different states side by side and lacking the ability to merge different states, using all visuals (not using the other senses), and bookmarking being manual are the main cons to this system. If the system could take into account audio, I believe that it would dramatically help during the creative and reflection process. This paper does not measure creativity, but it is integral and supportive of the creative process in the design phase for a final product.
This paper is similar to Apple’s time machine or a version control. For my project, I am not collaborating, so this system might not be as pertinent to use. Additionally, my project is not in the brainstorming stage or needs much use for post it notes. A common coding version control that is well documented could be extremely useful for my project however. This paper does provide insight into how such a system could be improved. Many times, people write small commit messages because they are in a rush to push or do not want to articulate it via typed words. For instance, it could be interesting if Github allowed commit messages to be supported via audio. This could allow for clearer and more detailed accounts of changes a user made. In turn, clearer recall could allow for more effective collaboration with self and others. Overall, this was an excellent read.