stressfree - collaborative design

Be2camp presentation on architectural micro-blogging

David — Fri, 15 May 2009 10:34:24 +0000

Below is the slide presentation I will (hopefully) present at tonight's Be2camp North un-conference. Basically the presentation graphically summarises my recent blog post on the use of micro-blogging within architectural collaboration.

The conference is in Liverpool and I am in New Zealand, so if the technology gods are not in a good mood things may go pear shaped very quickly...

Using micro-blogging to record architectural design conversation alongside the BIM

David — Mon, 11 May 2009 10:16:00 +0000

The majority of professionals within the architecture, engineering and construction (AEC) industry use the telephone and email to collaborate on immediate design problems. Unfortunately there is a disconnection between this communication and the underlying Building Information Model (BIM) where the agreed upon architectural solution is recorded. As a consequence it is difficult for a person interacting solely with the BIM to take part or learn from this external conversation because they are often oblivious to it taking place. Micro-blogging is an emerging, Internet-based communication medium that may provide the common thread to tie these disparate sources of project information together. It will achieve this through enabling the issues and outcomes discussed during architectural conversations to be quickly recorded by any member of the project team. Those working on the BIM will be able to actively monitor and search across these conversations to keep up to date with the project’s state and help solve new design problems.

Unlike blogging and instant messaging, micro-blogging can communicate simple messages between groups of people using mobile phones or any Internet connected device. These conversations are published online so they can be referenced in further design discussion, or indexed for searching alongside other sources of project information. For adoption to occur the technology must be integrated within the BIM toolset so that being part of this conversation is a natural extension of the digital workspace. Current micro-blogging services such as Twitter, lack this integration and have not (yet) been tailored to meet the specific demands of architectural collaboration. A focused implementation would likely improve architectural collaboration because micro-blogging embodies many of the principles of the Project Information Cloud. Its qualities of simplicity, ubiquity, decentralisation, modularity, awareness, context sensitivity and evolving semantics make it a promising collaboration medium, and one that could move the AEC industry towards the goal of hyperlinked practice.

What is micro-blogging?

Micro-blogging is an emerging Internet-based communication medium that could significantly improve the timeliness and accessibility of architectural collaboration discussion. Made popular by the Twitter web service, conceptually it is a combination of some of the best features of email, text messaging (SMS), blogging, and instant messaging (IM). The result has the flexibility of email, the ubiquity of SMS and the immediacy of IM, whilst its content can be browsed, referenced or indexed like a traditiona blog. Through this “best of bread” combination, micro-blogging creates a text-based communication platform that can be accessed by any network connected device. The technology has proven adept at conveying news and discussion amongst clusters of individuals who share common interests, for example debating the 2008 US election. Currently adoption is centered around public sites such as Twitter and Tumblr, but efforts are underway to inject the technology into business through initiatives such as Yammer.

At a practical level, micro-blogging is the publishing of a short text message to an Internet service responsible for notifying other users and publishing the message on the Web. The concise nature of these messages (~140 characters) allows them to be produced and consumed by almost any device connected to a cellular network or the Internet. This means taking part in design discussion is not limited to a specific device or context, and as such collaborators are free to participate at a time and place of their choosing. Whilst reaching a broad audience is important, the technology also attempts to solve the communication overload which plagues contemporary communication tools. Ironically this overload stems from their primary benefit; the immediate, unfiltered and low-cost access the telephone, facsimile and email provide. The underlying issue with these tools being the assumption that a recipient is either interested in, or the most relevant receiver of the message, question or data conveyed. For decision making within large groups this becomes unwieldy as it relies on everyone maintains a strong understanding of the team’s dynamic and knowledge distribution. In contrast micro-blogging encourages participants to explicitly state their interests by 'subscribing' to other’s accounts, or ‘tracking’ keywords as they are published. This enables collaborators to control the quantity and type of information received, and as a consequence indicates to others who and what the person is interested in.

i.e. I am interested in receiving messages from these people, and monitoring conversations taking part within the broader group around these topics.

How can micro-blogging improve architectural collaboration?

An evolved, AEC-specific micro-blogging platform could in the long-term prove as influential to architectural collaboration as the facsimile or email. The technology will not replace other communication tools, in fact for direct or complex interactions the telephone and email will always be the preferred tool of choice. Instead micro-blogging will form a digital conversation layer around the BIM where collaboration issues and outcomes can be monitored and discussed by the entire project team. This will benefit architectural collaboration by improving the timeliness and accessibility of information related to project decisions and current issues. From the point of view of the building life-cycle, micro-blog content will help preserve a history of the design and construction process, supporting what is recorded within the BIM.

Conventional collaboration tools assume the conversation initiator knows who should take part, and that those selected can participate at that time using the chosen medium. For example teleconferences are limited to those invited on the call at that time, whilst email involves only those explicitly included, or carbon copied, into the conversation. The collaboration exchanges in both cases are self contained, with outcomes requiring manual dissemination throughout the project team. In comparison recipients of micro-blog messages are not explicitly defined, instead they are inferred through a social networking and search-based syndication process. A recipient may have expressed an interest in receiving some (or all) of the author’s messages, or alternatively may have configured real-time searches for particular keywords. Relevant messages can be delivered to almost any network connected digital device, allowing a team member to monitor or participate in design conversation from any location.

Beyond exposing internal conversations to the broader design team, an added architectural collaboration benefit is that micro-blogging produces HTML artifacts. Each message generates a corresponding HTML document that has a unique address (URI), links to further information, the author’s details and the date of publication. These documents become part of the project’s knowledge base, and can be browsed, referenced or indexed using existing web browsers and search engines. From the collaboration perspective this is important because it enables knowledge reuse, and new members can familiarise themselves with the project’s design history. This is significant improvement over contemporary communication tools whose content cannot be easily referenced by, or stored alongside, other project data such as the BIM.

The following hypothetical scenario illustrates how micro-blogging could be used in practice to improve architectural collaboration. This scenario illustrates nine pieces of functionality that a dedicated AEC micro-blogging platform should enable in order to best satisfy a team’s collaboration needs:

Seamless Integration with BIM applications.
Rich searching of project content.
Hyperlinking to supporting digital media.
Significance derived through identity and meta-data.
Prompting for micro-blog entries on key events.
Monitoring of content for important events or topics.
Publishing to shared messaging channels.
Delivery of messages to a preferred device.
Integration with digital cameras and GPS devices.

"Kelly was helping John, one of the Practice's directors make design alterations to a large office development in order for it to meet the client’s requirements. Prior to an element being modified in the Building Information Model (BIM) the program would list relevant design discussion drawn from the project team's micro-blogs. This worked by Kelly selecting part of the model and asking the search tool to find micro-blogs that had linked to, or included tags relating to, this particular area of the building. Kelly had ordered this information by significance, so in this case content published by her direct supervisors was listed above that of others such as the quantity surveyor. Whilst most of this was unimportant, Kelly often came across micro-blogs published during the briefing process or on-site that highlighted issues she was unaware of. In this instance there were no obvious problems, so Kelly repositioned the wall element within the BIM and saved the changes. As the application registered this as a significant change she was prompted to record a micro-blog entry explaining what she had done and why. Kelly dutifully entered that she moved the wall to satisfy the client, and supported her claim with a link to the change request within the project's document repository. She described the change and her message was automatically tagged "#change-alert" so that everyone who mattered within the project would receive the update.

John meanwhile was running late to the project’s weekly site meeting. His cellphone beeped with the arrival of Kelly's SMS micro-blog message, that let him know the design change had been made and the updated plans were available. As usual the 'idealised' design process had gone out the door months ago, and now the client wanted the internal wall moved only after its construction had begun. Arriving onsite he found the foreman had also received the message and had downloaded the updated plans to his laptop. However on inspecting what was already built they soon came to the conclusion the change would not work due to the existence of a heating pipe that was not in Kelly’s BIM. Needing a compromise, John used his smart-phone to take photographs of the problem, which he posted to his micro-blog along with a few ideas Kelly could explore. At this point Richard, the building services engineer chimed in with a micro-blog that the pipe was a late addition by the client, and that clear access to it was very important. Richard had moved on to a new job, but he had kept tracking the project for any messages about services just in case a problem like this were to occur. John and the foreman had a brief teleconference with Richard to discuss alternatives. Prior to leaving the site John used his cellphone to post a micro-blog stating he had discussed the problem with Richard and requested an up to date services model for Kelly. He would not get back to the office for a while, but by then he hoped Kelly would have at least received and digested the revised services layout from Richard.”

Micro-blogging within the Project Information Cloud

Successful architectural collaboration involves understanding the decisions, compromises and assumptions which occurred during the creation of the built form and its digital representations. The Project Information Cloud is an Internet-centric knowledge network formed around a BIM in order to improve collaboration and data capture within distributed projects. It is the loosely coupled, digital space where these exchanges and associated data can be recorded, shared and referenced to each other or relevant project information. There is a need for such a construct because BIM’s centralised and controlling nature cannot adequately record or properly represent these unstructured data streams. Whereas Intranets consolidate ownership and control, a Project Information Cloud’s goal is to enable seamless collaboration across organisational and contextual borders. Given this ambition the Project Information Cloud is not a single technology, but a set of principles that can be applied to the development of architectural collaboration tools. Tools that embody these principles will improve the timeliness and accessibility of relevant project information, and in the long-term enable the goal of Hyperlinked Practice.

The seven principles of the Project Information Cloud are:

