Old diagram recorded for posterity

A while back (like two months ago) Mike and I were discussing what the project was about. Initially I talked about a 'time capsule for project thinking' but then it moved on to 'stream of conscious' and from there to the metaphor of a river and navigating against the current (sometimes without a paddle). This metaphor crystalised into a fairly tidy little diagram that describes a number of the ideas at play.

Essentially the diagram maps the quantity of decisions against time. The majority of design and development decisions occur in the first half of a project. Once construction begins onsite  decisions must be made but for the most part the impact of these are not as significant as what has gone before. The diagram takes a simplistic view of the design/construction process, breaking it into four stages for clarity. In actual fact its very rare to find such distinctions along a timeline but for clarity's sake it has been shown this way to illustrate the different transition periods. As the project shifts between phases a 'firewall' is erected that typically filters the quantity of information passed through to the next phase. This filter manifests itself as a project milestone that is typically clearly defined and used as a yardstick for assessing payment, progress and success. For example, the briefing phase generates a concise brief, from conceptual design comes a proposal and the outcome of design development is construction documentation and formal consents. Most (if not all) of the background work related to these final documents are archived, lost or deleted. Also as a project shifts phases the participants and 'key figures' change (even internally within an architecture practice), resulting in further knowledge leakage. The emphasis of this research is to provide a digital means of moving back through project time, peering through the internal firewalls to examine past decisions and conversations in order to better understand the project's evolution and resolve its present issues.

Application Diagrams

Workflow Outline
Click to enlarge

Ignoring front-end clients which could come in a multitude of formats (from web browser to CAD plugin) the backend application would be divided into three major backend pieces.  These pieces of functionality are divided in order to maximize deployment flexibility in a multitude of environments. The system uses two accepted methods of data transfer on the Internet: email and file transfer via a server (FTP/HTTP). By using a standard, non-proprietary means of data submission a multitude of clients can be supported or built using existing technologies. The three back-end components to the application are: