stressfree - collaboration

Bluestreak and the birth of a collaboration kernel

David — Thu, 07 Jan 2010 09:11:45 +0000

Successful Architecture, Engineering and Construction (AEC) collaboration depends on the timely dissemination of relevant information throughout the project team. This task is made difficult by the number of collaboration interactions that occur and the diverse range of digital tools used to support them. To improve this process it is proposed that a collaboration kernel could weave together these disparate interactions and tools. This will create a more productive and efficient collaboration environment by allowing design discussion, issues and decisions to be efficiently and reliably exchanged between team members and the digital tools they currently use. This article describes how Project Bluestreak, a messaging service from Autodesk Labs, can be transformed into an effective collaboration kernel. To guide this transformation, the principles of the Project Information Cloud have been used to evaluate the existing service and identify areas for future development. These fundamental digital collaboration principles are derived from lessons learnt in the formation of the World Wide Web. When these principles are embodied within a digital collaboration tool, they have demonstrated an ability to improve the timely delivery of relevant information to members of the project team.

Seamless collaboration within a fragmented digital environment

A successful AEC digital collaboration environment brings multiple parties together so that they can productively work towards a satisfactory and achievable design outcome. During this process participants must engage in a variety of interactions between team members and the digital models used to describe the design. These interactions, and the technologies commonly used to enable them, are summarised in the following diagram and table.

Note: The term 'model' refers to a CAD or BIM digital model that represents the proposed design. Digital models play an important role in the collaboration process as they communicate ideas, impose restrictions and can be manipulated to reflect a participant's opinion.

A diagram illustrating the relationship between the different digital collaboration interactions. (Click to enlarge)

Person to person
Purpose	Productive conversations between design participants are critical for the success of any design project. The intention of these interactions is to present, question and debate all aspects of the design.
Nature	Given the non-linear and bi-directional nature of conversation, the ideas and data communicated are generally fluid and unstructured. To be most effective, the tools used should not introduce latency as this can result in a disjointed conversation. During these exchanges it should be possible for participants to easily reference media such as photographs, documents, diagrams and digital models.
Enabling technologies	The most common person to person interactions during a design project are physical meetings and telephone conversations. In cases where participants are geographically distributed, Internet-based voice and video conferencing technologies are supplanting these 'traditional' tools. Email, and to a lesser extent instant messaging, are also commonly used in situations where person to person interactions are limited in scope, or do not warrant the interruption of a real-time meeting.
Person to group
Purpose	Individuals must be able to efficiently and reliably communicate information about the design to the project team, such as its status, data and any associated decisions or questions.
Nature	This interaction is uni-directional because a group cannot directly add to a conversation. If a recipient of a person to group message responds this spawns a new person to person, or person to group interaction. Person to group interactions typically have a specific topic, but the supporting media referenced during the exchange varies depending on the subject and its context.
Enabling technologies	Email is the most prevalent digital means of communication between a participant and the project team. Messaging systems and discussion forums embedded within project extranets, company intranets or the public Internet are also used. However compared to email their industry adoption is limited. Many document management systems include support for person to group interactions, but this is typically a secondary and underused piece of functionality.
Person to model
Purpose	A participant interacts with the model to understand the design, express new ideas and review the contributed work of others. If the participant cannot efficiently comprehend or manipulate the model, their ability to take part in the broader design discussion is significantly impacted.
Nature	The nature of this interaction depends on the role and technical ability of the individual. It is common for the majority of an AEC project team to be unable to modify the model. For these participants the model simply communicates the design state, whereas those capable of modifying the model can reshape it to reflect their own opinion, or that of others.
Enabling technologies	The primary interface between the individual and a digital model is the CAD/BIM software used to create it. Given the complexity and cost of this software, more accessible formats such as DWF and 3D PDF have been developed to allow the entire project team to experience and provide feedback on the model.
Model to model
Purpose	To simplify and distribute the overall process, a design is typically developed using more than one digital model. It is important that these distinct models can be efficiently and consistently integrated so that the team can comprehend the overall design.
Nature	Given the technical complexity of this task, the flow of data in a model to model interaction typically goes in one direction. This involves extracting the data present in one or more digital models and merging it into a primary 'master' model.
Enabling technologies	Technologies for model to model interaction vary in complexity, capability and industry penetration. The most common means of consolidation is the manual importing of data from standard digital model formats such as IFC or DWG. Unfortunately, incompatibilities between different CAD/BIM implementations mean such interactions can lead to inconsistent data. Many CAD/BIM tools have functionality for collaboratively editing digital models, but uptake is limited due to their operational complexity and the limitations imposed.
Model to group
Purpose	The overall design needs to be distributed amongst the project team for review and eventual construction. The information conveyed by the model is raw data related to the current state of the design, rather than personal opinion.
Nature	Given the physical and technical distribution of a project team, it is usually impractical for a group to interact with a digital model in real-time. To compensate, snapshots of the model's design state are created and communicated in a manner that all interested parties can consume. Given its revision-centric nature, the information transfer between model and group is uni-directional. If group members wish to respond to the information conveyed they must establish a new person to person, person to group or person to model interaction.
Enabling technologies	In larger projects, document management systems such as Buzzsaw, ProjectWise and Aconex are commonly used to ensure the project team is informed of changes to the digital model and supporting documentation. Many of these tools are integrated into CAD/BIM software so that the interaction between model and group is seamless. In smaller projects the cost and complexity of these systems cannot be justified, so manual file transfers using FTP or web servers are often used to distribute the model.

Given these diverse functional requirements it is understandable that no single technology is capable of satisfying the digital collaboration needs of a project team. This poses a problem because participants stand the greatest chance of receiving timely and relevant data when the digital experience is well integrated. Unfortunately the boundaries between two or more collaboration tools generate inefficiencies, confusion and data loss due to the inability of many digital tools to collaborate with each other. As a consequence, using two or more digital collaboration tools can often lead to the following issues:

Lack of Process Integration: The decisions or actions taken in one tool are often not reflected in others. In an ideal world, design decisions made during an email exchange would automatically generate outstanding to-do items within the digital model and have the document management service (DMS) notify the team of forthcoming design revisions. When interacting with the digital model or DMS later in the project, this same trail of messages can be used to understand the motivations and justification behind a design element. Currently these actions currently cannot be automatically undertaken, because a simple means of passing messages between the various collaboration tools used by the team does not yet exist.

No Identity Management: Collaboration tools do not generally use the same system for identifying users or recording information about them. This forces participants to create numerous virtual identities and maintain a record of those used by the team. This becomes problematic when reviewing a series of design decisions that have been made in unison with multiple collaboration tools. For example, a project team using email to exchange thoughts between participants, BIM to develop the digital model and a document management service to distribute the outcomes employs the following identity systems:

Interaction	Software	Identity System
Person to model	BIM software	Account on the local operating system. e.g. COMPANY\username
Person to person	Email	Globally unique email address. e.g. participant.name@company.com
Model to team	Document management service (DMS)	DMS-specific user account. e.g. participant_name

With three different identity systems, tracking a design decision from conception (email) to its finalisation (in the DMS) becomes a complex process. Questioning a design decision is no easier because the participant must first identify who it is they need to talk to, and from there discern that person's virtual identity relative to the collaboration tool being used to conduct the interaction.

Functional and Data Repetition: The lack of messaging or identity integration between collaboration tools results in the repetition of functionality and data-entry tasks. Common information such as the identities of team members, their project roles and general interests cannot be easily shared or consumed by applications. Similarly, common collaboration functionality used by multiple applications must be continually reimplemented rather than being reused. This occurs because utilising functionality present in third-party applications is difficult, and not all participants have access to the relevant software dependencies. This situation is akin to early desktop computing where system-wide functionality such as copy, paste and printing did not exist. Once this shared functionality was introduced, the capability and productivity of desktop computing was improved because all involved could rely on the presence and consistent behaviour of these familiar tools.

Using a collaboration kernel to integrate collaboration interactions

In an ideal world, the various collaboration interactions which occur during a project would be supported by a single, tightly integrated software application. This 'digital collaboration swiss army knife' would promote an efficient and cohesive collaboration environment by reliably recording and seamlessly communicating relevant design information throughout the team. Unfortunately a universal AEC digital collaboration tool is impractical, both now and in the foreseeable future, because of the complications which arise from bundling so much functionality into a single tool that will be used by a diverse audience. Rather than trying to reinvent the perfect wheel, a more practical approach is needed that provides a means for existing digital tools to exchange design discussion, issues and decisions. This will relieve the integration and replication issues that currently exist without having to start from scratch. The most efficient and reliable means of solving this problem is to establish a collaboration kernel that can act as an intermediary between the disparate tools. This Internet-centric service would in effect become the project's digital post office, overseeing the exchange of messages that support, summarise and promote the collaboration interactions taking place within the project team. A collaboration kernel's presence would be subtle, but its influence on collaboration would be significant. For example, consider the following hypothetical scenario set in the not too distant future:

Pam the project manager reviewed the client's email. The design of the entrance foyer for their multi-storey commercial development needed to be enlarged to accommodate more activities than originally projected. This was not a simple task because the layout of the ground floor was tight, so allocating more space meant sacrificing something else. In her email client she highlighted the email, pressed the New Task button and from the list of names assigned it to Andy the architect. She wrote a quick summary of the task ahead:

"From Pam to Andy: Tomorrow can you identify an alternative foyer design based on the criteria listed in this email?"

She pressed the 'Create Task' button and left work for the evening. As she left, the email client uploaded a copy of the email to the architecture practice's internal server where Andy could access it. It then passed Pam's message, along with a link to the relevant email, to the collaboration kernel which would ensure the task would be brought to Andy's attention the next morning.

The next morning Andy arrived in the office and logged into the Practice's Intranet. His personalised homepage checked in with the collaboration kernel, which promptly returned the task Pam had assigned to him. Andy read the message and followed the link to the referenced email. Being newly assigned to the project he was not fully aware of previous design decisions associated with the foyer. To provide some background he queried the collaboration kernel for all the design interactions related to that specific part of the building. The service returned a chronological history showing who had been involved in the design of this aspect and what input had been recorded. The breakdown revealed two particularly active design periods which included references to early 3D models and preliminary spacial renderings. Reviewing this work and the associated discussions, Andy quickly came to terms with the design concepts and issues at work within this part of the building. He opened the project's Building Information Model (BIM), but before starting work on the revision made the following note in the modelling tool's work-log:

"From Andy to everyone: I am spending this morning redeveloping the entrance foyer as per Pam's instructions."

He attached Pam's task to this note and saved it to the work-log. Behind the scenes the BIM software published the message to the collaboration kernel. The kernel broadcast the message to everyone in the team so that they could be forewarned of the changes afoot.

Meanwhile in another part of town Leny the lighting consultant was finalising the design of the building's ground floor lighting. That morning he had received a phone call from the client requesting a change to some of the fittings, but the proposed foyer changes had not been mentioned. His lighting simulation software displayed a notification from one of the architects:

"From Andy: I am spending this morning redeveloping the entrance foyer as per Pam's instructions."

Lenny could not access Pam's referenced instructions as he worked in another office, but he got the feeling this could affect his lighting design. He contacted Andy over instant messaging, and very quickly they identified the change would be a problem and that they should have a telephone conversation to discuss a practical way forward. After the telephone call Lenny quickly made a couple of notes about the conversation and what changes they had both agreed to make to their respective digital models:

"From Lenny to everyone: Andy and I have just discussed the proposed changes to the foyer and have come to an agreement that will suit the client's needs and code requirements."

"From Lenny to Andy: If you redesign the east side of the foyer as discussed I will be in a position to make the relevant lighting design changes this afternoon."

These notes were published to the collaboration kernel where they were distributed to everyone in the team. The second note was addressed to Andy so that his computer would remind him of Lenny's plans.

Andy spent the morning modifying the digital model to include the revised foyer design. On completion he published the revised model to the project's document management system (DMS) for review. On committing the change he wrote a quick summary of what design aspects had been modified:

"From Andy: This revision to this foyer design takes into account the changes to capacity requested by the client. Accommodating this extra space required changes to the surrounding design, which is forcing Lenny to redesign aspects of the lighting."

News of this change and the accompanying note where automatically published to the collaboration kernel by the DMS. Team members tracking this particular model where then automatically notified of Andy's change by the collaboration kernel. Lenny was one of these people, and on receiving this news he downloaded the revised model for checking against his updated lighting design. After confirming there were no conflicts and the design met code requirements he published a note via the collaboration kernel:

"From Lenny to Andy and Pam: I have reviewed Andy's proposed foyer changes alongside my revised lighting layout. Everything checks out, and as far as I am concerned everything can proceed."

The collaboration kernel delivered the message to Pam to her mobile phone via SMS. She was tied up on the construction site in meetings most of the day, but had been keeping half an eye on Andy and Lenny's activity. She sent an SMS message in reply:

"From Pam to Andy and Leny: Good progress. When I get back to the office I will have the client to review both changes."

The SMS went to a service that automatically forwarded incoming messages from approved numbers to the collaboration kernel for distribution amongst the team.

Establishing a collaboration kernel and attaining this level of integration between the various digital tools in use will take a significant amount of time and resources. Fortunately the early foundations of this cohesive environment may already be in place. For example one promising collaboration kernel candidate is Project Bluestreak, a web-based messaging tool from Autodesk Labs.

The untapped potential of Bluestreak

Autodesk Labs' Project Bluestreak is a Web-based tool for exploring the applicability and usefulness of various 'Web 2.0' and social networking concepts within the context of design collaboration. Whilst unique for Autodesk, this is not the first time these technology concepts have been applied within the AEC industry. For example Vuuch and Kalexo are two established and functionally richer products. However, Autodesk is a dominant and pervasive presence throughout the world of digital design. Therefore if Bluestreak testing proves successful, aspects of it could permeate through their entire software portfolio. This would significantly benefit the workflow of Autodesk's customers, and ultimately influence the direction of collaboration within the industry. In the shorter-term, a key differentiator between Bluestreak and its contemporaries is the support pledged to third-party application development on the platform. Of late, developer ecosystems that leverage information and relationships stored within larger, parent networks have achieved significant business traction. SalesForce's AppExchange and Facebook's Application Directory are prominent examples of this strategy. In both cases, large numbers of independently developed applications have flourished thanks to the popularity of the underlying core service. A collaboration-centric application ecosystem would not garner the same levels of developer or media attention, but within the context of the AEC industry would still be a powerful platform. For Autodesk such an endeavour would add considerable value to their product line, whilst for third-party collaboration tool vendors it would significantly ease development and distribution costs.

A screenshot of the Project Bluestreak web interface. (Click to enlarge)

When viewed alongside the concept of a collaboration kernel, Bluestreak in its current form is a lost opportunity. Instead of a standalone website, the service should be repositioned as a social messaging service that will be integrated across Autodesk's software portfolio. This would be a strong move as it would expose the service to a broad audience and position it as a viable collaboration kernel. Internally this would benefit Autodesk as it would allow their various development groups to leverage this collaboration-centric functionality via a set of Application Programming Interfaces (API). Once standardised, these same APIs could be publicly exposed to enable third-party application integration, or entirely new collaboration experiences. Third-party software vendors would be eager to build on this platform as it would simplify development and provide a direct, sanctioned link to Autodesk's applications and customer network. Whilst this strategy may sound simple, transforming Bluestreak into a viable collaboration kernel will not be straightforward. The service shows promise but it needs a considerable amount of redevelopment before it can adequately meet this challenge. Rather than blindly working towards this goal, a more productive approach is to analyse Bluestreak's theoretical performance relative to the collaboration principles set down by the Project Information Cloud. This process will identify a set of functional improvements that are required before it can effectively meet the demands of operating as a collaboration kernel.

A Bluestreak in the Project Information Cloud

The intention of a collaboration kernel is to improve the timeliness and relevancy of information delivered to project participants. To achieve this, the kernel must provide a set of common functionality that can be easily leveraged by other AEC software tools. This will efficiently improve the capability of these tools and allow team members to participate in an integrated and consistent collaboration environment. But what functionality does such a kernel require and how will this ensure the collaboration experience is improved?
One solution to this problem is to apply the principles of the Project Information Cloud to the design of the collaboration kernel. The Project Information Cloud is a proposal for an integrated collaboration environment where a project's digital history is readily accessible to those involved (see Using Project Information Clouds to Preserve Design Stories within the Digital Architecture Workplace). The principles of this environment have been derived from the World Wide Web, which in a relatively short space of time has proven to be a very successful and versatile medium for digital collaboration.

The seven principles of the Project Information Cloud are:

Comprehension: Is the system relatively easy to understand and use by both developers and participants within a project team? Technology should facilitate streamlined and reliable collaboration interactions instead of being an unfortunate necessity.
Modularity: Can the functionality of the system be extended or replicated by a third-party without interrupting the overall experience of the project team? The concept of a collaboration kernel implies that the extra functionality required to achieve each collaboration interaction can be seamlessly 'bolted on'.
Decentralisation: Can the collaboration interactions reliably occur without the presence of a central, mediating body? Likewise can one or more parties leave the project team without effecting the consistent flow of information?
Ubiquity: Can the entire project team access the system from the digital tools that they commonly use? Reliable interaction with the collaboration environment should not require specialised tools that are dependent on a specific software vendor.
Situational Awareness: Is the system capable of gathering and responding to external information generated by other systems within the project team? A system that stands alone is of marginal value as a collaboration tool.
Context Sensitivity: Does the system understand the hierarchy and ongoing activities within the project team, and can it tailor its operations and user-interfaces accordingly? AEC project teams are complex and constantly changing. Collaboration systems that cannot adapt during these context shifts are at best a hindrance, and at worst a liability.
Dynamic Semantics: Can the system's categorisation system change over time so that participants record and navigate information in a way that relates to the current state of the project? No two projects are identical, and as they evolve the vocabulary used to describe the design and associated activities needs to keep pace with this change.

The ability of a collaboration tool to satisfy these principles can be visually illustrated on a seven point spider diagram. Analysing a tool's performance in this manner is a simple yet effective means of identifying its strengths and weaknesses relative to other collaboration technologies. The rating system employed by this spider diagram is illustrated below and described in the following table.

Comprehension
0 - Enigma	The purpose, processes and outcomes of the collaboration tool are impossible to understand.
1	One or two aspects of the tool's purpose, processes and outcomes are somewhat understood by a few users.
2	After significant amount of effort, the tool's purpose, processes and outcomes can be understood by the minority of users.
3	After some effort, the purpose, processes and outcomes of the tool can be largely understood by the majority of users.
4 - Obvious	The purpose, processes and outcomes of the tool are readily understood by all users.
Modularity
0 - Sculpture	The tool is made from a single, large component whose functionality cannot be extended or replicated.
1	The tool is made from a single, large component, but with significant effort minor functional aspects can be extended or replicated.
2	Parts of the tool are modular and with significant effort some its functionality can be extended or replicated.
3	The majority of the tool is modular and with some effort most of its functionality can be extended or replicated.
4 - Lego	The tool is completely modular and with minimal effort all of its functionality can be extended or replicated.
Ubiquity
0 - Exclusive	The tool is only used by a single party and employs non-standard, proprietary technologies and data formats.
1	The tool has some industry use, but it is not readily available and employs non-standard, proprietary technologies and data formats.
2	The tool is readily available, but not widely used and generally employs non-standard, proprietary technologies and data formats.
3	The tool is readily available and widely used, but it generally employs non-standard, proprietary technologies and data formats.
4 - Universal	The tool is readily available, widely used and employs freely accessible technologies with standardised data formats.
Decentralisation
0 - Monolith	The tool in its entirety is bound to a single location and cannot be moved or used anywhere else.
1	The tool is based in one location, but with significant effort it can be deployed to and used in multiple locations.
2	The tool relies on some centralised components, but with moderate effort it can be deployed to and used in multiple locations.
3	The tool has a few centralised components that do not stop it from easily being deployed to and used in multiple locations.
4 - Mesh	The tool's components are distributed and replicated, which presents no single point of failure and allows its use from anywhere.
Situational Awareness
0 - Isolationist	The tool is isolated from the outside world and its processes and interface cannot respond to changes in this environment.
1	With significant effort the tool can monitor a few external resources so that its processes or interface can respond to changes in them.
2	With moderate effort the tool can monitor some external resources so that its processes or interface can respond to changes in them.
3	With minimal effort the tool can monitor a large number of external resources and can automatically respond to changes in them.
4 - Hive mind	The tool is deeply intertwined with its surrounding environment and its processes and interface automatically responds to changes in it.
Context Sensitivity
0 - Oblivious	The tool has no understanding of the project situation and its processes and interface only operate one way.
1	The tool has no understanding of the project situation, but with significant effort, its processes and interface can be tuned.
2	The tool has a very limited understanding of the project situation, but with moderate effort, its processes and interface can be tuned.
3	The tool has a limited understanding of the project situation, and in response can change some processes and interface aspects.
4 - Aware	The tool has a strong understanding of the project situation, and in response automatically changes its processes and interface.
Dynamic Semantics
0 - Meaningless	The tool employs no semantic system to organise the data it collects or transfers.
1	The tool employs a single semantic system that cannot be modified without considerable effort or planning.
2	The tool employs a single semantic system that can be modified with minimal effort or planning.
3	The tool employs multiple semantic systems specific to the user and their context, but modifying them requires considerable effort.
4 - Expressive	The tool employs multiple semantic systems specific to the user and their context, and if need be they can be easily modified.

How each of these Project Information Cloud principles is embodied within collaboration tools currently used by the AEC industry is illustrated in the following diagrams. In this diagrammatic analysis an ideal digital collaboration tool would form a perfect heptagon, but in each case one or more areas are found to be lacking.

A comparison of collaboration tools currently used and their performance relative to the Project Information Cloud principles. (Click to enlarge)

These same principles can be applied to Bluestreak to identify its collaboration strengths and weaknesses. Adequately satisfying these principles will ensure the service has a strong chance of performing well as a collaboration kernel. Bluestreak's immediate and long-term ability to satisfy the principles of the Project Information Cloud are illustrated in the following diagram and proceeding text.

(Click to enlarge)

Comprehension

Bluestreak is currently easy to understand because it has only just been released and therefore lacks functionality or historical 'cruft'. Given this spartan beginning, the greatest challenge facing Bluestreak's developers is identifying what functionality does not need to be added. This is important because a collaboration kernel should be concise so that those using it have a clear understanding of what services it provides and why. A limited scope will help to ensure the Bluestreak platform is easily adopted by developers and end-users appreciate its role in collaboration. This strategy has been very successful for Twitter, which has flourished thanks to the ease by which developers and users alike have understood what it has to offer and how to leverage it to achieve their desired results.

(Click to enlarge)

The difficultly ahead for Bluestreak is that becoming a successful collaboration kernel requires it integrate with a diverse range of AEC tools in a number of ways (as illustrated by the diagram above). This integration breaks down into three forms:

Components: Autodesk and third-parties will build components on top of the Bluestreak API that will form a critical part of its web interface and functionality.
Web Service API: For basic operations many Autodesk and third-party web applications will interact with Bluestreak using a set of web service functions. Web services are a ubiquitous and accessible means of exchanging data between different systems, but these same properties makes it an inefficient means of programming complex tasks.
Client API Libraries: Learning a set of low-level web services and writing custom code poses a significant learning curve and development hurdle. To ease this burden Autodesk needs to provide a set of software libraries which allow developers to reliably and quickly perform a set of complex Bluestreak operations using only a few lines of code.

To improve the comprehension of developers and users it is important that these three integration points are well designed and documented. A developer should not be expected to understand the entire Bluestreak platform if all they wish to do is achieve quick results using a Client API library. In contrast, the experience of the end-user should be such that they are unaware these even interfaces exist. To them Bluestreak should be as transparent as possible so that collaboration across different applications appears to "just work".

Modularity

Bluestreak's capacity to be modular hinges on its API which will allow third-parties to develop new components. As this API is currently not publicly available judgement cannot be passed on its success. However, it is promising that Bluestreak's own file upload component has been developed using a subset of it. Beyond allowing independent parties to add new functionality, a well documented and public API can be reimplemented by other collaboration systems such as ProjectWise, Aconex and Vuuch. If these services reimplemented the API then, at least in theory, Bluestreak components would be able to integrate with, or run inside of these other services. The benefit of this modularity is that a 'killer application' written on top of the Bluestreak API would not necessarily be restricted to Autodesk's collaboration environment. In the programming world cross-platform APIs and runtime environments are popular and powerful platforms. These range from fully portable programming runtimes such as Java, to ports of traditional APIs like WINE, which enables Windows applications run unmodified on other operating systems.

A diagram illustrating the relationship between the Bluestreak service, its API and various Autodesk and third-party applications.

Beyond the as yet unreleased API, Bluestreak employs OpenID which is an open standard for authenticating to websites. This is currently limited to Autodesk's own OpenID provider, but a future iteration could permit third-party OpenID services to be used, for example Google, Yahoo or an internal corporate account. Enabling authentication modularity in this manner lowers barriers to entry, as potential collaborators will not necessarily have to create a new online identity to participate in an online conversation.

Decentralisation

Like most web applications, Bluestreak cannot be installed onto a private server and migrating data stored on it to another service is not straightforward. This may suffice for a consumer application, but it poses a significant problem in the context of the AEC industry. Companies require reliable systems that adhere to entrenched processes and policies. Therefore to be successful Bluestreak must be decentralised so that it can be run 'in-house' or integrated into other systems.

The first step in this process would be to offer Bluestreak as a standalone application that can be installed on a local server. This sounds straightforward, but in practice it would require significant changes to the way Bluestreak is designed and implemented. An isolated copy of Bluestreak is of limited value if it cannot "talk" to other Bluestreak installations. For example if architects and engineers cannot exchange information because they are running different Bluestreak instances, then the service as a whole is of limited collaboration value. Unfortunately enabling this level of reliable and timely data exchange is fraught with challenges. Google Wave captured headlines due to its rich user-interface, but ultimately its long-term success hinges on the ability of the Wave Federation Protocol to allow users on different Wave servers to seamlessly collaborate in near real-time. A viable option would be for Autodesk to follow Novell's lead and implement the Wave Federation Protocol within Bluestreak. This would solve the decentralisation problem, however this would be a complex, costly and inherently risky undertaking.

Ubiquity