Simple - The collaboration technology is easily to understand and capable of being used by the widest audience, for example architects, clients and contractors. This simplicity should extend beyond that of the user interface into the collaboration metaphors and technical architecture employed. Collaboration is most effective when participants comprehend how their tools help facilitate and empower their role within the project team.
Ubiquitous - The collaboration technology should be readily available and cost-effective to use in a variety of contexts, from design office to construction site. The concept of ubiquity should extend beyond the prevalence of the physical device or software tool to the ability of a broad number people to utilise it. Simple software that is well understood and available to all is ultimately a more powerful collaboration tool than complex tools which only a limited number of participants can understand or access.
Decentralised - Contributed collaboration data should not be dependent on a single, centralised system for its continued existence or be 'owned' by a single party. On leaving a team participants should be able to easily make digital copies of the design conversation they have participated in. Whilst productive within a closed environment, centralised collaboration structures promote control and restrict conversation, which in a distributed team leads to friction and confusion.
Modular - It should be possible to add or remove functionality from collaboration end points, i.e. the software participants use to interact with each other, without breaking the compatibility or reliability of the overall communication system. Likewise participants should not be forced to use specific software in order to take part in digital conversations. Similar to how any certified telephone can be used to make phone calls, successful digital collaboration should emphasise interoperability.
Information Aware - Collaboration systems should assume that they are part of a larger ecosystem and strive to integrate with this environment as much as possible. Integration should include the ability for the tools themselves to automatically seek out and classify relevant digital information from sources within the team and externally. In modern, attention starved workplaces, the more independently a digital tool can operate within a collaboration ecosystem, the more valuable it becomes to the end-user.
Context Sensitive - Information should be presented in a manner that is relevant to the collaboration situation and people consuming it. The sheer quantity of digital data in an architectural project can confuse or overwhelm design conversation if not managed properly. To compensate digital collaboration tools should strive to act as intelligent information brokers to ensure design conversation between participants remains coherent and distinct from a project’s background noise.
Evolving Semantics - Collaboration data should be unbounded by a rigid structure so that those taking part are free to convey any architectural concept. Contemporary collaboration tools such as BIM employ rich, but rigid, semantic models which ultimately prove less versatile than tools which communicate simple, unstructured data. Highly structured data formats cause a great deal of collaboration friction if the consuming tools are not fully compatible, or the concepts conveyed are not comprehensively supported.

If a digital collaboration tool fails to satisfy one or more of these principles the likelihood of it playing a productive role within the Project Information Cloud is reduced. This argument is supported by the limited adoption prior digital architectural collaboration initiatives that have failed to satisfy many of the principles outlined. Consequently these tools have imposed high technical barriers to entry, or have exhibited collaboration shortcomings when deployed within distributed project teams. For example BIM is unquestionably a very powerful architectural productivity tool, but for enabling collaboration within a project team it is weak in many of the described areas. As a result project teams have turned to simpler, more ubiquitous technologies such as PDF, DWF and email to exchange data about a BIM within the project team.

Micro-blogging embodies many of the principles of the Project Information Cloud and therefore stands to become a productive architectural collaboration platform. This is in part because it has evolved as a response to the complexities witnessed in the first wave of Internet-based communication and collaboration initiatives. Whilst simplicity and ubiquity are key factors in its initial success, its ability to satisfy the other principles of the Project Information Cloud are growing with time.

Simple

Publishing 140 character plain text messages is simple to implement, and premise that a person “follows” others or “tracks” ideas is easily understood by a broad audience. With this conceptual foundation in place users and developers have been free to utilise and expand on the concept in a multitude of ways. For example the prevalent use of hyperlinking within micro-blog content has enabled a variety referencing and multimedia capabilities not present in the original implementation. Here rather than introducing complexity to solve new problems, the application of another simple concept, the hyperlink, has enabled sophisticated outcomes. Further examples in simplicity can be found in the evolutionary use of characters such as @ and # to represent reply and topic fields within micro-blogs. Whereas many technologies have added complexity to enable such functionality, recording this information within the message has ensured micro-blogging remained simple.

Ubiquitous

The simple conceptual and technical characteristics of micro-blogging enables its content to be produced or consumed on almost any network connected digital device. This platform ubiquity ensures micro-blogging is accessible to the broadest possible audience in terms of technical ability, network availability or workplace context. From a collaboration perspective this is important because it gives all potential participants the opportunity to passively monitor or actively take part in project discussion. At a technical level micro-blogging has also leveraged ubiquitous communication protocols such as HTML, RSS and XMPP to output a user’s message stream. This has enabled the rapid growth of a broad micro-blogging ecosystem, complete with external services that consume and add value to the underlying data. For example conventional search engines can crawl a micro-blog’s HTML content, whilst newer ‘live‘ search and trend services can monitor XMPP output in near real-time. The benefit of this ubiquity is two fold; the service can integrate with existing infrastructure, and developers can efficiently add functionality using well understood technologies.

Decentralised

