stressfree - thesis meeting

Meeting roundup from the last few weeks

David — Thu, 17 Aug 2006 23:57:23 +0000

Over the last few weeks I have been going over my thesis structure and determining exactly what the nature of my all important second round of testing will be. During this time I've normally met with Mike and Fridays and Henry on Tuesdays. Last Tuesday we had a very interesting meeting between the three of us that went over the entire concept from start to finish.

One of the most important things that came out of the meeting was notion of the Project Information Cloud, a loosely joined collection of resources that could contain a number of Building Information Models and various other resources. The important aspect of this cloud was filtered, intelligent syndication of content between all participants. This filtered, intelligent syndication would achieve the aim of data relevancy that is of utmost importance when dealing with large quantities of data and communications.

During this conversation it became important to clearly define the Project Information Cloud not as a delivery strategy but rather as a model for communication that would operate within a delivery strategy. By doing this it makes selecting specific areas within the building design process to test a lot easier as the emphasis is on testing different types of communication rather than the pro's and con's of different delivery strategies.

To help things out I am now designing what and how the Project Information Cloud could manifest itself. By doing this it (in theory) should make isolating specific testing strategies and environments a lot easier instead of picking a testing strategy and environment and then designing an implementation of the PIC around these constraints.

Attached is a few diagrams that came out of discussing the concept with Henry over the last few weeks. I think as we both seem to think through problems visually diagrams make a lot more sense than words most of the time.

Thesis update & Campfire

David — Wed, 15 Mar 2006 22:35:35 +0000

It has been a while since I last posted, mainly because for the last month and a bit I've been busy preparing and implementing Reasonate within BBSc303. Consequently its been a pretty interesting time. It seems to be working out really well, I've got to grips with Rails (to the point that I cringe at the thought of having to do Java stuff) and almost all of the functionality has been implemented in an easy to use manner. Tagging and RSS have been implemented and introduced to the students whilst the project blogging aspect will come into play once the students form their project teams. Overall the students have picked up the ideas very quickly and some are really getting into the swing of things.

From a meeting perspective at the beginning of February I had a PhD progress meeting with Mike, Henry Skates and Robert Amor. It was very productive and really made me question exactly what I was doing and how I planned on achieving these things. SInce then Mike and I have meet weekly and since the students have started work I've also been giving a short demonstrations within lectures. Meetings with Mike have mainly covered Reasonate specific functionality and concepts. Like any design project once a physical model exists that can be interrogated the level and quality of discussion lifts distinctly.

An interesting software release that came up during the time I was hacking on Reasonate was Campfire from 37 Signals. The software begins to blend together instant messaging and project management and collaboration. It looks really nice and provides a very simple mechanism for the sharing of ideas and files. When tied into Basecamp 37 Signals provide a fairly nice project based collaboration suite.

Versioning and practice-use requirements

David — Thu, 10 Nov 2005 23:18:37 +0000

In previous meetings Mike and I have discussed how the system would operate (along with a lengthy discussion about Google Maps/Earth). One import issue Mike brought up was the role of versioning and how that would play out in the system. I think at this point there is a distinction to draw between the IT/programming concept of 'versioning' and one an architect may hold. In programming versioning is the process of tracking changes from a given point in time based on a set of very clearly defined parameters.

Two common programming versioning systems are CVS and Subversion. I use Subversion on a daily basis with Eclipse (my Java IDE). The process of using a versioning system involves 'committing' code changes to the repository and at defined times (like a software release) creating 'braches' from the main development 'tree'. The versioning system does not keep multiple copies of files it simply tracks the changes to each file and dynamically builds files by adding together all the code changes. Such a system extremely useful, especially when working in groups as different pieces can be worked on simultaneously and then combined. Probably the most important aspect of the entire process is the unobtrusive nature of the versioning process from a developer's perspective. Committing a change is as simple as a right mouse button click yet the consequences are sophisticated and extremely useful.

(Click to enlarge)
Committing a change to Subversion using Eclipse. It is as easy as right click -> Team -> Commit

(Click to enlarge)
Then enter a brief description of what has changed. Browsing to subversion.stress-free.co.nz provides everyone with a look at what has changed.

From an architect's perspective versioning is a little different as the idea is more conceptual in practice and hardly ever grounds itself in a concise piece of 'code' (a single drawing/sketch). Some CAD packages do versioning based on parametric conditions or the notion of time, but as far as versioning across an entire project, manual methods are still the main form of versioning. Online project Intranets are trying to address this issue but because of the buy-in and major working changes required to use a project intranet these services have not gained major acceptance.

For the most part the practical realities of creating a true 'versioned' design model are beyond the reach of all but a few of the most anally retentive architects. In most offices I have been associated with digital versioning typically consists of creating a new file when a major change is about to take place or going back to a backup if a change occurs that cannot be easily 'undone' using the software.

So in my proposed system one of the designers asks the question, 'when was the door moved from A to B and why?' how will this search, and the information related to it, be displayed?
This question is essential to answer but difficult to solve and poses a conceptual versioning dilemma. In in the context of a design project a whole series of design moves could be made in a single 'version' of the design. Two CAD models produced at different times may provide evidence of the elemental shift but it probably would not narrow down the date of when this change occurred or more importantly why. To identify the when and why you would first need to know who made the decision to move the door, what discussions led to this decision and when in the design development stage was this decision implemented and whether subsequent design moves influenced this shift.
When searching for these answers you would probably be asking the following questions and receiving these hypothetical responses:

1. What is the design history of this door?

Whilst not specific you generally begin a broad search and then narrow it down from there. More often than not when using any search engine (be it Google or your local file search tool) your initial search attempt is a test of the water rather than a precisely focused search statement. In the case of the door it is problematic to search within CAD models themselves as doors are typically only represented by a series of lines. In a Building Information Model it could be possible to search within the document to find a specific door instance but achieving this in todays mixed AutoCAD/Revit/ArchiCAD/Microstation environment would be problematic and probably lead to inconsistent results.
So as far as searching for the door's history we would be limited to meta-data tags and written documentation (in the form of notes, briefing documents, etc).

Another avenue for locating information could follow the use of project plans and work diaries. Given enough chronological information about the project as far as when things were done by whom it could be possible to extend the usefulness of any search by identifying useful pieces of information. This brings to question exactly how often data should be entered into the system. Just like in computer software versioning the system is only as good as the data it receives. If you fail to frequently commit your changes to the versioning system your chronological view of the model will be very weak. Hence the versioning process in this system would need to take place as frequently as possible (whenever information is exchanged, important decisions are met or at the close of the business day).

2. When did the move from A to B take place?

If the general search for the history of the door door in question returns a large number of results (from material options to recorded notes on design options sent to the client by the architect) the next phase in the search would be the isolation of when the actual move took place. The most efficient manner to do this would be a narrowing of the search based on the tag 'design decision' (or equivalent as setup within the project). This tag would be applied to any correspondence or work logs submitted that related to instances where specific design decisions were made. The highlighted results viewed against a project timeline would highlight when design decisions related to doors occurred. It would be at this point when the user would use their own intuition based on their personal insights and knowledge of the project to zoom in on a specific time zone within the project where it was thought the door was probably moved (based on the displayed information).
This move is very similar to how we interact with current search engines of all kinds. The greatest difference is that we view and evaluate these results against the chronological project canvas.

3. Who moved the door?

Now that we have narrowed down the time frame as to when the door was moved it is important to understand who were the parties involved in the decision making process. Was this an action performed individually for no reason or did it occur against the backdrop of a number of different but inter-related issues that are important to keep in mind?

4. Why was the door moved?

Understanding this question will require extracting a subset of the conversations and logs placed by the person responsible for moving the door. By examining their activity before and after the activity we would soon identify whether this was a requested planned action, a spur of the moment decision or an action brought on by a chain of events unassociated to the door itself. Situations like this often occur when a design change results in the repositioning of a spacial element which in turn forces the door move (through no fault of its own).

5. Subsequent to this discussion, what other (if any) influences effected the placement of the door?

This investigation of the moving of the door may reveal discussion threads indirectly associated with the door's repositioning. In order to identify this a broad cross section of the conversation would need to be extracted and browsed based on the time frame, participants and project tags associated to the repositioning of the door element.

What would make users buy into this increased data entry requirement?

I believe architects would be willing to invest their time in such an endevour if it was proven that it satisfied a number of their ongoing concerns about working digitally. By itself the system would be useful but the added burden would stunt, if not destroy any chance of widespread adoption. There are a number of small areas where architecture practitioners must pay particular attention to that large software vendors do not properly address. From my experience acting as a consultant in this environment these 'gaps' can be broken into four different groups:
a.) Taking care of the data backup process
b.) Time tracking based on task/project particulars for a specific person
c.) Finding things they or others have worked on in the past
d.) Enable simple sharing between people in their team and other parties

These issues are presently tackled in a number of ways and usually involve customised manual processes that have evolved within each particular office. For example:

a.) Taking care of the data backup process

All companies are deeply concerned about loosing their data. There is the time cost involved in loosing past work but also the prestige and moral hit that takes place when hours of blood sweat and tears suddenly disappear. This is especially important when other parties depend on the data you are providing to undertake work. Just recently I had an experience where an architecture practice lost a few files and they could not be recovered. The flow on effects for this loss where huge. A team of builders could not work, other projects were delayed and office moral took a dive as hundreds of hours of work had to be redone under stressful circumstances.

Probably the most surprising thing however is that architects still do not value their data enough (until it is lost). For many the idea of creating frequent, multiple offsite backups of their work is just too much effort when a single, weekly backup protects them on a week by week basis. If a system like the one proposed were to exist then backups of critical data would occur automatically as changes were logged or information exchanged between groups. Not only this but as more parties joined the project the backup integrity would increase as multiple copies of the same file propagated itself through the network.

b.) Time tracking based on task/project particulars for a specific person

Tracking what time was spent on which tasks by who is crucial for architecture practices. Not only is it required for paying employees but also tracking chargeable hours and assisting in the quoting of new jobs. There are numerous applications available for time tracking, especially for the legal arena but none have been universally adopted by architects (in fact in this field a simple Excel spreadsheet is a popular option). If the system logged time spent on projects as users committed work to the project this information would be silently recorded by the system for later analysis. Not only would it provide immediate benefits in staff and charge out tracking but over the long-term it would provide a resource for comparing past projects to future estimates.

c.) Finding things others have worked on in the past

Information reuse within any office is typically very low. Due to the sheer quantity of information present within a single project it is often easier to reinvent a solution rather than track down past work on a crowded disk archive. As more materials and accepted solutions libraries are put in digital format the architects physical reference library is shrinking yet their capacity to easily find digital information available to them still depends almost entirely on an up to date and comprehensible digital filing system. Desktop search tools like Spotlight and Beagle acknowledge this problem and are attempting to provide general search functionality to desktops around the world. Unfortunately the functionality provided by any of these general search engines fall well below that required in an architecture specific context as no matter how evolved these tools become they will never understand AEC semantics.

If the tool provided this ability to easily search a project or projects information base for a set of constraints old solutions could potentially be rediscovered and utilized on current problems.

d.) Enable simple sharing between people in their team and other parties

Although file sharing has been around since the beginning of computers it is still difficult. Presently project files are exchanged either physically (on CD/USB) or using the Internet (via email). Within an office often the option exists to share files live via the local network but this is problematic in small offices due to the lack of IT knowledge available and various intricacies that still exist in the process itself.

Exchanging files using email or physical means results in a 'frozen' version of the file that does not keep pace with changes made by either party. In this scenario we do not want others to have direct ability to change our files (or even see our in-process version). What we do need to be able easily do is easily notify users of a particular file that it is now considered out of date and for what reasons.

Consider the following example, I email a development drawing to a quantity surveyor and building services engineer for estimation and simulation. The quantity surveyor's feedback results in the design undergoing a series of changes. Once these design changes are finalized a simple mechanism is required to notify the quantity surveyor, building scientist and any other related parties of the design change otherwise there is the potential (as so often happens) that third party work will be completed using outdated data. In computer programming such a concept is known as a 'thread-safe architecture'. Basically it boils down to establishing a common communication layer between all actions so that everyone is always on the same page.

Part of the file sharing process also requires a communication of assumptions, standards and conventions associated with a file. When emailing data, especially to people outside your work group these factors play a crucial role in not only determining what the data is but also play a role in the eventual outputs from this third party. In a conventional AutoCAD file the semantics behind CAD layers and XREF management are vital to understand but more importantly in an estimation or simulation context other users must be aware of assumptions, shortcuts and operating logic associated to the working data. In these scenarios the raw data (an Excel sheet, 3D walkthrough or still image) is only the first clue to the puzzle, understanding the logic behind this data and how it fits into the bigger picture is very (if not more) important.

Late September/Early October Meeting Roundup

David — Tue, 25 Oct 2005 00:27:43 +0000

Over the past month Mike and I have had three meetings that for one reason or another I haven't documented. The weather has been very nice, usage of my Webmin Theme has taken off like a rocket (1,300 downloads and counting) and I bought the complete third and fourth seasons of the West Wing on DVD the other week.

Our meeting on the 20th of September primarily dealt with versioning and the problem of identifying when and how a change takes place. I have a post that is three-quarters written that deals with this subject so I will leave this topic for the time being. The next meeting covered the question of how whatever model come up with can be tested. Whilst the notion of making an interesting piece of software is worthwhile from a technical perspective through the academic lense such a folly is unjustifiable if the end result cannot be soundly analysed through critical testing.