Bluestreak shows promise as a collaboration kernel because it is built on ubiquitous technologies and places minimal restrictions on what can be exchanged. Being a Javascript-based web application, it can be accessed from any standards compliant web browser with an Internet connection. Likewise, when using the tool participants are free to exchange whatever data their team can readily access, instead of being forced into specific formats.

Micro-blogging is one area where Bluestreak could enhance its ubiquity. Micro-blogging is a promising AEC collaboration medium (see Using micro-blogging to record architectural design conversation alongside the BIM), but the implementation within Bluestreak is hamstrung by its isolation and inconsistencies. There is currently no means of posting a message without visiting the Bluestreak website, and for no discernible reason 'status' and 'group' messages have different maximum lengths - 150 vs 250 characters respectively. A more ubiquitous approach would be to implement an existing, albeit immature, micro-blogging standard such as StatusNet (formerly Laconi.ca). Extending an established platform would allow Bluestreak to leverage this existing functionality and community. Project teams would then be able to use desktop or mobile-based software clients rather than just the Bluestreak website. From the perspective of decentralisation, initiatives like StatusNet also allow different micro-blogging systems to exchange messages. These federated micro-blogging solutions are simpler than Google's Wave Federation Protocol, and could prove 'good enough' for the purposes of digital design collaboration.

Beyond the promotion of ubiquitous formats and processes, the concept of Bluestreak needs to become ubiquitous across Autodesk's software line. Similar to Ray Ozzie's Mesh initiative within Microsoft, Bluestreak should be portrayed as a collaboration umbrella that touches upon all aspects of Autodesk's activities. Conversations currently taking part within the Bluestreak web application need to be brought to the 3D CAD and BIM tools where the majority of design development, analysis and documentation is taking place. For example, when using Revit an architect should be able to review and participate in Bluestreak discussions without leaving the application. Then when the model is exported to DWF for sending to the contractor, relevant aspects of that discussion could be embedded within the file to preserve its context relative to the overall design process.

Situational Awareness

Currently Bluestreak depends on manual data input and there is no way of externally monitoring the discussion taking place within it. This is a considerable shortcoming because collaboration takes place over multiple communication channels. A successful collaboration kernel should make the team aware of the activities taking place on these other channels instead of being oblivious to them. The API could significantly boost situational awareness by allowing components to pull data from external services, or push data into Bluestreak. Examples of potential components are:

Changes: An agent that monitors files in a third-party document management service and informs the team when modifications take place. Most project documentation will not reside within Bluestreak, so knowing it has changed and to what degree is an important consideration during collaboration.
Progress: An agent that parses the project manager's Microsoft Project file or shared calendar and alerts the team of significant events. The project timeline is continually evolving and those involved cannot be expected to maintain it in multiple locations. Monitoring a project's timeline also ensures the collaboration service satisfies the principle of context sensitivity.
External Activity: An agent monitors an external email account, collaboration tool, or web service for information contributed by a third-party. A sub-contractor may not warrant full Bluestreak project membership, but they could be provided an email address for submitting information and questions. The component could then automatically monitor this email account and publish correspondence to Bluestreak.

Situational awareness is a two-way street, so beyond acting as a data sponge, Bluestreak should expose data to trusted third-parties. Presently users can manually monitor conversations via the website, or elect to have all status/group messages emailed to them. Both of these options are problematic because for many team members Bluestreak will not form a part of their daily workflow. As a result most will not visit the website regularly and will soon ignore, or disable, email notifications. These attention issues cannot be resolved by Bluestreak alone. Instead it must work towards exposing its data and functionality to applications that are regularly used by the team. A prime example of this is that a large portion of Twitter use takes place within third-party tools. Similar results can only be achieved by Bluestreak if it exposes the collaboration interactions it records in machine readable formats (RSS, XML, JSON) that can be parsed by other software used within the project team.

Context Sensitivity

Bluestreak's only nod towards context sensitivity is the use of groups to divide people and conversations. In the future it needs to make better use of the contextual information within a project so that participants can easily navigate, filter and target collaboration interactions. For example project teams have clearly defined, hierarchical relationships that reflect the roles and expertise of each participant. A collaboration kernel that successfully leverages this knowledge will be more able to deliver timely and relevant information to the team. Bluestreak users have profiles, but these lack expertise or fields of interest which would help to bring relevant messages to their attention. Alternatively this information could identify people within the team who are the most capable of resolving a specific design problem.

Beyond filtering and highlighting conversations, context is a useful means of stopping information from reaching participants in the first place. In its current form, a Bluestreak project is like working with a group of people in a large auditorium - anybody can say or hear anything. Whilst fine for general situations, when large numbers of people or sensitive data is involved it becomes important that certain interactions occur in private. At present multiple Bluestreak groups can be created to achieve this, but practically this is unwieldy. A more flexible approach would be to allow messages to be addressed to people within the team based on their profile's meta-data or the project's hierarchical structure. This could be achieved by combining micro-blogging's address (@) and subject (#) syntax at the beginning of a message. For example, a message beginning with @#architect would signify it should be brought to the attention of architects within the team. This same mechanism could be extended to specific phases in the project (@#construction), or fields of interest (@#concept). Borrowing again from micro-blogging, a leading 'd' character (for Direct Message) would signify that the message was intended for a restricted audience. Whilst this syntax is simple, it is compatible with micro-blogging standards and can be clearly presented by software agents.

Dynamic Semantics