Whilst the decentralisation of micro-blogging is in its preliminary stages, if successful it will enable greater levels of scalability, privacy and flexibility. Twitter is currently the most popular micro-blogging implementation, but due to its centralised nature, it is also notorious for its unreliability due in large part to scalability issues. In response decentralisation and cross-platform interoperability are paramount objectives for “second generation” micro-blogging platforms such as Laconica.

"The model I am trying to follow is email. You have different servers that have different domains... But they are all interconnected, and as long as they are speaking the same simple protocol they work pretty well.”

Evan Prodromou, Developer of Laconica, FLOSS Weekly, Episode 37

Initiatives such as this have led to the OpenMicroBlogging specification, which along with OAuth and YADIS establish protocols for the discovery and creation of micro-blogs. Whilst at this time it is unlikely Twitter will adopt all of these standards, their existence will ensure competition and interoperability will be strong within the micro-blogging market.

Modular

The concept and technologies behind micro-blogging are relatively simple and as a consequence the number of implementations of different types is steadily growing. Besides Twitter other examples of independently produced micro-blogging platforms include Jaiku, Laconica, Tumblr, Yammer and FriendFeed. Whilst at this time interoperability between these disparate systems is inconsistent, standards like OpenMicroBlogging, OAuth and YADIS are beginning to enable it. Micro-blogging has also demonstrated its modularity through the rapid and diverse growth of the client software which interacts with the service. Through hyperlinks and semantic syntax (@ and #) developers have been able to add new layers of functionality onto micro-blogging without breaking backwards compatibility. The first and most prevalent of these is the widespread use of URL shortening services such as TinyURL to make long hyperlinks micro-blog friendly (i.e. < 20 characters). Beyond simple URLs, micro-blogging specific photo sharing sites such as TwitPic make it easy for client software to upload and display images within standard messages. From an architectural collaboration perspective this is powerful as the majority of design problems are visual in nature, making communication using only 140 characters difficult.

Information Aware

The most powerful property of micro-blogging is its emphasis on live, customised data streams that are generated based on user lists (follow) and keywords (track). As a result micro-blogging clients are inherently information aware because their purpose is to monitor and clearly display an ever changing conversation space. However evolutionary improvements still need to be made to these interfaces to better manage the continual flow of data and minimise the risk of information overload. Beyond consumption, micro-blogs expose data as HTML, RSS and XMPP streams so that other information aware tools can collect, present and act on this information. For example Yahoo Pipes can aggregate multiple micro-blogs, perform complex operations on the data, (filter, manipulate, etc.) and output the result as a new RSS feed. Finally the simple and ubiquitous nature of micro-blogging is helping it become a medium for third-party applications to publish messages such as event notifications. An early but unique example of this is Tweet-a-Watt, an Internet connected electricity monitor that automatically publishes a building’s daily power consumption to Twitter.

Context Sensitive

The growing use of @ and # characters to identify people and topics is allowing more contextual information beyond creation time to be recorded within a micro-blog message. Emphasis has now shifted to the development of intelligent clients and services that can interrogate and represent these contextual nuances to users in more meaningful ways. For example micro-blog streams are unthreaded, but many clients can recreate message threads through the weaving relevant person, topic and creation time meta-data. Whilst still in its early stages, services like FriendFriend use such techniques to facilitate “real-time conversation”, loosely threaded discussions derived from micro-blog content. Beyond real-time conversation is the eventual integration of micro-blogging content with other digital activities such as the creation of a shared document or digital model. Although no concrete examples have yet to emerge, it is only a matter of time before micro-blogging is integrated within applications such as these to create powerful results.

Evolving Semantics

Micro-blogging has no predefined semantic structure, but the recording of meta-data within a message via hash tags has occurred through a process of community acceptance. Initially these tags have been used to aid in search and to identify semantic trends within micro-blogging communities, for example the hashtags.org service for Twitter. Whilst hash tags have given micro-blogging a flexible semantic mechanism, the drawback is that including tags within a message reduces the space available for content. A consequence of this trade-off is that micro-blogs form shallow, but broad semantic structures with only a limited number of explicit relationships formed between tags. For example a micro-blog message on CAD may apply the explicit tag #revit or #microstation, but the more generic #cad tag may be omitted for the purposes of brevity. This reduces the navigability of the semantic structure because many of the required higher-level links between terms and associated content is omitted. To counter this shortcoming “micro-blog thesauruses” may emerge to allow people to browse micro-blog semantic trees using implicit (rather than explicit) relationships.

Why the AEC Industry needs a dedicated platform

Micro-blogging adheres to the Project Information Cloud’s principles, but consumer micro-blogging services do not satisfy the AEC industry’s operational requirements. Although a consumer service such as Twitter could theoretically be used by a project team, adoption would be mixed and the outcome unsatisfactory. For broad adoption an AEC-specific micro-blogging solution must integrate with existing workflows, respect the team hierarchy, store information securely and operate reliably within distributed environments.

BIM/CAD integration

AEC professionals spend a good portion of their workday interacting with BIM and CAD models. If micro-blogging is to gain acceptance in this field it needs to seamlessly integrate with the tools used to interact with these models and the accompanying workflows. Given this emphasis, to be of most value in the collaboration process micro-blog content needs to be presented alongside the source material. For example displaying and searching for relevant micro-blog content within the BIM or CAD model viewers and editors is an important integration point. Likewise to preserve the workflow, functionality should be provided to create micro-blog messages from within the BIM and CAD applications themselves. This should include the prompting for updates on significant events, and the ability to create and link to screen captures or 3D models when composing a message.

Comprehension of the project team hierarchy

Unlike consumer micro-blogging services a system targeted at AEC professionals needs to comprehend and respect the hierarchical nature of project teams. Rather than placing the onus on the user to manually identify and create these relationships the basic network should be maintained within a project template. Managers would create this template using a tool that lets them map the working and security relationships between project participants. By maintaining this hierarchy it allows the people and topics followed by a user to be automatically updated as the composition of the project team changes. This would save people time by keeping them informed of developments, and in the process expose them to new sources of information within the team.

Context-level security

The AEC industry is a litigious environment and as a consequence any micro-blogging solution used within it must be capable of restricting access to published content. Currently the security options offered by Twitter, or even the business-centric Yammer, are limited in that content can only be restricted at a user-level. For example whilst it is possible to mark a message stream as private, once another user is granted read access they can read every piece of content published by this account. However project teams are distributed and dynamic, so a finer grained, context-level access control system is required that filters access to specific parts of a message stream. For example an external consultant joining a micro-blog conversation should only be able to view messages posted by team members relating to that specific project. Additionally it may be necessary for the project administrators to filter access to users based on specific topics or periods of time. This would enable the consultant’s access to be limited further to messages published between a defined period of time about specific aspects of the design. From a practical perspective this context-level security would be applied at the micro-blog servers as this would allow the client software to operate unchanged.

Decentralised implementation

Architecture projects are temporary collaborations between multiple organisations so it cannot be assumed that all parties will be using the same micro-blogging system. For an AEC-specific implementation to be successful it needs to allow participants to seamlessly collaborate whilst using different micro-blogging services. As discussed earlier this is an important principle of the Project Information Cloud and a primary goal of second-generation micro-blogging platforms. To consistently apply the project hierarchy and context-level security settings across micro-blogging services the relevant information would need to be exchanged. In theory an AEC micro-blog system could operate without this data transfer, but if it were to occur the benefit to the end-user experience would be considerable.

Digital collaboration-fact, not fiction

Although the architectural collaboration example and AEC specific requirements may seem far fetched, much of the functionality highlighted already exists. Therefore implementing a working, AEC-specific micro-blogging collaboration system is more a case of putting the right pieces together than inventing a new wheel. The following examples illustrate how these functional characteristics exist today, and hint at how an AEC-specific implementation may operate in the future.

1. Seamless Integration with BIM applications

There are many standalone desktop micro-blogging applications (for example Thwirl and Spaz), but some developers are taking the concept further by integrating into the desktop itself. MoodBlast and Twitterific are two examples where the line between micro-blogging and traditional desktop functionality is blurred.

The desktop integration of MoodBlast and Twitterific (click to enlarge)

For example when browsing the Web, pressing a hot-key combination will display a MoodBlast message window and pre-fill it with the browser's current URL. When the message is submitted the URL is automatically shortened and the result posted to a variety of micro-blogging systems. Likewise Twitterific regularly displays new content published to your social network so that you can be updated of events while working. Mechanisms such as these could easily be included within BIM applications to allow users to publish and consume micro-blogging content alongside project model data.

2. Rich searching of project content

Building search indexes from micro-blog messages is technically relatively simple given the problem of searching Web content has existed for some time. Unfortunately the message size restrictions limits the quantity of meta-data that can be associated, and as a consequence it is unlikely search relevancy can be improved. However Twitter Search has been able to include unique search parameters such as ‘attitude’, which is made possible by micro-blogging’s real-time, conversational nature. Yet to be fully exploited is the search potential derived from the social network formed through micro-blogging’s acts of following and being followed by others. In a distributed team the ability to ask, “who do I know that may know the answer to this question?” is in many ways more useful than “what is the answer to this question?”

3. Hyperlinking to supporting digital media

Given the limited payload size for a micro-blog message it is very common to include a hyperlinks to external Internet resources. This capability and the resulting obfuscation caused by URL shortening leads to the crafting of messages which succinctly convey what is important about the included link. For example, “The revised ground floor plan showing the realigned internal wall (PDF): http://aecurl.com/GEDJ32”. From a comprehension and search standpoint this is an efficient process as it encourages resources to be described rather than having them exist as anonymous files. Currently for internal documents this process is not as simple as it should be, but services like TwitDoc hint at how this process can be made easier for AEC professionals.

4. Significance derived through identity and meta-data

Unlike the majority of conventional Web content, the current assumption with a micro-blog is that like email it is published by a specific person. This provides a strong mechanism for identifying reliable information as the source and recipients of the message can easily be identified. Likewise by constructing a map of references between micro-blogs and hyerlinked URLs it is possible to quickly identify significant project events and resources. This technique, known as PageRank, is common in search engines, but in a real-time micro-blogging environment it can be used to identify emerging 'flash points'. Two services that demonstrate this functionality are Twitterurls and Twitlinks, both of which monitor and display popular trends, media and hyperlinks published to Twitter.

5. Prompting for micro-blog entries on key events

Like a traditional diary, a micro-blog gains more value as a historical record of events the more frequently it is used. Integrating the technology into productivity tools such as BIM will assist in this adoption process, but to foster regular submissions the tool should proactively seek input. A basic example of a proactive micro-blogging mechanism is the Yammer Time Firefox plug-in for the Yammer service. However whilst a time-based approach would meet with some success, a mechanism activated on key events would be more efficient and less obtrusive. For example saving a BIM after changing identified elements, or crossing an overall model change threshold, could trigger a request for a micro-blog justification.

6. Monitoring of content for important events or topics

Micro-blogs are time-sensitive records and one of their most important characteristics is their ability to display the “real-time” status of a distributed discussion. The most powerful demonstration of this has been Twitter’s trending and tracking functions which allow users to easy monitor events or topics within the broader community. TweetDeck provides a dashboard-like interface where a subset of this dynamic information can be easily monitored and acted upon.

The TweetDeck personalised dashboard (click to enlarge)

Such functionality would be useful to a project manager wishing to keep on top of issues as they could monitor the project stream for trends and specific “problem” keywords. If successful in some situations this may see a shift from reactive to proactive decision making based on issues detected at an early stage of development.

7. Publishing to shared messaging channels

A significant portion of architectural collaboration micro-blog content would not be targeted at a specific person, but instead concern a particular topic. Applying of hash tags to messages would ensure the content was received by relevant people via micro-blogging’s tracking mechanism. The role of a dedicated AEC service would be to make using and tracking these hash tags as simple and automated as possible. One example could be the syndication of project hash tags to desktop clients so that instead of working from memory participants could choose “messaging channels” from a list. This way a team member could follow the project’s conceptual design (#concept) and development (#devel) channels without having to remember the correct hash tag(s) to use.

8. Delivery of messages to a preferred device

The design of micro-blogging services and their ~140 character limitation is to ensure they can be delivered to any network connected device. From an AEC collaboration perspective this characteristic is important because it cannot be assumed project team members will have Internet connectivity. Whilst adoption of Internet-capable smart-phones is growing, the majority of the workforce still uses “traditional” cellular devices and desktops with fixed Internet connections. As a consequence the ability to deliver or publish important micro-blog notifications via SMS is a significant capability should a design problem be identified.

9. Integration with digital cameras and GPS devices

Camera and GPS equipped smart-phones such as the iPhone and Blackberry are pushing the boundaries of micro-blogging client applications. Software like Tweetie and TweetGenius make it simple for photos taken using a smart-phone to be uploaded to a micro-blog along with accompanying GPS data. From an AEC perspective this capability is very useful during construction as the process shortens the feedback loop between the site and office. For example onsite progress or problems are typically recorded using a digital camera, and the resulting images are emailed or physically taken back to the office. Either process takes time and there is no guarantee that the images will make their way into the project’s knowledge base or distributed throughout the team. In contrast a micro-blogging application on a smart-phone can upload a photo and instantly include a reference to it within the project’s message stream.

Conclusion

A correctly implemented, AEC-specific micro-blogging implementation could become a powerful and valuable architectural collaboration mechanism. Success hinges on the service embracing the principles of the Project Information Cloud and respecting the workflows and operational requirements of AEC professionals. Implementing the service would not be a simple task, but the functional groundwork has already been laid in the broader micro-blogging ecosystem.

Making digital collaboration "more betterer"

David — Mon, 20 Oct 2008 09:36:40 +0000

Recently I gave a presentation at Victoria University on the work I am doing with my PhD. For posterity I have uploaded this presentation to Slideshare.

View presentation. (tags: construction design)

The talk covered the problem of digital architectural collaboration and how it is an immature field compared to other aspects of architecture. Due to the pressing nature of architectural collaboration the solutions to this problem will not be revolutionary, e.g. Second Life-like, but rather evolutionary, and at times even haphazard.

After introducing the problem-space I went on to discuss the emergence of the Building Information Model (BIM) as a central figure in digital architectural collaboration. However whilst BIM is an excellent productivity tool it does not address many of the industry's collaboration issues - in fact in many respects it compounds them.

WIth BIM identified as a significant yet problematic collaboration technology I outlined the need for an overriding set of digital collaboration principles that can be applied to future collaboration technology decisions. Rather than starting from zero I propose that we build on top of the underlying theories of distributed systems such as the Internet. With this need and methodology identified, I go on to introduce the seven principles of the Project Information Cloud:

Simplicity
Ubiquity
Decentralisation
Modular design
Information awareness
Context sensitivity
Evolutionary semantics

Through application of these principles it is hoped we can establish Project Information Clouds within architectural projects. These unbounded information clouds will link significant amounts of projects data into intelligent, loosely joined, knowledge-bases.

Internet enabling Generative Components for a new breed of AEC consultant

David — Mon, 11 Jun 2007 05:40:33 +0000

Generative Components, also known as Smart Geometry, is a technology for describing the underlying rule-set of a geometric form. Currently it is in its infancy but potential exists for it to become the basis of a new field of AEC consultancy centered around geometric exploration. Central to its success will be the ability for its proponents to utilise the Internet to improve its technical accessibility and enable consultants to deliver the benefits of Generative Components to any interested architecture practice no matter its size or geographic location.

Even though it is smarter, BIM is still dumb

Typical CAD or BIM modeling tools are relatively simple in nature because all the major design elements are systematically defined by the architect or drafts-person building the model. Unfortunately this process depends on the person creating the model having at least some idea of the intended outcome before undertaking the work. Also once the model is built the underlying geometric motivations behind it cannot be efficiently experimented with. Generative Components empowers the designer with the ability to almost effortlessly explore many different yet related iterations of the same concept in order to determine the strongest architectural response to the given situation.

Exploring the geometric motivations behind architectural form

Generative Components (GC) are a new breed of digital modeling methodology emerging to help architects meet complex design challenges and explore new architectural forms. GC allows the designer to programmatically define a conceptual rule-set which the software can use to automatically generate a geometric response. This is a significantly different approach compared to conventional digital modeling where the designer must manually instantiate each geometric element. The benefit of a GC approach is that instead of being drawn into the struggle of creating geometry the designer is free to focus on the underlying conceptual principles, leaving the arduous task of modeling to the software. This freedom enables more time for geometric experimentation which can potentially result in innovative and more efficient architectural responses to a problem.

But when does architecture become programming?

Unfortunately Generative Components are not, and will probably never be as easy as talking to the computer about a project's geometric ambitions. Instead each geometric intention must be clearly defined using logical expressions composed in a GC-specific language. This is very different to the visually inspired tool-set of lines, walls and windows which architects have grown comfortable using thanks to the conventional processes of architectural drawing and CAD. As a consequence it can be argued that someone developing a Generative Component shares more in common with a programmer using a software language than it does to an architect on a drawing board. This poses a problem for the widespread uptake of Generative Components because AEC professionals are generally unwilling to learn an entirely new and conceptually very different way of working in order to gain its benefits.

A typical Generative Components work session within Microstation (click to enlarge)

Whilst certain functional aspects of Generative Components will filter their way into conventional CAD and BIM packages for the most part this technology will remain out of reach to the majority of architectural designers. This usability limitation is not stopping larger architectural practices from establishing Generative Components teams dedicated to mastering the technology and applying it to problems faced within the organisation. Even in these environments financial justification is difficult given the high calibre of staff required, the cost of the software and the ongoing training necessary to remain competitive in Generative Components field. Matters are made worse by the fact that even in an optimistic scenario Generative Components can only be applied to perhaps 5% of 5% of projects, i.e. a very small proportion of a practice's income generating work. Currently this unfavorable cost/benefit analysis is justified due to the threat faced by competing practices and the ability to unflinchingly say to a client that nothing is too difficult. Even given this pressure there will come a time when the financial strain of maintaining an in-house Generative Components team will become too great for even the largest of architecture practices. At this point it would not seem unreasonable to suggest these organisations would look to third-party consultants to provide a cost-effective, on-demand GC capability.

Consultants in the industry

The AEC industry has a range of consulting arms associated with it depending on the type of project and its contractual structure. Consultants are generally involved in aspects of the project where the core participants expertise maybe lacking or in need of complimenting. This can occur at the design level with the involvement of environmental, services and fire engineers, right down to a technical level with the use of I.T. consultants to help meet Internet collaboration demands. No matter what the skill-set it is generally the case that consultants are employed because it is not economically feasible to retain or maintain these skills 'in-house'. Determining economic feasibility within an architectural practice generally comes down to a question of size. Large practices can afford to maintain a fairly broad skills-base to compliment their architects and draftsmen, but for a small practice the capability (or desire) to undertake the level of work needed to justify a broad skill-set does not exist.

The field of Generative Components would appear to be an ideal candidate for outsourcing to a consultancy due to its limited applicability to the majority of a practice's work and the relatively high costs associated with it. Being a small and developing technology it is a difficult proposition for a single architecture practice to efficiently maintain and utilise the skills necessary to gain the most benefit from Generative Components. Unfortunately clouding the decision around outsourcing or retaining an 'in-house' Generative Component capability is the questionable realisable value it has on the design process and the inderminate nature of its deliverables.

Establishing costs for Generative Component consultation

An enabling factor for most external consultation is the ability for the party doing the consulting to define a pricing structure around their involvement. For many this will comprise of a quote that mixes fix-priced deliverables, such as set of building simulations, with a best-guess estimate of the consulting time required to help the project team meet their required objectives. From the perspective of the project team establishing costs and timescales for contractors is critical because it justifies their involvement to the client and establishes metrics for gauging their performance. Establishing these metrics is currently a major barrier to external Generative Components consulting due to the vague working relationships and complicated deliverables which emerge from the current process.

An abstract but interesting example of the explorative capabilities of GC (click to enlarge)

The power of Generative Components is that they enable designers to experiment with the conceptual and geometric premises of their design. However due to the complexity of current GC processes for this to occur the most efficient working relationship is for an architectural designer to operate in partnership with a GC developer. The developer's role in this relationship is to efficiently translate the designer's architectural concepts into mathematically and programatically sound Generative Components. Unfortunately the GC outcomes from this process still require the ongoing input of the developer because the non-standard software used to create the model is not immediately accessible to the designer for experimentation. As a consequence of this lack of accessibility the relationship between designer and GC developer must be ongoing and relatively close. In fact one could argue to generate the most value in the design process the designer and GC developer would need to work together from the conception of a project to its design completion. This is a difficult undertaking because the actual value derived from such a relationship cannot be immediately realised or the costs easily justified to the client over the duration of the design process.

For Generative Components to be established as a viable consulting opportunity a methodology needs to evolve whereby a set of deliverables and estimated time involvement can be clearly defined and presented to the design team. For this to be achieved the GC developer must be decoupled from the design process and be able to deliver accessible GC objects which can be experimented with by the design team in their own time. This methodology change would minimise the cost of utilising Generative Components during the design process because its application would be clearly defined rather than the product of a fuzzy design/developer relationship. Delivering Generative Components in a medium that is cost-effective and immediately accessible to architectural designers would also increase its value throughout the entire industry as the process would be transformed from high-end toy to general purpose tool. Decoupling the designer/developer relationship would also enable the GC consultant to work simultaneously a number of projects from different firms, a critical factor when considering the technology's limited applicability to the overall work within a single practice and the high costs associated with maintaining GC proficiency.

An Internet architecture for enabling distributed and accessible GC interaction

Delivering this methodology change will require the development of a set of bridging technologies between the GC model and architectural designer. The most significant component in this bridging technology would be the development of a light-weight GC server capable of exposing parameter driven GC models to the outside world as traditional 3D models (i.e. a near real-time GC to DWG/DGN converter). The overall architecture of such a bridging mechanism is outlined in the diagram below.

An diagrammatic overview of the role of a GC server in delivering Generative Components in a more accessible manner to AEC professionals (click to enlarge)

Development of a Generative Component would occur as normal but rather than dealing with the model directly the designer would be presented with a user-friendly interface for exploring the possibilities of the GC object in a controlled, parameter driven environment. This interface could range from purely Web-based (i.e. Flash) to being integrated into the architect's CAD package via a plug-in. This client interface would use Web Services to send GC parameters to the server which in response would return the geometric GC outcome for displaying to the designer. Determining exactly which GC parameters to expose to the designer would be the role of the GC developer. Internet enabling GC development would improve the participants ability to undertake design exploration in a distributed environment. In fact the GC consultant could be based on the other side of the world, collaborating with the designer via text, voice or video conference technologies.

Depending on the contractual relationship the GC consultant could also use the quality and quantity of the geometric iterations as a pricing metric. For example rather than creating entirely new Generative Components for each client the consultant would be able to expose pre-made objects to designers on a cost-per access basis (e.g. $0.50 for a basic geometric iteration, $10.00 for a high-quality iteration). This would enable designers to independently and cost-effectively experiment with an existing library of GC parts using low-quality (draft) settings. Once they have something interesting it would then be a case of requesting a single, high-quality version from the GC consultant for actual use. A business model such as this would establish multiple income streams for the GC consultant and help entice architects into experimenting with Generative Components without having to commit to a full blown relationship with the GC consulting firm.

It all comes down to delivery

If Generative Components could be delivered to architects in a more accessible and decoupled manner it would not only establish the technology as a broadly applicable architectural tool but also facilitate a new breed of AEC consulting. As a technology Generative Components demonstrates a lot of promise but until it can be exposed to and utilised by the mainstream architectural audience its capability and potential will never be fully utilised. Internet-enabling the collaborative development and delivery process behind Generative Components will be instrumental in achieving this goal.