I looked at a number of papers (and Rowan Bailey's thesis) which used different methods for testing a piece of software. Unfortunately the papers were too theorectical whilst Rowan managed to prove his thesis in his opening test that had nothing to do with computer software. This subject followed on to the third meeting which actually ended in the conclusion that I needed to clarify exactly what the problem was before any useful tests could be formulated. This is a pretty good observation given that up to this point and time the potential solution has been identified through the isolation and analysis of a number of separate Architecture, Engineering and Construction Information Technology Communication (AEC ITC) issues:

Problems successful briefing in a dynamic project environment
The unrealistic expectations of 'knowledge management' in the industry
The limited uptake of ITC within the industry
Potential benefits and pitfalls of the Building Information Model

Meeting with Mike 13/9/05

David — Mon, 19 Sep 2005 23:53:06 +0000

Last Tuesday Mike and I met for a discussion on things. I was meaning to put an overview of what we talked about online sooner but it slipped my mind. Actually a far more interesting thing entered it - the home theatre system I bought the next day...

For the most part we discussed how the concept of 'rich and unobstructive' connections could be made a reality. Definitely the 'tagging' concept so well implemented in systems like Flickr would be a real benefit in such a system especially when it comes to the difficult task of categorising resources (text, images and CAD files) for searching. The ability for users to easy tag resources (be it theirs or others) would enable a degree of human searching not present in a contemporary model. Once use instance of this could be the client tagging product fittings they like and then having the architect place style tags next to them (i.e. postmodern, classic). Using these tags you could then pull slices out of the conceptual work such as 'classic, low-cost fittings that we (as in the client and architect) like'. Alternatively in a construction scenario the ability for the contractor to tag documents pertanent to a specific contractor would ease some documentation headaches (if I change this drawing who will be effected?).

A problem highlighted in Mike's thesis is the unreliability of hyperlinks as reference items over a long period of time. Whilst very reliable over a short period of time hyperlinks a prone to break over time with domain changes, site outages and corporate rebranding. Consequently the use of Internet based references for this thesis and arguably for the entire concept, should be backed up by some form of backup document to prove the initial hyperlinks existence. In the case of my thesis this will be achieved by saving Internet based resources as PDF. In the case of the sharing concept as a whole the problem is a little more complex and I will go into that a little later. Mike brought up the existence of the Wayback Machine. Not only do they run this archive on some fairly serious hardware (http://www.archive.org/web/hardware.php) but they also keep a fairly comprehensive archive of the web going back over seven years. I have just entered my site into the WayBack machine's web crawler so hopefully in the future copies of this site will be around for posterity and to cringe at.

Our last topic of discussion was how this concept could be tested. The major problem with a quality test (is my thing better than the conventional process?) is that it is almost impossible to test or prove conclusively. In theory a quality test such as this could be run on hundreds of real world projects and the results, in the form of questionnaires and evaluation forms, compared and summarized. Unfortunately such a test is not practical and anything similar performed on a small scale would not provide conclusive evidence.

A case study approach could be a better strategy as it substitutes depth for breath. In this form of testing a few projects could be evaluated extensively using interviews, discussion groups and observation to determine the impact (if any) of the proposed system. In order to prove the feasibility of the system the scalability of the concept would need to be proven. To prove this the system could be tested in mockup small and large practice environments and testing how it performs under a variety of conditions. The common belief is that something that can be 'scaled up' is successful but I think the reverse principle should be used for this test. I have found in practice that anything can be 'scaled up' given enough investment in resources, support and training. The real test of a system is how it can 'scale down' into low resource environments such as that of a New Zealand architecture practice and then be scaled back up into a full scale enterprise environment (100+ users from many different companies participating).

The other test of how successful the concept will be is in how robustly it performs during failure of part of the network. This idea touches on the problems Mike has experienced with Internet based references no longer being accessible on the Internet for one reason or another. In practice this same problem will be faced by users of the system, especially in environments where multiple organisations are sharing information. In this scenario it would not be unreasonable to suggest that at least once during the development process one of the companies would temporarily (or permanently) drop out of the information network for technical or business reasons. When this circumstance arises the system must still be able to provide the information submitted by this party else the integrity of the system as a whole would be severely compromised. No user wants to be told to 'come back tomorrow' if time critical information is not available when they need it and likewise a project's information should not be held to ransom by the threat of one business failing to live up to their service agreement. Consequently the system must use caching not only to ensure robustness of service but also to aid in boosting the overall user experience through speedy service, especially when large data files are involved. There is an interesting speech by Justin Chapweske of Onion Networks available at IT Conversations that deals with this subject (http://www.itconversations.com/shows/detail462.html).
The complete Onion Networks SDK costs US$25,000 which puts it out of reach for this application but definitely the concepts (and the Public Edition) are very useful to keep in mind.