Old diagram recorded for posterity

David — Mon, 19 Dec 2005 10:43:51 +0000

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

David — Sun, 13 Nov 2005 22:26:02 +0000

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:

Getter Application

The Getter retrieves messages from a number of identified email accounts, web services and file servers and consolidates the information to at a single location with separate RSS feeds for the various information sources. The Getter could be acting for a single project or setup to serve a practice with numerous projects 'on the go' at one time. The principle behind the Getter is that storage and bandwidth are relatively cheap compared to the time required to dynamically harvest resources from around the web. Deployment wise the Getter could be setup to operate on each PC (in order to create local versions of the data-store) or centrally at a single location in order to create a single location where all project data is stored.

Receiver/Indexer Application

The Receiver monitors the file repositories created by the various Getters for each organisation (or person/group within). The Receiver reads the RSS feeds generated by the Getter and on submission of new information the Receiver pulls down the corresponding files and meta data for parsing and submission into the search index by the Index. The creation of the concise search index is required in order to quickly perform rich, sophisticated searches of the project data. The Indexer would create its index using the meta data supplied by the RSS feeds coupled with a full-text index of the submitted file attachments, work-logs and emails.

RSS Search Engine

The RSS enabled Search Engine would interface the search index created by the Receiver/Indexer and provide RSS feeds to any search queries submitted. The use of RSS style search feeds would enable the creation of sophisticated, time sensitive searches by a multitude of clients (from web-based tools to plugins and desktop helper applications). The search results would provide hyperlinks to the information stored in the central repository created by the Getter application. In this sense the original content can be transient but still be referenced over long periods of time. In most deployment situations the three applications would be deployed on a single office server but they could also be deployed on a laptop or spread across three hosted servers located anywhere on the Internet.

Advanced search (Click to enlarge)	Search results (Click to enlarge)
Conversational view (Click to enlarge)	Expanding view (Click to enlarge)
Schedule view (Click to enlarge)	View of related resources (Click to enlarge)

Example User Interface

The focus of this example user interface is to retain a lot of the familiarity of contemporary search engines whilst emphasizing the chronological and conversational nature of architectural design evolution. In the given example as the designer submits daily work-log entries (along with file attachments of their working drawings) and discusses design changes via email a time sensitive model is created that allows the user to browse through the evolution of the project. The user is free to expand out different conversational threads or switch the search view into a gantt chart style view where email and work-logs are tracked against project schedules. As working files are submitted to the system as work-logs are created the user can browse and download a versioned history of files in order to examine the state of design during a particular phase of the project.

stressfree - diagram

Old diagram recorded for posterity

Application Diagrams

Getter Application

Receiver/Indexer Application

RSS Search Engine

Example User Interface