At present Bluestreak lacks any means for categorising contributed content. When navigating or searching large amounts of AEC collaboration data this soon becomes a problem because the content of many messages does not reflect its subject matter. For example a discussion centered around "indoor and outdoor flow" maybe conceptual (the floor layout), or specific (the detailing of a door). Micro-blogging services like Twitter have demonstrated that semantics can be embedded within messages via hash (#) tags which Bluestreak could easily support. Components could then be developed using the API that allows the project's semantic structure to be visualised and navigated.

Embedding hash tags within messages is a flexible means of publishing semantics, but participants must also be able to retrospectively apply meaning to content. For example a project's taxonomy will initially focus on conceptual ideas, but as the design is refined, so too will the semantics used to describe it. Semantics are also relative depending on the perspective of the participant, therefore it must be possible to assign multiple semantic layers to content. Achieving this semantic flexibility requires users possess the ability to manually re-categorise any content. To assist in this process the collaboration kernel itself should infer meaning based on a message's context and any assigned relationships.

Applied Semantics

Within Bluestreak users should be able to tag any content that has been contributed so it can be referenced by other data. In a distributed environment embedding new semantic information within existing content is problematic because these changes must be replicated across the team. A more efficient means of solving this problem is to assign all content published to Bluestreak a globally unique URL. These simple URL references can then be categorised multiple times using an existing bookmarking/tagging service such as Delicious, or a native Bluestreak tool.

Inferred Semantics

Beyond manual tagging, semi-intelligent agents could categorise collaboration data based on where and when it was created and what it is related to. This would require Bluestreak to be integrated into other software so that information can be automatically included from this environment. For example, an architect using Revit may identify and highlight an issue with the design's foundations. On posting the issue to Bluestreak using a tool built into Revit, relevant meta-data such as the components affected (foundations), materials used (concrete) and the model's revision details (revision #432) would be included automatically.

Conclusion

A collaboration kernel communicates key design ideas, issues and decisions between the disparate digital tools used by the AEC industry. If it became as digitally prevalent as copy and paste is today, such a service would be an efficient and reliable median between the various collaboration interactions which occur. By helping to weave together these various communication channels, the collaboration kernel would improve the timeliness and relevancy of information delivered to members of the project team. The principles of the Project Information Cloud proved very useful in isolating the key characteristics of a collaboration kernel and its benefit to information flow within the team. Using these principles to assess Bluestreak identified a set of changes that would allow it to better fill the role of collaboration kernel. By implementing these changes and integrating the service across its line of software products, Autodesk could be the first to establish a collaboration kernel, and in doing so ultimately improve the AEC industry's overall collaboration capability.

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.

Adobe Genesis brings fresh AIR to business portals

David — Tue, 09 Sep 2008 11:33:14 +0000

Adobe Genesis is an AIR take on the venerable enterprise dashboard, or "enterprise desktop" as it is referred to on their development blog. Development of this business platform has not taken place in secret, but it has only recently been given its first public outing at the Office 2.0 conference. Below is a 40 minute video presentation by the Product Manager Matthias Zeller on Genesis, but if you want a higher resolution view check-out this March 2008 screen-cast.

Genesis is an attempt by Adobe to position their AIR run-time as the platform for business applications. Given the eagerness of business developers to use Flex, Adobe are hoping AIR will see similar levels of adoption. However unlike Flex, which produces Flash content that any modern web browser can consume, AIR applications reside in their own, dedicated run-time. This requirement, alongside improvements in browsers, may prove too big an obstacle for Adobe to get around, but you have to give them credit for trying.

Hidden Text

Overall Genesis is a shiny looking, but still fairly standard, enterprise dashboard. The biggest problem is that the majority of the functionality demonstrated could be achieved using modern Javascript and Flash. Besides the ability to drag and drop files to and from Genesis there appears to be very little demonstrated benefit to using the AIR run-time over a standard web browser. This is unfortunate but the signs are there that if luck went Adobe's way Genesis could become huge.

Adobe "Genesis" Overview @ Office 20

Things could get interesting for Genesis if Adobe can deliver rich, Microsoft Office-like functionality as reusable AIR widgets. If they can pull this off then they stand a chance of establishing Genesis as the "Intranet 2.0" equivalent of the 1990's Access/Visual Basic combination. One really interesting piece to this puzzle is the built-in support for third-party 'templates' and 'tiles' (aka widgets). With this 'catalog' Adobe are attempting to establish a marketplace where developers can easily sell their Genesis handiwork to businesses. If this is followed through it may provide the momentum to push Genesis from a good looking toy to integral business component.

As it stands many I.T. departments will discount Genesis because its demonstrated benefits do not outweigh the cost and hassle of supporting yet another desktop run-time. Adobe and its partners will need to work hard to construct a vibrant ecosystem which justifies the AIR investment. The clock is also against them because Microsoft will no doubt be readying a Silverlight response that leverages their existing Office monopoly.

AttendAnywhere brings high-end video conferencing to the corporate masses

David — Wed, 03 Sep 2008 20:00:00 +0000

Disclaimer: I have undertaken some consulting work for AttendAnywhere in the past. This post only covers what is publicly available and I haven't received a penny for writing this. About the only thing I may get from the AttendAnywhere guys is a beer (or a slap on the head) the next time I am in Melbourne. Anyhow, on with the show...

Rising fuel prices, hectic schedules and incessant climate change warnings are making us more aware of the hidden costs of 'same room' meetings. Whilst telephone conferences alleviate the need for travel, a lack of visual feedback leaves such exchanges feeling one dimensional and disjointed. Up till now video conference choices have either been too costly or rudimentary to be viable business solutions. In an effort to change this, Melbourne-based AttendAnywhere have partnered with Vidyo to offer an affordable, on-demand, high-quality video conferencing solution.

That's me (on the right) taking part in a video conference. (click to enlarge)
Yes that is a .Net book in the background - I was young, naive and she promised to be gentle...

But what is wrong with Skype?

At this point many people start to wonder why you would want to spend money on video conferencing when Skype video is free. The AttendAnywhere/Vidyo combination provides a range of advantages over plain old Skype:

Multi-party conferences - Skype is limited to one on one video.
Screen sharing of applications - Is possible in Skype but requires third-party software.
Very low-latency audio - Ever tried having a conversation on Skype only to talk over people? Vidyo has pretty much solved this problem.
High quality, robust calls - Skype video works, but is not that consistent as far as video or audio quality goes. Vidyo dynamically degrades the video and audio quality to make sure the conversation can still keep going.
Meeting management - Skype lets you make calls but it does not help when it comes to setting them up.
Ad-hoc meetings - With Skype you really need to be 'friends' with someone to start a meeting. In a business environment where you could be meeting with hundreds of relative strangers this is unwieldy.
Support - Skype is a subsidiary of eBay focused on mainstream audio services. AttendAnywhere is dedicated to business to business video conferencing.

How affordable is affordable?

The reality is high quality, business-critical video conferencing cannot be achieved for free. No matter how the solution is deployed there will be significant infrastructure and support costs. However, consider this back of the envelope comparison of a traditional setup vs AttendAnywhere's on-demand offering.

In this example we will use a hypothetical three office company that conducts 10 hours of video conference meetings per week, or approximately 31,200 meeting minutes per year (all values in Australian dollars):

The traditional video conferencing model

Description of expense	Total cost per year
Video conferencing units (Cisco/Polycom) - $6,000.00 per office	$18,000
Dedicated ISDN lines - $350 per month per office	$12,600
Third-party technician to install and support equipment - 10hrs per month @ $140hr	$16,800
Total cost	$40,200
Approximate 'per minute' cost:	$1.52

The on-demand (Software as a Service) video conferencing model

Description of expense	Total cost per year
AttendAnywhere subscription - $0.36 per minute x 43,000 AA minutes*	$15,480
Decent PCs with good quality web cameras and microphones - $2,500 per office	$7,500
Extra Internet bandwidth on top of standard connection - $50 extra per month per office	$1,800
In-house technician to install and support computers - 4hrs per month @$70hr	$3,360
Total cost	$28,140
Approximate 'per minute' cost:	$0.90

* 43,000 AttendAnywhere minutes = 25,000 minutes one to one conversation and 6,000 minutes of three way conversation (different rates apply)

The above calculations assume three dedicated PCs would be purchased rather than reusing existing hardware. It also assumes that an existing network infrastructure and support system is in place (i.e. an internal "I.T. guy"). Even taking into account these hardware costs, an on-demand video conferencing solution still comes out significantly cheaper per minute than a traditional, dedicated setup.

How does AttendAnywhere do it?

AttendAnywhere itself does not produce video conferencing software, it simply resells access to high-end Vidyo developed systems. Vidyo are relative newcomers to the video conferencing market, but they have designed some pretty impressive technology based on the h.264/SVC standard. Their software delivers high quality video conferencing over low quality Internet connections. If you want to know more checkout a demonstration video on their website. AttendAnywhere has taken this raw technology, reconfigured it for a shared environment and built a management layer on top to enable people to easily setup and join meetings.

Okay but what is it like to use?

Even if something is cheaper than the competition and technically superior it still has to work well and look good to be accepted. Joel Spolksky's recent RailsConf 08 keynote hammered this point home (if you have not heard this talk check it out).

"Great software has three components... making people happy... obsessing over aesthetics... and observing the culture code."

Joel Spolsky, RailsConf 2008
8:25 - 8:35

As far as AttendAnywhere goes the overall experience is good, but it is still a little raw and in some parts muddled. This can be attributed to two things: the company is undergoing a tricky migration of business models, and the on-demand Vidyo service is very new.

Prior to offering on-demand video conferencing AttendAnywhere's primary business was distributed events management (primarily in the health-care sector). The problem is this side of the business is quite distinct (and harder to understand) than their more generic offering. Unfortunately rather than offering two completely distinct services the two are intertwined and compete for attention on the same page. Whilst a minority of existing users may like this, new Vidyo-centric customers will probably find this "other stuff" more than a little baffling.

But all is forgiven, the video conferencing really does work!

The Vidyo component is very new (i.e. just out of beta) but generally excellent. Currently the client is Windows only, but it is built in Java, so in theory it could be ported to OSX and Linux. Installation is a snap because when you select to join an AttendAnywhere meeting the software downloads and installs automatically so long as you have Java installed (thank you Java Web Start).

An average trans-Tasman Vidyo meeting. The white box at the very front is the microphone (click to enlarge)

Video quality does depend on the hardware and bandwidth you have at your disposal. AttendAnywhere has a good technical rundown of what you need to see good results. The examples you see here are taken from my two year old 20" iMac running Windows. On occasion I have also used a MacBook Air to achieve a similar outcome. In both cases I have used Apple's built in iSight cameras without any issues.

Technical details aside the Vidyo client is very straight forward to use. It has a single row of buttons along the top for controlling screen layouts, screen sharing, volume and not much else. In an Apple-like manner it seems to "just work", and for the most part this is the case.

The value of a good, noise cancelling microphone

One thing that needs mentioning is the value of a decent microphone. Many webcams have microphones built-in, but when it comes to anything serious you really need to splash out on a decent, noise canceling unit. The ClearOne CHAT 50 is very good for a group of people, but when by myself I use a Logitech microphone and a pair of iPod earbuds (to stop audio feedback).

The organisation and network-centric paradigm

The AttendAnywhere web application forms the glue which changes Vidyo from a simple Skype competitor to a core business application. AttendAnywhere accounts are free and when you sign up you receive complimentary Vidyo minutes.

My company's profile complete with a photo of my desk (click to enlarge)

Within the system you can create your company and various types of networks. The concept of a network in AttendAnywhere is very similar to a Facebook group, except instead of sharing gossip you can easily share meeting invitations or begin 'ad-hoc' meetings. The privacy settings of networks can be tuned to cover a range of needs, from organisational departments through to special interest groups.

Networks can be associated to an organisation whilst still including interested third-parties (click to enlarge)

Preparing and joining a meeting

Setting up meetings is AttendAnywhere's bread and butter. Unlike your average calendar application the focus of meeting invitations is identifying how a geographically distributed group of people will come together. A big part of this involves managing the limited video conferencing resource that most organisations have available. Whilst it is common for consumer hardware to ship with webcams the overwhelming majority of corporate systems do not. Over time this will change, but in the short to medium term, business video conferencing will still involve groups of people huddling around dedicated computers and projectors.

Accepting an invitation means identifying where you will be joining from (click to enlarge)

When invitations are sent out the recipients must identify not only if they can attend but where they will be coming from and how many extra people can join them. This grows the video conference resource pool and makes it easier for those who cannot attend from their own computer to find someone nearby who is.

The cost of taking part in a meeting room can be offloaded to the parent organisation (click to enlarge)

Another important factor that AttendAnywhere takes into account is how the cost of the meeting will be covered. A single organisation can cover the entire cost of the meeting, or costs can be divvied up on a participant basis. For freeloading consultants like myself this is great because it means I do not need to pay (or seek reimbursement) to attend other people's meetings. I can also see this being very handy in architectural projects where one party (i.e. the client or lead-contractor) agrees to cover all project meeting costs.

The downer: interface overload

A business application's interface should strive to stay out of the way. This is because the goal of the person using it is to get in and get out - they are not interested in pausing to take in the view. Unfortunately AttendAnywhere's current web interface has not had the time to go through these optimisations and is still very much a '1.0' experience.

The main issue is that there is too much 'interface candyfloss', words for the sake of words and options repeated in various places for no obvious benefit. For example having an option that reads "Create a network" with a subtext of "Create a new network" does not add anything except another centimeter to the overall page length. In contrast if you take a look at the Projjex interface the majority of the screen is made available for things you are interested in. They have also used tool-tips to introduce newcomers to functionality without cluttering up the seasoned user's experience.

The Projjex interface is concise and makes excellent use of tool-tips (click to enlarge)

Did I hear someone say makeover?

How much of this candyfloss can be trimmed from the web experience you ask? Well after a few weeks of using the service I have some ideas. Take for example the following (typical) AttendAnywhere screen:

Before: The existing interface: 80% of which I don't use or understand (click to enlarge)

I took this screenshot into Photoshop and took a knife to all the things I did not use or had no interest in. The result was this tight little number:

After: My wish: Get rid of the textual candyfloss and stuff I don't care about (click to enlarge)

Okay it may not look radically different, but by stripping out the candyfloss and deleting the obtrusive menus the important things are a lot clearer (to me at least). Not only is it easier on the eye but you get the added benefit of having everything fit within a single browser window.

Conclusion

The AttendAnywhere/Vidyo combination is really promising. Whilst there is a long road ahead and it has plenty of maturing to do, the service provides an excellent balance between price and performance. Companies like AttendAnywhere stand to profit from the hesitancy of mainstream brands such as Skype and Apple to enter the world of serious video conferencing. If you live in the Australasian region and are interested in checking out AttendAnywhere/Vidyo go ahead and sign up. I can't guarantee flawless results, but if your experience is anything like mine you will be pleasantly surprised.

Projjex: Online project collaboration for the rest of us?

David — Sun, 24 Aug 2008 12:53:59 +0000

I have recently been checking out Projjex, a relative newcomer to the online project/collaboration/document management market. The "cool kid on the block" when it comes to this field is 37signals' Basecamp, but it seems like the two companies are after very different audiences. Basecamp is synonymous with "Web 2.0" and has a look and feel that suits this crowd. In contrast Projjex seems to be going after the older (more mature?) audience with an offering that emphasises practicality over design.

My sweeping generalisation is that if you read TechCruch religiously then Basecamp is for you, whereas if you have never heard of TechCrunch (or prefer 'real news') then Projjex is probably more to your liking.

The genre clash dilemma

Before I go over Projjex I need to get a couple of things off my chest. The problem I have with these project/collaboration/document management tools is that they are trying to do too much with too little. It is like a summer blockbuster that cannot decide whether it is an action, comedy, drama or romance film and just ends up being nothing. Pulling something like this off is almost impossible and at some point the software developer has to put a stake in the ground and focus their efforts on one primary thing. For example when you take a look at the 'traditional' desktop each one of these functions is handled by a dedicated product:

Project management: Microsoft Project
Collaboration: Outlook, Notes, Groupwise, Apple Mail...
Document Management: Sharepoint, Alfresco

Every one of the above products has a very deep feature-set and whilst it is possible to monitor projects in Sharepoint or manage documents within Outlook, these capabilities are purely secondary and often accidental.

In contrast both Projjex and Basecamp apply the 80/20 principal (see Joel Spolsky's critique) in order to cover such a broad problem space in a realistic amount of time. On one hand this works well because it provides a slick (a.k.a. spartan) user interface. However on the other hand this limited functionality soon starts coming up short as people gain an understanding of the product. Personally I would much rather use (and pay for) a deep product that seriously tackled the one problem space rather than investing my time in a service that did a little bit of everything poorly.

For example the feature that makes Microsoft Project "kick ass" is its ability to visualise the abstract world of project management. At meetings or in emails nobody is interested in seeing a list of milestones or tasks - what everybody wants to see is the really pretty gantt chart clearly illustrating the process spaghetti going on. Unfortunately what software developers see as important (and easy) when they come to Microsoft Project is the list of dates and tasks. Consequently what we end up with in tools like Projjex and Basecamp is that text-based list of things we all hated looking at in the first place. Personally I think the product that will kick Microsoft Project of its pedestal is an offering that somehow does away with those boring lists entirely.

A consequence of this generalist nature is that these project collaboration services have a walled garden approach when it comes to interaction because the underlying assumption is that every person associated with the project will be a signed up member of the service. However if I am using Projjex and a business partner has chosen Basecamp we should not need to have accounts on both systems to collaborate on different projects. If these services were more focused then I am sure more effort would be placed on getting them working together (e.g. Basecamp for collaboration and Projjex for project management). Unfortunately because every one of these companies are going for the same 'generalist' pie, there is no room for negotiation or partnership. I am sure this tune will change once a major player enters the arena, sending the smaller companies clammering for higher ground. Which leads me to my second thing...

Where is Google?

This project/collaboration/document management market seems ripe for Google to come muscling in. On paper it would seem like a no brainer for a Google Projects like service:

It would tie in nicely with their Google Apps offering.
GMail, Google Docs and Google Calendar would integrate perfectly.
It would support open source development and compliment Google Code.
There is an opportunity to do something really different.

At the back of Projjex and 37signals' minds must be some lingering uncertainty around if (or when) such a service will be released. If past events are any indication the result would not be good as it would draw users away from these smaller services and probably force Microsoft's entry into the online market. As a potential user this is a problem because you do not want to entrust a business critical task on a service that will be run out of business (or at the very least eclipsed) by a major player in the (perhaps) not too distant future.

Why not swim with a big fish?

What we have yet to see is any of these project collaboration tools take the task of desktop/web integration seriously. For example if Google ever do release a project management tool that integrates seamlessly with GMail, GCalendar, etc. would it not make sense to be the competitor with excellent Outlook and Sharepoint support? Alternatively by deeply integrating your product with Google's services it may lead to hesitation before the release a competing product (see Saleforce.com & Google).

The problem with this theory of course is that it breaks the 80/20 rule. If something is to integrate seriously with any of these applications it by definition must be a deep product. Compounding the problem is that building this integration takes far more effort than adding extra features to your proprietary web-interface. Unfortunately the fact of the matter is that integration trumps aesthetics and functionality nine times out of ten. An online project management tool that integrates seamlessly with Outlook is far more valuable to a heavy Outlook user than one that does not.

Only time will tell whether Google or Microsoft enters this market and if they do whether smaller services like Projjex can survive or even flourish. In the meantime lets take a look at how Projjex shapes up as standalone service within a relatively immature market.

Projjex at a glance

If the look of Projjex had to be summed up in a couple of words for the catwalk it would be "subdued practicalism" (note, I don't think practicalism is a real word).

The fact that Projjex is not glitsy is a matter of taste, but personally I believe it is a good thing. When it comes to business critical tools what you are after is something that works when you need it and gets out of the way when not. On this scale Projjex performs pretty well, it is uncluttered and designed with an eye to getting things done first, and looking good second.

Whilst the introductory videos did a very good job of introducing the functionality and setting the tone for the product my initial experience was not very welcoming. When I first went to log in with Safari I was presented with this rather intimidating message:

Note to Projjex developers: If a site works in Firefox 2/3 it will pretty much work in Safari or any other Webkit-based browser. Sure, go ahead and display a warning message if the person is using Netscape Navigator 4, but in the case of Webkit if the only issues are going to be minor bugs then the warning should be more subtle. As far as I could tell things worked fine with Safari except for a couple of negligible graphics issues, all of which looked more like bugs with the site rather than the browser.

What works

Tool-tips

It was a pleasant surprise to see lots of useful tool-tips appear on each new page. Whilst it may seem trivial these aids helped point out things that first time users who never read manuals should know about.

Dialogs instead of page loads

The project creation and data-entry tasks were all pretty straight forward for anyone used to using applications like this. Rather than using lots of different pages Projjex opts for a dialog model that is very reminiscent of a desktop application. This is a wise move because not only is it familiar, it also feels more responsive and more consistent.

Time-sheets

One user interface feature I really liked was the ability to quickly fill in time-sheet information. For this Projjex uses a hybrid spreadsheet/dialog approach that is not only fast but very easy to understand. Time-sheets are a necessary evil and with this in mind it does a very good job.

Minute taking

Lots of applications let you setup meetings, but very few follow through with emailed minutes and attendance. The idea is that as you are having your meeting you record changes to the project (i.e. add requirements, update tasks, etc.). Once the meeting finishes you 'close' the meeting in Projjex and it generates a set of minutes based on the changes made during the meeting. This is a really good idea because it closes the loop between organising a meeting, recording the changes and notifying everyone.

Simple yet sophisticated security

For every entry created in Projjex you can assign sharing rights that range from completely public through to private. There is also an option to share entries only with those in your business. Whilst it may appear simple, the fact that these permissions can be inherited or individually set provides a lot of flexibility when it comes to mapping out your project with others.

What doesn't

The dashboard

Dashboards are the one place on any system where things need to be visually appealing. I would say the most successful dashboard ever is the one provided by Microsoft Outlook. That alone has probably helped sell more copies of Exchange than any other function or marketing campaign. The dashboard is your first impression of Projjex and to say it is underwhelming would be an understatement:

In contrast checkout this one from Salesforce.com:

The dashboard needs to be the place where all this abstract, textual data is aggregated and presented in a clear and visually appealing manner. Currently as it stands the Projjex dashboard is something you want to get away from as quickly as possible because it just feels so stale.

The dashboard is also an excellent place to integrate with other systems, for example an easy place to start are HTML widgets for websites such as iGoogle and Facebook. Beyond that is the fragmented desktop widgets/gadgets environment (Google Desktop, OSX, Yahoo and Vista). The dashboard should arguably be the first and last place you visit during the day, so striving to make it ubiquitous and appealing is the goal.

Lack of visualisation

Beyond the dashboard is the lack of any serious charting functionality to enable project data to be summarised and visualised on a single printed page. When it comes to projects and communication the ability to stick a gantt chart in front of people's faces is the single best way of getting them to understand the overall project and where they sit in it. By not answering this problem Projjex are forcing people to export their data into another, competing product (e.g. Microsoft Project).

Beyond gantt charts is the lack of visualisation of documents. When all your documents are stored on a remote server it is important that you can quickly see the right file without having to download it completely. The fact of the matter is that people never name their files intelligently or take the time to adequately describe them with meta-data (e.g. 'This document describes...'). Projjex needs the ability to quickly preview contents of commonly used files in the same manner as Alfresco Share. For example image files should have thumbnails generated and text documents a preview of the first page rendered.

A screenshot of Alfresco Share's document previews

In conclusion

Overall Projjex is a solid service that contains a couple of really good features (meeting minutes and time-sheets). The interface is very practical and works well in general. Projjex needs to focus on integration with third-party services and develop the depth of functionality in one or two key areas. If you are working in a small team and looking for a low-cost, project/collaboration/document management service then Projjex may fit the bill. However be warned, if you are looking for Web 2.0 glamor, Basecamp maybe more to your liking.

Wikis in plain english

David — Thu, 14 Jun 2007 10:59:52 +0000

This is a nice little video for explaining to those who do not know or understand what wiki are without using words of more than two syllables. It does not push the theoretical envelope in any way but it is fun to watch all the same.

Second Life, AEC collaboration and Ryan Schultz

David — Mon, 11 Jun 2007 10:39:01 +0000

Last week I had a pretty interesting email conversation with Ryan Schultz about Second Life (not to be confused with First Life) and its potential for architectural collaboration. In a nutshell I am not a fan of Second Life. Certainlly one day 3D will play a much stronger role in our experience of the Web but I don't believe Second Life is 'it'. If you are interested in reading our conversation then Ryan has done a pretty good job of presenting it on his Studio Wikitecture site. I come off sounding reasonably intelligent which I guess means those long hours of watching Discovery Channel are beginning to pay off.

I can’t help but feel the online 3D market is at the same place as the 2D online world was between 1990 and 1995. Back then we had walled gardens like Compuserve, AOL and even Microsoft Network (which originally shipped with Windows 95). Whilst these communities had a lot of money behind them the rapid adoption of open HTML and HTTP concepts quickly usurped them.

When it comes to 3D architectural collaboration I really do not see much of a role for entirely immersive worlds like Second Life in a business context. Immersive worlds like Second Life or World of Warcraft have a tonne of conceptual baggage that is part and parcel with the whole experience. Your average business person, be it client or architect, just wants to focus on the job and hand which is interogating and understanding the building design in a clear and comprehensive manner. 3D is just one avenue for this exploration, conventional 2D architecture drawings and conversation is no less important. Because of these demands architectural collaboration will continue to trend towards standalone and portable 2D/3D media such as DWF and PDF rather than moving into online worlds. These are relatively lightweight and immediately accessible mediums compared to Second Life, where just finding the architecture could prove problematic for unaccustomed users.

Another undiscussed factor which is just impossible to shake off is the stigma associated with any entertainment-centric technology when applied to a business problem. For ten years I have been watching demonstrations of how architecture can be 'experienced' within a 3D game engine yet nothing has really come out of it apart from a lot of promising demos and the odd chuckle when a reviewer gets bored and decides to virtually shoot the other attendees. Whilst it may seem a little silly I think deep down many people just cannot take these derived tools seriously (although they would never admit it). This may change over time, especially as the generations who have grown up with Doom and Quake begin to ascend corporate ladders. However until such a time I think any architectural visualisation experience centered around entertainment or gaming technology is going to struggle for credibility in what is in general a fairly conservative AEC market.

Why Autodesk should 'Open' DWF

David — Wed, 07 Mar 2007 22:24:39 +0000

Beyond the Paper's Scott Sheppard recently pointed to McDwiff as the first partial example of a Mac-based DWF viewer. Unfortunately for the DWF starved Mac community McDwiff is simply a wrapper around a WebKit browser window pointed directly at Autodesk's own Project Freewheel web service. It fails to qualify as a true desktop application for a number of crucial reasons:

It does not (yet) add functionality beyond what is present in the Web-based Freewheel viewer.
DWF files must be first uploaded to the Autodesk web service.
There is no off-line mode or local caching to improve performance.
The lifespan of the software is entirely dependent on the existence of the host service.

Note: These limitations are not the developers fault as they have obviously only just initiated the project. It will be interesting to see where they go from here.

Looking at McDwiff and Project Freewheel got me thinking about Autodesk's direction when it comes to DWF. Unlike many AEC data format categories what constitutes the dominant 2D/3D design information exchange format has yet to be decided. However things are beginning to change with a battle brewing between Autodesk's DWF and Adobe's 3D enhanced PDF. Unlike pure data formats such as DXF, DWG and DGN goal of a design information exchange format is to provide AEC professionals with the ability to deliver digital building design information safe in the knowledge that any recipient will accurately experience the design in the manner intended by the author.

Why is such a format important?

With the rapid adoption of the Internet within business AEC professionals are conducting an ever growing portion of their design collaboration online. Central to this collaboration is the 2D documentation and 3D models that visually describe the outcomes of this design process. The unfortunate dilemma faced by AEC professionals is exactly what format to use when exchanging such information? There are a broad range of potential formats currently available but they all have their limitations as illustrated in the table below.

Format	Benefits	Limitations
Bitmap Image	Broad software support Consistent display across platforms	Limited accuracy No intellectual property protection Only supports 2D imagery
Vector-based Image	Accurate display of data Relatively broad software support Consistent display across platforms	No intellectual property protection Only supports 2D vector-based imagery
Office Productivity Document	Broad software support Relatively consistent display across platforms	Limited/no intellectual property protection Only supports 2D imagery and data
Traditional 2D PDF	Broad software support Consistent display across platforms Intellectual property protection	Only supports 2D imagery and data
Flash Animation	Supports 2D and 3D data Intellectual property protection Broad reader support Consistent display of design elements across platforms	Limited printing functionality No AEC specific creation tools
Proprietary 2D/3D CAD format	Supports 2D and 3D data	Limited/no compatibility across different software platforms Potential for inconsistent display of design data Limited/no intellectual property protection Conveys the entire digital model rather than a subset identified by the author
Standard 2D/3D CAD format (DXF, OpenDWG, OpenDGN)	Broad software support Supports 2D and 3D data	No intellectual property protection Conveys the entire digital model rather than a subset identified by the author
Propriety Building Information (BIM) Model	Supports rich AEC semantics Manages 2D, 3D and text-based data	No compatibility across different software platforms Limited/no intellectual property protection Conveys the entire digital model rather than a subset identified by the author
Standard Industry Foundation Classes (IFC) Model	Supports rich AEC semantics Manages 2D, 3D and text-based data Consistent display of design elements across platforms Industry standard	Limited software support No intellectual property protection Conveys the entire digital model rather than a subset identified by the author

From the perspective of an AEC professional the ideal format is one that can communicate 2D and 3D information that any recipient can consistently view without misappropriating the author's intellectual property.

The limitations of traditional 3D formats

Conventional 2D or 3D models cannot fill this collaboration need because they are focused on recording design data rather than exchanging design information. Information exchange is the communication of context specific data for dissemination in a certain manner, for example an A3 sheet of elevation drawings prepared to a scale of 1:100. In contrast data exchange is the communication of an entire data-set for interpretation in the manner of the recipient's choosing. There already exist a range of common AEC data formats such as DXF and the semantically rich Industry Foundation Classes. Whilst these will always be of tremendous value within the industry, when it comes to exchanging design information the malleable properties of these pure data formats limit guarantees which can be placed around communication consistency and protection of intellectual property.

The importance of consistency & intellectual property protection

Consistency is crucial in AEC information exchange because the intention of most design documentation is to act as blueprints for a physical creation. If the exchanged digital documentation is not consistently presented to all participants the design team will loose confidence in the medium and be forced to use conventional (i.e. paper-based) information exchange methods. Traditional data orientated 2D/3D formats provide no guarantee to participants that the various CAD applications available will display the parsed model consistently, if at all. To resolve this issue design information formats and their associated reader applications employ measures to ensure that information exchanged with team members is displayed in a consistent manner across all platforms.

Increasingly for many AEC professionals the digital model is the lifeblood of the design process and the source of most chargeable activities. Literally giving this model to untrusted members of the design team could compromise future income streams, devalue their role in the design process, or raise legal liability issues if the model was used inappropriately in such activities as simulation and engineering studies. Formats for design information exchange protect intellectual property by enabling the author to communicate a limited subset of the entire digital model in a manner that cannot be reutilised for anything other than its intended purpose.

The combination of these unique requirements has resulted in the evolution of two similar but competing formats from Autodesk and Adobe: DWF and PDF with 3D extensions. Whilst each have their own strengths and weaknesses they ultimately have their eyes set on the same goal: to become the dominant design information exchange format within the AEC industry. Central to success is the ability for both formats to become ubiquitous and operate above traditional concerns such as operating system, hardware device and CAD vendor.

Format ubiquity and the success of PDF in the world of 2D

Adobe's PDF format has achieved a level of platform ubiquity in the 2D documentation space that DWF and 3D PDF are striving for in the 2D/3D design information exchange arena. This ubiquity has been achieved through a couple of related factors. Firstly PDF's creator Adobe supports native PDF readers on a range of hardware and software platforms. Whilst it is unsurprising to find the Windows version receives the most attention, users of other platforms are not left feeling isolated when it comes to inclusion of new features and ongoing support. Secondly a rich developer ecosystem has increased the acceptance of PDF from merely a proprietary (yet open) format, to a vendor neutral and soon to be internationally standardised platform for business information. There are literally dozens of non-Adobe sponsored, open and closed source implementations of PDF libraries, readers and writers written for a variety of different computer languages and applications. This diverse ecology ensures that even if Adobe were to pull support for some, or all aspects of PDF the format itself would remain viable for years to come.

Time will tell whether Adobe's 3D extensions to PDF will receive the same platform and developer support as its older 2D equivalent. Considering the 3D extensions are being standardised during the forthcoming ISO certification process there stands a very good chance of the extended format gaining broader platform and developer support in the near future. Considering PDF's current momentum DWF faces a difficult challenge if it wishes to become the dominant design information exchange format. Fortunately for DWF's chances its creator Autodesk is not idle when it comes to this challenge.

Autodesk's DWF initiatives

Unfortunately for Autodesk DWF has yet to reach the same level of platform nirvana held by 2D PDF. However they do have five initiatives underway to encourage adoption of the format within the AEC industry:

Extensive DWF support is built into many existing and new Autodesk products.
A revised DWFx format has been released which is built on top of Microsoft XPS technologies. This benefit of this format is that is can be read by Windows Vista without the need to install a dedicated viewing tool.
Recently Autodesk Design Review was released for free alongside existing DWF Viewer and DWF Writer applications for Windows.
A DWF toolkit has been made available for software developers on Windows, Mac and Linux to write for and integrate with DWF applications.
Within Autodesk's labs they are working on Project Freewheel, a Web-based, hosted DWF viewer.

Gauging success through market significance

Unfortunately for Autodesk the ultimate success or failure of DWF will not hinge on how well it is implemented within their own product line. Instead the deciding factor of its success will ride on its level of uptake within the AEC industry when compared to the use of PDF and the myriad of other traditional format options. Market significance will depend on three equally important factors:

The ability of Autodesk to deliver compelling reasons why AEC professionals should use DWF instead of PDF or traditional design data files.
The capability to read DWF in all design environments on any potential platform.
The proliferation of DWF beyond an Autodesk-only software mindset. In essence the concept of DWF must become 'bigger than Autodesk'.

If Adobe can leverage PDF's existing user and developer base to become the mainstream 2D/3D design documentation format Autodesk risks losing one advantage it has held within the AEC industry; dominance in the file format arena. In the past Autodesk has used its control of the legacy DWG format to assist software sales and deter competition in the 2D/3D CAD space. Two such examples of this have been the encryption applied to DWG by AutoCAD 2004 and more recently the copyright lawsuit filed against the Open Design Alliance for their support of TrustDWG. Undoubtedly whichever vendor can achieve a similar level of format dominance in the design information exchange field will hold greater leverage when it comes to future sales, marketing and development activities.

Initiatives that appear to be working

Two of the five Autodesk DWF initiatives appear from the outside to be working very well. Integration of extended DWF capabilities within a range of Autodesk applications is signaling to the industry that not only are Autodesk serious about DWF but it is also a very capable format in its own right. The availability of free reader and writer applications ranging from the complex but very capable Autodesk Design Review down to simple DWF reader/writer tools are also encouraging users who do not use or have access to the latest Autodesk applications to experiment with DWF on a limited yet worthwhile basis.

DWFx: clouding the water or lighting the way?

Of the five initiatives I am least certain about the establishment of DWFx, the derivative of DWF based on Microsoft's XPS (a.k.a. 'PDF killer') technology. The problem DWFx poses is that it makes the process of explaining to AEC professionals what DWF is and why it is useful more complicated. Rather than having one format to choose from there is now two that do exactly the same thing but have varied levels of support in different software versions and operating systems. Whilst there are some fairly valid technical decisions behind the establishment of DWFx its timing seems geared more toward product release cycles (i.e. Windows Vista) than any industry call for a DWF successor at this point in time. The telling question which remains to be answered is how the consumers of this technology react (if at all) to these diverging DWF formats, especially considering the imminent entrance of 3D PDF into this field.

Freewheeling Freewheel and its effect on the developer community

After looking at Project Freewheel for a while I have come to the (maybe wrong) conclusion that it is an excellent concept that in the long run is actually doing more harm than good to the DWF developer ecology. What Autodesk should be focusing on is providing application and Web developers with a tool-set to create their own Project Freewheel rather than building functionality on top of it. McDwiff is an obvious example that the current DWF developer toolkit provided by Autodesk is not what high-level application developers want. What is needed is an easily deployed DWF engine available for any platform that those interested in working with DWF can quickly utilise in a few lines of code. Ironically Project Freewheel provides this functionality but its ties to a central website limits developer potential.

How can Autodesk provide these development tools when they do not have the resources or experience to support multiple platforms? The answer is they cannot, but what they can do is encourage other developers to help them out in achieving this task. Although the DWF developer tools are available free of charge they are not easily accessible under a common license. Instead developers are forced to complete a rather large form and agree to a license which essentially states you can do anything with the code as long as you acknowledge the changes made when distributing the software. Forms and unusual licenses are barriers to developers, especially those used to working in an open source world of anonymous CVS and free (as in freedom) license models.

With the kit already available without cost under a relatively open license agreement why not take the next step and establish a SourceForge project for the software and release it under a commonly understood (LGPL or Apache) free license? After all it is not uncommon for large proprietary software companies to do such a thing. The benefit of the move would be to send a clear sign that Autodesk is serious about fostering a developer community. This extended developer community would be free to create DWF-centric applications and fork or port the existing DWF code-base in a variety of ways. The short term benefit of this action is that the DWF toolkit would be turned from an isolated download into the basis for an entire online development community similar to that of the Open Design Alliance's OpenDWG and OpenDGN initiatives. In the long term the opening of the DWF toolkit could be used to signal the tip of a very large, open source DWF iceberg.

Autodesk should not simply stop at freeing up distribution of their DWF toolkit. Instead this action should be used as the prelude for the open sourcing of the DWF Viewer and Project Freewheel code bases. With Autodesk Design Review now available free of charge Autodesk's DWF Viewer is of no real value from a commercial product perspective. If opened to third parties its code-base could be of tremendous value as a starting point for DWF readers on other platforms such as OSX and Linux. Whilst it maybe difficult to believe there are communities of developers that take pleasure in getting Windows centric applications like DWF Viewer running on multiple platforms. Likewise the goal for Project Freewheel should be to act as an open technical demonstration of what can be achieved with DWF on the Web. Whilst it is easy for Freewheel to be viewed as a potential money maker for Autodesk in reality the concept's true value will only be realised when third-party developers can embed similar functionality within their commercial or in-house developed Web applications operating behind corporate firewalls. Consequently instead of productising Freewheel, Autodesk's goal should be to inspire Web developers to write similar DWF manipulation functionality in PHP, Java, Ruby and other Web languages which may evolve. It is only through actions such as this that Autodesk will be able to proliferate DWF technologies rather than simply monopolising their use in the interests of short term profit.

Conclusion

The looming DWF vs PDF format debate will be beneficial to the AEC industry as the heated competition will no doubt enable new levels of digital collaboration. Currently it is difficult to say which format will become dominant but undoubtedly whichever vendor fosters the strongest developer ecosystem will hold a significant advantage. With this factor in mind Autodesk should be actively nurturing the growth of its external DWF developer community by removing of all barriers to entry. This could be achieved through the release under a common open source license of a select few DWF-centric technologies within a community friendly environment such as SourceForge. Through this process Autodesk would stand to grow an even stronger DWF developer community and in the process improve DWF's chances of becoming the ubiquitous design information exchange format.

Following up on CAD Collaboration

David — Thu, 01 Mar 2007 10:21:41 +0000

I have had a fairly positive response to my last CAD Collaboration post. Feedback has highlighted a couple of areas that need clarifying and developing a little further.

On Snapshots and Deltas

Paul Wilkinson of the Extranet Evolution blog put up a fairly long post that discussed many aspects of the article. Of most interest was his comments on the snapshots and deltas idea, significantly the fact that a similar approach had been adopted three years ago by BIW Information Channel from BIW Technologies.

BIW’s Accelerated Transfer pack condenses file revisions to a fraction of their previous size allowing faster transfer – up to ten times faster in the case of some files.

In the case of BIW it used delta encoding as a means of increasing data transfer speeds to remote, poorly connected places such as construction sites. This is slightly different to the concept I proposed because it deals with binary deltas rather than deltas at an abstracted digital model level. Binary deltas are great at a file level because they do allow changes to the same file be transferred somewhere very quickly. The problem is that binary deltas are intended to convert a file to a carbon copy of the remote source file from top to bottom.

Using delta's in a collaborative digital model is all about exchanging design intentions (i.e. rotated wall A 45 degrees) so that the model is updated but many properties of the actual file remain the same. In many respects it is more complex process than a low-level delta courtesy of a tool like diff. However this added complexity provides the benefit of enabling users to choose what design intentions they wish to inherit from other team members without worrying about the associated digital baggage that accompanies their team member's file.

Paul also raised this interesting point:

But what we need, as a commercial software developer, is some customer demand to make such R&D activity commercially viable - as with BIM, there is no huge clamour (yet) from project teams for collaboration tools to support this way of working.

Supply and demand is an interesting thing. Posing to a group of people whether they want to adopt a certain way of working without a having that method productised and easily accessible will always result in negative feedback. Twenty years ago I doubt researchers would have received a positive response if they asked architects to adapt their processes to meet the needs of a hypothesised 'Building Information Model'. The fact of the matter is that it has taken compelling yet somewhat risky tools like Archicad and Revit to convince industry professionals that a BIM approach has significant advantages over conventional CAD. This change of heart has not come about because professionals have come to terms with what the concept of BIM. Instead most have been sold on the idea because the products available have shown themselves to be more efficient and flexible than alternatives. I think a snapshots and deltas approach has significant advantages which I have previously described, but it will take the availability of a compelling product before the majority of users exhibit any degree of interest.

So how does a Satellite approach work again?

A link to the article was posted on the VectorWorks forum thread which was provided the initial spark. It received the following comment:

It still remains a bit of a mystery to me how the "master/satellite" system is actually managed. I'm not aware that in writing to disk it is possible to write only selected portions of a file (I may be in error in this belief!).

In the updating process, does software on the server take master and satellite into one file, sort each object for permission and time stamp, then integrate into one file to overwrite the original?

At the heart of the satellite model is usually a permissions system that allows only one user to lock a selected area for editing. Other people are still able to view this area but for simplicities sake write privileges are usually kept to one person. Minimising write privileges negates the need to have a complex synchronisation process where one set changes are accepted or declined in place of another. It is certainly possible to write an application that deals with these issues of change authority but it is difficult to justify given its negative impact on application efficiency and ease of use.

Because of its simple permissions system synchronising a satellite is a simple task of overwriting the area assigned to the user within the master model with what is present in their satellite copy. Once this is complete the updated areas of the master not under the user's control are copied to the satellite. The process of updating the satellite can be as simple overwriting its entire contents with what exists in the master down to fine-grained synchronisation of new and updated elements.

It is perhaps easiest to think of the process like the children's game where each child is allowed to draw on a specific side of a folded-up piece of paper. The piece of paper is handed around each of the children in turn to draw on and after everyone has had a turn the unfolded end result is revealed (usually to much hilarity). The only significant process difference with a satellite approach is that instead of drawing on the same piece of paper copies are distributed for working on and collated into a master version at a set time.

Of course one thing to remember about a digital model is that its unique 'sides' do not have to be constrained by a physical space such as a kitchen. Instead these areas could be specific elements that occur throughout the model, for example 'all the windows on the second and third floors'.

CAD Collaboration

David — Mon, 26 Feb 2007 05:00:01 +0000

(or how I learned to stop worrying and love ambiguity)

This post covers the issues surrounding CAD collaboration and past approaches to resolving it. It then concludes with a concept of how decentralised digital model development could be undertaken in a manner that reflects the ambiguous environment in which collaborative design is experienced.

The Problem of Digital Model Orientated Collaboration

Modelling an architectural design in CAD almost never occurs in an isolated environment. Typically work is undertaken with at least one other person simultaneously in order to meet development deadlines. Unfortunately issues arise when participants wish to simultaneously change the same design element, or a set of design changes inadvertently effect another aspect of the digital model.

Recently I was asked to comment on a debate that was raging in the Vectorworks forums related to its minimal set of collaboration functionality. Whilst the forum thread initially begun as a feature request it soon evolved into rather heated debate over how collaboration functionality in CAD should function (if at all). Central to this online debate was the role internal offices processes and politics held in the success of a collaborative digital model. Whilst this is typically the most visible factor we must also keep in mind the mere introduction of digital models has significantly altered our collaboration psyche.

Representational Shift

Before CAD collaborative design development had minimal effect at the drawing level because it was understood that each sheet was an isolated representation of the proposed design. Irregularities on different sheets were accepted as a byproduct of the chronological drawing process or later amended with supplementary information. In a digital world we are unwilling to accept this representational ambiguity for two reasons: either the integrity of the digital model is so important to design documentation that it cannot be ignored, or psychologically the consumers of the data expect digital models to be consistent because 'the computer is never wrong'. Whichever expectation holds true it illustrates a subtle representational shift from drawings as a means to an end, through to the digital model as a means and end unto itself.

Perception of Precision

Conventional architectural representation is of limited precision due to the inaccuracies of the tools available and the small scale applied to most drawings to fit their chosen media, for example a sheet of A2 paper. In contrast the digital model has no defined scale and a high degree of fidelity because of a computers ability to manage large quantities of data quickly and accurately. This computing capacity raises the perception that a digital model is very precise when in fact it often has the same tolerances as a conventional drawing. As a consequence when inconsistencies are identified within a digital model they are viewed as failures of the process rather than as natural artifacts of the dynamic and inherently imprecise activity that is architectural collaboration.

Due to these representational and perceptional changes there is an increasing emphasis within the Architecture, Engineering and Construction (AEC) industry to consider the digital model as the outcome of the design process in place of a conventional set of production drawings. This shift in desired outcome has heightened the challenge when it comes to enabling multiple parties to efficiently manipulate the same digital model.

Prior Teamwork Solutions

Various methodologies have been applied to the problem of enabling teamwork within a single digital model. A summary of these high-level approaches are: linked independent files, external document management, an intelligent master with satellites and an always connected, centralised digital model. Most CAD packages take advantage of one or more of these methods to enable their users to work within a team.

Linked Independent Files

Pros: Simple, supported within a wide variety of software, low barriers to entry
Cons: High management load, no warning of external changes, external data cannot be manipulated

This is the oldest and simplest method of collaborative digital model building. Within CAD circles the process of linking is often called referencing or XREF'ing depending on the software vendor. A linked-file collaborative approach enables two or more people to work independently on different files whilst still having a reasonable idea of how the entire digital model is evolving. Due to its simplicity and relative maturity as a concept most CAD applications support some form of file linking, in some cases even across different file formats (e.g. dwg to dgn linking).

Unfortunately due to its file-centric nature linked files cannot be manipulated within the working document. Another drawback of this approach is that the simple links formed only share geometry information and ignore related meta-data such versioning information and impending design change notifications. In order to account for these shortcomings high levels of external management are required to communicate this data and resolve various issues related to access permissions and naming standards.

External Document Management

Pros: Applied on top of existing CAD platforms, often deeply integrated, provides a range of extra services
Cons: Requires purchase/maintenance of separate software, issues with lock-in and upgrade cycles

The primary advantage of using an external document management system in concert with CAD software is that it allows team members to overcome many of the shortcomings of the linked file approach without changing the CAD software users have experience with. Unlike conventional documents a digital model often spans multiple files which raises problems around data consistency and interpretation. AEC-specific document management tools have evolved to meet these issues and handle change management, clarification of naming standards and communicate digital model meta-data such as unresolved design issues. Increasingly these systems are also implementing automatic file conversion functionality (i.e. digital model to PDF or DWF) in order to increase accessibility of design information to all members of a design team.

There are two distinct forms of AEC document management system, CAD vendor specific such as Buzzsaw and ProjectWise and vendor neutral such as Adept and Eskudos. Vendor specific systems work with external data sources but their real value comes through deep integration within their respective CAD platform. Deep integration provides significant advantages in productivity and user experience through tailoring both CAD and document management experiences. Unfortunately deeply integrated tools make it increasingly difficult for team members lacking vendor-specific (and often costly) software to participate equally in development of the digital model.

An Intelligent Master with Satellites

Pros: Self contained collaboration, intelligent semantic-based permissions
Cons: Requires complex synchronisation process, steeper learning curve for new users

The evolution of Building Information Model (BIM) concepts within software such as Revit and Archicad has led to development of highly structured models capable of being edited simultaneously by multiple parties. This capability stems from the models ability to internally divide itself into a number of discrete areas which can be assigned user-specific editing permissions. In theory each user could then access and modify the same file but in practice network and disk I/O problems have limited availability and reliability. To overcome these hurdles copies (satellites) of the digital model are distributed to each user for editing on their local computer. Once the changes are complete a synchronisation process replicates the working model's changes back into the master model and updates the satellite file with other updates that have occurred within the master.

The benefit of such an approach is that all design and collaboration information is contained within the same digital file rather than being distributed amongst multiple resources on the network. Management overhead is minimised as the CAD platforms which employ such an approach understand rich architectural semantics allowing their collaborative capabilities to be relatively intelligent. From the end-user's perspective their experience is also improved as they are not dependent on network or shared resource availability and performance to undertake work.

A limitation of this and the linked file approach to collaboration is that users cannot make or propose changes to design elements beyond their set of allotted permissions. Consequently careful planning must be put into the assignment of model access rights to ensure that the team's working efficiency is not impeded. In rigid teams where responsibilities are clearly understood such a task may not be difficult, but in fluid teams this can be a significant challenge and an impediment to productivity.

An Always Connected, Centralised Digital Model

Pros: Everyone is always working on the same model, real-time collaboration, fewer management issues
Cons: Requires a constant network connection, no production systems yet exist(?)

In a completely centralised digital model all information is stored at a single location such as an internally operated server or within a cluster on Internet. CAD users interface with the model via network connected devices and a piece of client side software that displays the data in a meaningful way (think Google Earth). As all write operations are performed at a single location these design changes can be viewed in real-time by team members connected to the system.

Management decisions still need to be made over who has the permission to change what and when, but in an always connected environment it is usually assumed model locking will occur at finer level than that employed within a satellite approach. This is generally because a satellite approach encourages the reservation of editing rights on a larger area than actually required. This is because unforeseen changes may need to be made and the risk exists that another party will modify a dependency such as a wall or other relevant design element. In contrast within an always connected, centralised model editing locks can be localised around specific areas because users have a real-time understanding the digital model and the context in which they are making their design decisions.

In practice a centralised model is similar to a satellite approach without the complicated synchronisation process. Unfortunately even in a world where the Internet has become ubiquitous, maintaining a network connection is still the greatest barrier to employing such an approach. As a result there are very few, if any, production-quality CAD tools that are based solely on this architecture. The most notable examples that come to mind are the IFC Server Project and Divercity research projects, both of which never left their testing environments. Given the increasing proliferation of the Internet throughout the developed world it seems inevitable that a CAD product based on such a collaboration architecture will reach the mainstream in the not too distant future.

Hybrid Approaches

CAD applications can mix and match these various collaboration architectures to reach a balance that suits their user's requirements and environment. MicroStation for example can make use of linked-file and central database collaboration architectures. Whilst most CAD applications store the digital model in memory and then save the changes to disk periodically MicroStation places its digital models within a relatively simple and open, file-based database system. Changes are recorded directly to disk and being a database multiple parties to read and write to the same resource (similar to Microsoft Access's JET back-end). Consequently MicroStation can employ a central database approach to collaborating or link independent file resources together in a more traditional manner. It must be noted that the central database collaboration functionality available within MicroStation is relatively limited compared to systems developed purely around such an approach but the fact it can operate in such a configuration makes it a very versatile collaboration platform.

Accepting ambiguity when the 'computer is always right'

Attaining an absolute answer from a process that is in flux until the paint literally dries is a difficult proposition. In the teamwork architectures described this need is met by having one 'correct' digital model around which we go to great lengths to preserve. Central to this mindset is that a digital model should be 'more correct' than a traditional drawing. Unfortunately at the end of the day the models we develop are just best guesses based on the information we had on hand at the time of authoring. If for some reason the context behind those guesses change, for example a wall is repositioned, it is the process by which we can adapt our design intentions to meet these changes that should be more important rather the processes followed to maintain a 'correct' digital model.

An alternative approach – snapshots and deltas

Assuming for a moment that the computer is not always correct how do we work collaboratively on a digital model in a manner that embraces this ambiguity yet still allows us to be productive? I don't have a definitive answer but what follows is my idea on how this could work based on an architecture that is distributed rather than relying on a single, all powerful point of reference.

Before explaining my alternative approach two I.T. concepts must be introduced: snapshots and delta encoding. A snapshot is a captured moment in time during the life of a piece of data. It is commonly used to enable the backup of data that is undergoing constant change such as databases. Delta encoding is the process of recording only the changes that have occurred to a piece of data over a period of time. It is more efficient than storing two different copies because generally data manipulation is a subtle affair (we add a door or move a wall) rather than an event which is completely destructive (the entire model gets deleted).

With these two concepts in mind my intention is to now describe a methodology for digital model collaboration that attempts to satisfy the seven Project Information Cloud principles of:

Simplicity
Modularity
Decentralised
Ubiquitous
Situational Awareness
Context Sensitive
Evolutionary Semantics

The aim of the approach outlined in Figure 1 is to provide an intelligent way of understanding, comparing and merging distributed changes to the digital model. A secondary objective is to allow the participants to operate independently without tight managerial control which can be a major hindrance to productivity and creativity.

Within this architecture a snapshot can be simply a conventional CAD file but in order to satisfy the requirements of the architecture it requires a versioning index to be maintained which describes the history (authors and dates) of the digital model's snapshots. The recorded delta changes would describe in CAD terminology how the digital model has been manipulated, for example 'wall A was changed to a length of 10m'. Both the versioning index and delta changes could be maintained within the CAD file itself or stored externally as separate files or a series of database entries. For the purposes of this example it is assumed the versioning history is maintained within the snapshot whilst the delta changes are stored as separate individual files.

In the following example there are three design team members who work on the digital model at different times during the project's history.

Figure 1: An outline of the distributed CAD collaboration architecture based on snapshot and delta change concepts (click to enlarge)

A Fictional Description of Events

Andrew the architect creates a new digital model and sets to work describing the building in CAD (1). Once he has determined the basic design he meets with Carol the consultant who is charged with developing the interior fit-out of the building. It is at this point Andrew creates a snapshot of the digital model to provide Carol with a copy to work on (2). Once Carol understands what Andrew has been up to she begins adding new design elements to meet the specialised working needs of the client (3).

With her part of the design complete Carol meets with Bob the builder who has offered to help out on some construction detailing she did not know how to solve. Carol creates another snapshot of the project file and emails it to Bob (4). Bob quickly completes the detailing and resolves an issue with the placement of one of Carol's dividing walls near a structural element. Bob then arranges to meet with Andrew the architect after the weekend and go over the things he and Carol have worked on.

On the night before their meeting Bob emails Andrew a snapshot of the digital model (5). On opening the model Andrew is notified by his CAD software that the model has been modified several times by Carol and Bob for different reasons. Unfortunately over the weekend Andrew has also been working on the model which leaves him confused about who has changed what exactly and why. Looking at the work log stored within the file he determines that Carol modified model before Bob (6). With this knowledge Andrew points his Internet browser to Carol's secure file storage and downloads the file containing all the relevant delta changes she made to the digital model he originally provided her (7). The CAD software then automatically regenerates Bob's delta changes through comparison of the snapshot available and Carol's delta changes (8).

With all the relevant delta changes at hand the CAD software displays a chronological overview of the digital model's evolution from the perspective of each participant's input (9). The software then determines a list of design issues through the analysis of delta changes made by each of the design participants. For the most part the individual changes to the digital model work well together but a couple of problems do arise around Bob's repositioning of the dividing wall and some of the changes Andrew has later made (10). Andrew generates a report which includes a breakdown of these issues alongside relevant plans and sections to discuss with Bob. While the report is printing he also calls Carol to see whether she has any preference on the final location of the dividing wall as she was the person to originally propose it. Fortunately for everyone involved Carol does not mind where the wall is placed leaving the decision in the hands of Andrew and Bob.

Whilst overly simplified the hypothetical example above does illustrate that a distributed approach based around snapshots and delta changes could be a worthwhile and flexible addition to an architects collaboration vocabulary.

Benefits of a Distributed Approach

A significant benefit of a distributed approach is that no external systems have to be maintained and participants are not reliant on network access to undertake work. Compared to the satellite model a distributed approach can work with unsophisticated data models plus there are no concerns around editing permissions as anyone who has a copy of the digital model is free to make changes.

Conventionally change conflict is viewed in a negative light which leads to restrictions being placed on the digital model at the expense of the creative process. In the approach just described anyone can potentially change anything within their copy of the digital model. Rather than focusing on restricting access to the model emphasis is placed on understanding of how these design conflicts arise, navigating a way through this potential minefield and finally reaching a consensus that it suitable to all parties.

Drawbacks Compared to Alternatives

Compared to centralised systems the actual process of communication is not handled internally within the model or through a defined external system. The architecture simply defines three components: snapshots, deltas and versioning logs, that need to be exchanged between parties alongside and complimentary to other design discussion. Rather than being the center of attention this approach is intended to work alongside existing communication systems such as email and document sharing services.

Such an architecture is not a worthwhile choice if the design team is avert to disagreement and uncertainty in the exact state of the digital model. Team members who operate at a managerial level would gain the lest value from such an approach because unlike centrally managed and monitored collaboration a distributed model does not have an easily accessible 'correct' answer. The process of understanding how the model is progressing would be assessed through communicating with those involved and accepting the fact the digital model is somewhat intangible and not as precise or reliable as initially perceived.

Conclusion

With the digital model becoming the focus and eventual outcome of design development collaboration within this medium is gaining increasing importance. Currently there are four different approaches to digital model collaboration that can be applied within software tools such as CAD. These varied approaches can also be applied simultaneously within software products to provide even more collaboration flexibility to design teams. Unfortunately the majority of these collaboration approaches lead to highly centralised processes that place an emphasis on consistency over flexibility. A decentralised approach using snapshot and delta change concepts would facilitate a more efficient and fluid design collaboration environment which encourages discussion and compromise in place of conformity and hierarchy.

Reviewing Autodesk Design Review

David — Sun, 04 Feb 2007 08:16:08 +0000

Recently Autodesk dropped the price tag off their Autodesk Design Review package making it far more accessible to the Architecture, Engineering and Construction (AEC) industry. Design Review is a DWF-centric tool for viewing and reviewing 2D and 3D design documentation. Prior to becoming freely available Design Review appeared to the casual observer as a useful tool for those heavily into Autodesk products but not the mainstream audience. This pricing shift changes the game and enables the software to compete against Adobe Acrobat as the primary, general purpose viewing tool for design documentation. With this in mind I took a fresh look at the software and what follows is what I found.

Obtaining and Installation

Design Review can be downloaded from the Autodesk website but before you can begin you must provide Autodesk with a few personal and professional details. For what is now free software this seems counter productive as it acts as a barrier to distribution. If you are a software vendor and you want your software tool to become ubiquitous so that your format becomes dominant in the industry (i.e. like Flash and PDF) your software needs to be easily accessible and preferably available from a range of download sites (i.e. download.com).

The Design Review installation process

Just to make things even more convoluted you must take note of a serial number discretely printed on the download page, then browse to another web page altogether to obtain the highly recommended Service Pack 1 installer. Maybe it is just me but if you are going to the effort of heavily publicising your now free product wouldn't it also be a good idea to help this flood of new users out by slipstreaming the service pack into the installer and removing the need for a serial number? Hopefully with the release of Autodesk Design Review 2008 in April these things get cleared up, because if Design Review is to really take off (which I think it could) it has to be painless to attain and install. And please Autodesk if you are listening drop the idea of a 'Service Pack' for a product with a yearly update cycle, either get it right the first time or integrate an automated update mechanism within the program like most software vendors are doing these days.

Finally getting into it

Things get a lot better once you move past the overly painful installation process. On opening Autodesk Design Review you are presented with a clear set of options that help you get working with documents or learn the program.

The easy on the eye and brain opening screen (click to enlarge)

Interface wise Design Review feels like Adobe Reader crossed with an slim version of AutoCAD. To avoid cutting into the functionality of other products Design Review is not intended as a content creation tool and instead focuses on the viewing and annotating of documents primary created by CAD or BIM software such as Autodesk Revit. Those familiar with Autodesk products will feel right at home with the interface as it borrows significantly from AutoCAD right down to the appearance of many icons. For existing Autodesk users this is great for productivity but for those used to a competitor's product or who have not used CAD coming to grips with some Autodesk axioms can take a lot of time and patience.

Exploring the components of a DWF model (click to enlarge)

Design Review supports 2D/3D files in DWF format and a wide variety of 2D raster file types such as TIFF and JPEG. Design Review can also import DWG and DXF data into a new or existing DWF file. This is a useful capability to have during collaboration as it means the DWF becomes a bi-directional platform for information, quite unlike PDF which are fairly static without the purchase of a costly editing tool like Adobe Acrobat Professional.

The File -> Open dialog illustrating most of the supported formats

When a DWF file is opened you can browse through the various layers, objects and views. This allows the user to quickly locate or hide aspects of the document when taking measurements or annotating. Like most Autodesk products Design Review utilises side-panel to display the properties of a selected object and a run-down of a document's annotations. Again this is all very familiar territory if you are an Autodesk user but somewhat overwhelming if new to the product line or CAD in general.

Collaborating with Design Review

As the name of the product suggests its core functionality lies in reviewing designs. The review process takes place through a very capable callout system which enables users to highlight aspects of the design for commenting on or questioning. The DWF can be then saved and sent back to its original source for these questions to be answered. Design Review does a fairly good job of tracking all of this activity chronologically so it is easy to see who said what and when. However from a usability perspective it is a little confusing that when creating a comment it is referred to as a 'Callout' but on the side-panel these comments are listed as 'Markups'. This is a small thing by why the terminology change when a single term could be consistently applied?

Creating a callout, note the properties in the bottom left (click to enlarge)

Once you get the hang of creating callouts it is a fairly painless process to visually identify a design issue, comment upon it and email the modified file to the intended recipient. There is an email option direct from Design Review but it would be nice to see a toolbar button for this (as in Adobe Reader) so people do not have to look for it halfway down the File menu. Unsurprisingly Design Review has built in Buzzsaw support for opening from and saving to Autodesk's on-line service. What is a little surprising is that there is no direct promotion of Buzzsaw within Design Review. Considering the two go hand in hand together it would make sense to include an easy sign up function built into the software in the same manner Apple promotes the .Mac service within their own product lines.

A promising beginning but there is room for improvement

As a commercially priced piece of software Design Review only made sense for large or long term design teams with an established suite of Autodesk applications. However with this significant shift to a free model Design Review suddenly becomes a viable tool for nearly all AEC professionals seeking to digitally collaborate in a medium that has the accessibility of paper plans and the clarity of CAD. With this in mind I think there exists a number of areas where Autodesk Design Review needs to improve or change to fully realise its potential.

The installation

For clients and other non-technically inclined users to use from the comfort of their own desktop it must be as simple to attain as downloading a single, easily located file and mindlessly running an installer that asks nothing more than do you want to accept the default installation directory? No serial code, no service pack and certainly no system restarts.

The interface

Autodesk Design Review inherits its interface from a long lineage of Autodesk products. If you are a die hard Autodesk user is not such a bad thing, but if Autodesk is seeking to extend the use of Design Review beyond this tightly controlled customer base they need to give a second thought to the interface. To reach its full potential Design Review should be accessible to users of all technical abilities and software backgrounds. It is counter-productive to adopt an ugly and often confusing historical interface when in fact Design Review is not an extension of the AutoCAD franchise but the creation of an entirely new product line.

Office 2007's new interface may still be ugly but at least it is efficient

How could things be improved? For starters they could take a look at the way Google Earth handles 3D navigation and take a leaf from that. Setting up a view should not involve clicking on nested icons to achieve tasks that should be accessible in a far more intuitive manner. This would result in a new interface paradigm but as Microsoft has illustrated with Office 2007 such events can be beneficial. Through providing a dynamic toolbar the little utilised menu strip could be disabled in a similar manner to Internet Explorer 7, providing even more screen space for document viewing (the purpose of the application).

The clean interface of Google Earth coupled with intuitive mouse controls makes it easy to pickup even for inexperienced users (click to enlarge)

By default there is also far too much screen clutter for an application that is meant to be all about reviewing designs. There are too many toolbar icons visible especially considering half of them are generally disabled. The interface would be so much clearer if the interface was dynamic to suit your current task (i.e. like Office 2007 and many OSX applications). The sidebar works okay but this would also benefit from a degree of customisation depending on the user's current activity and what is present within the opened file. For example when viewing or creating a callout in a 2D view why not hide the Model, Animations, Cross Sections and other non-essential side-panel sections so that users can focus on the Markup and Properties panels? This would ease the need to scroll around the side-panel and remove distractions to navigation and commenting by an inexperienced user.

A Web-centric approach to markups/callouts

The callout functionality within Design Review is excellent but this discussion is buried within the DWF and cannot be extracted or viewed independently of the file. This results in a lot of data transfer within a design team for what equates to a dynamic text conversation which is referenced to a static document. A more efficient and functional approach would be to provide the option to host the markup conversation on-line, allowing the DWF to be distributed throughout the design team once and from that point on used as a static point of reference (see the below diagram).

Diagram of proposed online callout functionality (click to enlarge)

An approach similar to this is used quite successfully at blogger.com when providing comments on a post. Comments are created and exist in a central location and are referenced to by the respective blog. Externally referenced markup would increase the responsiveness of Autodesk Design Review in team situations as new callouts would be pulled down live from the Internet without having to redistribute the entire DWF file. It would also make searching and monitoring of the design review process easier because existing Web search and RSS technologies could be applied to the on-line data, effectively making the DWF a hub around which many other services could be offered.

A Web-centric approach would also enable a more fluid design review process whereby a handful of reviewers could actively comment on the progress of a design. The current operational model is engineered for a simple one-to-one exchange and would get unwieldy if more than a couple of people want to partake in the conversation at the same time.

Cross-platform compatibility

Autodesk is in many ways a bigger supporter of Windows than Microsoft itself, but in order to gain universal acceptance they really need to drop their silly 'Windows or the highway' approach to software when it comes to DWF. If people are to use Design Review they have to be certain any current or future member of their design team will be using Microsoft Windows. The software becomes of no value to the process if just one person in the team cannot access and add to the discussion. As soon as the Windows mould gets broken DWF goes out the window (pun intended) and is replaced by a format that everyone can effortlessly read, PDF supported by email.

Who could this non-Microsoft person be? The first user group that springs to mind is the client. Whilst not dominant in the general office environment Apple has a strong home, upper management and IT professional base. Also on the other side of the team the many technical specialists (simulators, technicians, engineers) may also use Linux. Therefore if Design Review (and DWF) are to succeed at all levels it needs to support the three primary platforms: Windows, Linux and OSX. This support cannot be a token gesture either, if it is done correctly the same set of functionality must be shared across all three platforms to ensure all members of a design team are equal partners.

PDF support

This may sound a little strange considering Autodesk and Adobe are currently pitching their DWF and PDF formats against each other but in the long run it makes a lot of sense. Even though it probably pains Autodesk to admit it PDF is a widely used format in the AEC industry for everything from product specifications to design plans. Autodesk Design Review needs to support importing this information so that users can build DWF files containing designs, specifications and all the other useful pieces of information that go along with the review process. Autodesk Design Review needs to support the exporting of structured PDF information because of this same fact. Design Review must behave as a first class citizen if it is to be treated like one within the general AEC community.

Conclusion

Autodesk Design Review is a very promising tool for Windows based design teams seeking a simple way of exchanging design information, questions and opinion. The tool is free, powerful and relatively easy to use by those somewhat literate in CAD. The markup tool set makes it easy to hold fairly complicated design discussions but it does incur a heavy cost in terms of the data sizes communicated between team members. There are a number of areas where Design Review could be improved and I hope in the forthcoming releases we see some, if not all, of these issues seriously addressed.

2.0 C&C tools and my experiences

David — Sun, 30 Apr 2006 23:15:02 +0000

There has been a few interesting articles about products that hope to assist in the process of communicating and collaborating (C&C). Tangler sets out to do this by providing a mechanism for grouping various discussion sources (blogs, instant messaging, mailing lists) into a single 'group' that can be easily searched, scanned and in turn discussed. It sounds like they aim to get around the problem of information dispersion, ie. an interesting blog here, a somewhat handy mailing list here. This could be really useful in certain arenas like open source where often I find myself going to several similar but different discussion venues (mailing lists, forums, blogs) in order to find the answer to a certain question. Unfortunately it would also seem like the potential for making money out of such a system is pretty low, not only because similar systems already exist but also because the 'value-add' is relatively small when put in the context of the web, search engines and the flexibility of RSS.

Foldera is a new take on the way we use email as Michael Arrington from TechCrunch explains. It is accepted that everyone archives email into folders for later reference but Foldera takes this to a new level by evolving the concept of shared project folders. Foldera is web-based and has email, instant messaging and document management functionality built in. The concept seems pretty interesting but the system would appear to be handicapped by the fact everything happens within Foldera. Consequently for it to be any use at all everyone involved in the project must use the same web-based Foldera system. This is nice from a setting up a new company perspective but so far as integrating its use into existing companies and projects it would be very difficult given the amount of process change and retraining required. A product referenced in the comments section of the TechCrunch article that has similar functionality but is designed around tags is Joyent.

At the heart of it both of these are hosted mail/calendar tools that look and feel very similar to Zimbra and Google Mail/Calendar with a document management portion similar to Fluxiom added for good measure. The fact they offer very limited (or non-existent) integration with existing desktop applications makes them a lot less appealing however.

On the topic of Fluxiom it went public a few weeks ago so I signed up for an account to see what it was like. Whilst the interface was quite appealing I found the service to be somewhat pointless as I could not easily integrate it with my desktop (via WebDAV or a Dashboard Widget) which made putting files into the system a bit of a chore. Plus tags had to be predefined in a separate screen rather than just entered dynamically next to the file which was a real pain (and defied half the purpose of tagging). Mike Arrington wrote a fairly scathing review of it on TechCrunch, not because of what it is but rather its relatively high pricing especially in light of Amazon's S3 storage service pricing.

On the email front there was a good article on NewsForge about using Thunderbird as a context management tool. Rather than using a completely new system similar to Foldera the author proposes we use what we have more intelligently. In this instance folders, email templates and filters within Thunderbird are put to good use to create a fairly tidy document management system. Unfortunately from a user interface and setup perspective its fairly awkward but it works with what is already in place in many offices. For a minimal investment in time and zero dollars the outcome is actually quite powerful.

Talking about email, for the last few months I have been using Zimbra as my office email/collaboration server. Whilst its performance as a mail server has been good I have been pretty dissappointed with its web-interface which in the open-source version is the only way to create calendar events. Whilst Zimbra's interface looks nice its fairly clunky to use and is very fat (150kb+ download). When not in the office its proven a pain to use because on a dial-up connection it takes forever to load and creating new calendar events take just a little too long to be worth the effort. Consequently I've started using Google Calendar for which I must say is really fast and simple to use, the very simple Google aesthetic works well for a productivity application like a calendar as all I want to do is enter events and then view them in iCal or in my Dashboard (both of which are possible thanks to ICS and RSS support in Google Calendar). To get around the fat webmail interface of Zimbra I've installed the far lighter yet just as cool RoundCube, a stylish yet fast IMAP webmail interface written in php. The moral of the story, no matter how good something looks it has to be very fast, as quick to use as possible and preferably integrate with existing infrastructure on the desktop easily.

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.

WikiCalc

David — Mon, 13 Mar 2006 01:16:07 +0000

WikiCalc is a new piece of online software from Dan Bricklin that is attempting to bring the venerable spreadsheet to the Web. NewsForge is running a review of the initial alpha release and it seems pretty good. Recently he was interviewed on the Gillmor Gang about this software and his ideas around it. It is a fairly nice idea now that we live in an Internet full of Ajax and rich interaction. My initial feeling was that he was angling for a Google/Microsoft/Yahoo buyout but surprisingly he has put the source code online for others to download. This is a good thing from a free software perspective and hopefully with the support of others there will soon be a viable (and hopefully embeddable) spreadsheet application for the Web.

On the subject of Google last week TechCrunch ran screenshots of Google's Calendar application that is still in development. It seems nice enough though the market is getting pretty full of Ajax calendars. It will be nice if it can pull events out of plain text email and display your schedule in GMail in a similar way that Zimbra can tell you whats happening 'tomorrow' or 'next week' when reading an email. Mike Arrington who runs TechCrunch had a pretty good sparring contest with Steve Gillmor afterwards on the Gillmor Daily podshow. It is quite a funny listen as the pro-Google Steve attacks the more logical and reasoned Arrington on his opinion that Google is more than a little bit evil and are making a number of wrong steps.