stressfree - autodesk

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.

Google O3D may finally bring 3D to the Web

David — Wed, 22 Apr 2009 11:23:22 +0000

Today Google released a very early preview of O3D, a cross-platform, open source plug-in that enables OpenGL accelerated graphics within Web browsers. Delivering 3D graphics within browsers is not a new thing, (remember VRML?) but what makes this initiative promising is that it works on all platforms and is backed by Google. Performance-wise O3D seems very snappy when compared to alternatives such as Flash 3D. As a result some of the initial demonstrations are very impressive, and it hints at a future where Google Earth and SketchUp leave their desktop roots behind to become pure web applications.

From an architectural collaboration perspective O3D is valuable for a number of reasons. Firstly in a review situation it would mean remote clients can experience 3D designs without having to download, install and learn a separate "viewer" application. Likewise within an intranet such functionality would be valuable when navigating a project or company knowledge base. Whereas at the moment textual (web) data is quite distinct from 3D models, in a O3D-enabled future the two could be seamlessly intertwined in a variety of powerful ways. Finally by freely distributing 3D capabilities to everyone with a browser O3D opens up the possibility for new types of 3D-centric web applications that allow all design team participants to more effectively communicate ideas with one and other. For examples of these potential markets checkout the section 'Where will Dragonfly land?' in my earlier 'Autodesk Dragonfly emerges from its larvae' post. The people behind O3D's demo applications seem to appreciate this fact too, because the "Interiors" demo showcases such a tool (i.e. it 'copies' Project DragonFly).

A 3D, Google Trends view of the Earth in O3D

I have not yet created or rendered content using O3D, but if I get the chance there is a significant amount of developer documentation online. Anybody with web development experience should feel at home because the rendering engine is initiated and controlled using Javascript. This is a great choice, not only does it make the technology accessible, but it means 3D can be integrated into "traditional" web applications using standard Javascript event handlers. For example if you were creating a web-based CAD application you could create the majority of the user-interface using standard HTML/Javascript and leave O3D to handle just the rendering of the model window(s). Such an approach also means developers who already have already created 3D web applications in Flash and HTML could leverage O3D without being completely rewritten.

Overall O3D comes across as a very powerful and surprisingly polished early preview. Google are obviously very serious about 3D in the browser, and this implementation seems to be the most promising yet.

Autodesk Dragonfly emerges from its larvae

David — Fri, 13 Mar 2009 03:20:37 +0000

Project Dragonfly is an Autodesk Labs technology preview of a web-based, simple to use architectural planning tool. It represents a step towards a future where CAD and BIM model editors are not considered bloated, complex, or desktop-bound. Whilst the current functionality of the tool is limited, it is technically impressive, and the underlying concept hints that Autodesk’s broader web strategy (as discussed in ‘Autodesk Beyond Desktop CAD & BIM’) is proceeding at a slow, but steady pace.

An example of the 3D visualisation capabilities of Dragonfly (click to enlarge)

Dragonfly in flight

Dragonfly runs on any operating system that has a web browser which supports the latest Flash plug-in, for example Windows, OSX or Linux. Designing a floor plan primarily takes place within a constrained 2-dimensional space, but limited 3-dimensional views are available. In a nod towards its Autodesk lineage the toolbar and view controls aesthetically mimic those found in AutoCAD and Autodesk Design Review. As a result the tools are intuitive to use, but slightly limiting for those used to the responsiveness and flexibility of a desktop application. For a web-based tool in its infancy this is unsurprising, and there are certainly no fears (yet) that Autodesk is cannibalizing Revit or AutoCAD sales. However there are very strong signs that with continued development a unique and compelling product will evolve.

At Dragonfly’s core is a Flash-based model editor that enables users to manipulate architectural elements using traditional mouse gestures. In practice this editing process works best when in the 2D viewing mode, but moving of some objects whilst in the 3D view is possible. The graphic performance when making modifications is not up to par with a CAD or BIM desktop application, but for simple tasks it works quite well. What is impressive is the use of visual dimensioning aids to help quickly position elements in their correct location. Although not as powerful as the coordinate-based positioning systems used in most desktop CAD tools, for general layout it does the job admirably.

The dimensioning aids that help size elements (click to enlarge)

Beyond basic modeling the most visually appealing aspect of Dragonfly is its library of architectural furnishings and surfaces. Each element in the library has a detailed 2D and 3D representation that adds a level of scale to an otherwise blank canvas. At the moment this library is small, but there is enough there to get an idea of its versatility, and given time this will undoubtedly grow. Like the modeling tools, library components can be dragged and dropped into place and rotated to suit the designer’s needs. An issue at the moment is that once a component is placed there does not seem to be a way of displaying its name or meta-data information. From the perspective of layout design this would be useful as it would enable details such as the exact shower model and cost to be recorded.

Learning to fly: Where Dragonfly can improve

Whilst a promising initial release, a lot of development needs to take place before Dragonfly can transition from interesting preview to productive tool. Online collaboration is a key area where the Web-based Dragonfly holds a huge advantage over contemporary CAD/BIM modeling tools. Whilst further development of the modeling toolset is needed, being able to save designs as traditional 2D and 3D files is also critical for adoption. Finally expanding the component library through integration with the Seek product index would seem an obvious evolutionary step for both services.

Collaboration is key

The greatest development and deployment advantage a tool like Dragonfly has is that was conceived and built with the Web in mind. In contrast most desktop-based CAD/BIM tools use a file-based paradigm which cannot fully leverage the collaboration possibilities of the Internet. As a result sharing or collaboratively working on a design with Dragonfly is made very simple because the data and the tools are online. Unfortunately the current collaboration feature-set is limited to either exchanging an email link, or exhibiting the design within the public gallery. Whilst both are useful options, this is just the tip of a functional iceberg when it comes to professional architectural collaboration possibilities. Arguably the “holy grail” would be the inclusion of a multi-user, concurrent editing mode like that found in many Flash-based white-boarding tools. But even if technically infeasible, adding configurable read/write privileges and groups functionality would substantially increase Dragonfly’s value.

Exporting the layout for further development

The obvious market for a web-based architectural layout tool would seem to be in pre-design where clients are able to explore ideas by themselves. Once they have something they are happy with they need to be able to share it with their architect in a way that can promote further development. The first step in this process would be the ability to export scale 2D drawings in both DWF and PDF formats for printing and discussing over coffee. Architects should then be able to export the 3D model as a DWG so that more complex designs can be created within AutoCAD or Sketchup. Whilst this would probably not be used as the basis for production drawings, as far as visual exploration goes it would make an ideal starting point.

Growing the component library with Seek

An architectural layout tool is only as good as its component libraries, thus integration with Autodesk Seek would make Dragonfly very compelling. Seek is Autodesk’s product search index which contains a broad range of product descriptions along with 2D and 3D models. Integration with the Seek service would be very challenging, but if it was executed well the result would be far greater than the sum of its parts. The benefit to Dragonfly is that users would instantly be able to access a vast catalogue of components which they could add to their layout. For Seek and its content providers Dragonfly integration would provide that next step in the procurement decision making process beyond search. i.e. I have a product that I am interested in, but how does it physically sit within the space I am designing?

Where will Dragonfly land?

Dragonfly is a great example of how powerful the web browser has become, but how will this materialise into a financially viable product offering? There would seem to be three markets; a value-add service for desktop software, an advertising platform, or an engine for third-party development.

Adding value to existing products

Microsoft refers to this as a Software + Services strategy where online tools are provided alongside desktop software to extend its functionality. In the case of Microsoft this is Office Live, but for Autodesk this could be a version of Dragonfly that allowed Revit models to be interacted with online. In the foreseeable future Dragonfly is never going to match Revit in functionality, but it could allow architects to collaborate on plans with clients. For example an architect could export multi-story office plans to Dragonfly so that clients could experiment with office fittings and layouts. Once determined the Revit model could be synchronised with Dragonfly so that detailed production drawings or light renderings could be produced.

Autodesk as an advertising platform

Dragonfly’s component library would be an excellent advertising vehicle for manufacturers of furniture, fittings and surfaces. It is becoming common for these manufacturers to invest in web-based visualisation tools in order for potential clients to see what they will get. Rather than developing these tools, Dragonfly could be licensed to suppliers and the component library tailored to their promotional needs. These customised visualisation engines would be embedded into websites around the world in a similar manner as YouTube’s video player. Potential customers would then be free to experiment with how products would look and integrate within their own home.

A Dragonfly API: Third-party application development

Dragonfly’s underlying 2D layout and 3D visualisation functionality is something that can be applied to other tasks beyond basic architectural layouts. Google Maps is a great example of an innovative, web-based engine that has spawned a vast market of third-party applications. The underlying Dragonfly engine could fulfill a similar role if the API was exposed and developers were able to layer on functionality and information. Third-party development could be simple as tools for calculating the tiles needed in a space, through to applications in non-architectural domains. What the killer application would be is impossible to say, but being able to leverage Dragonfly within other web applications would be very powerful.

The big picture: bringing Dragonfly, Seek & Showroom together

Dragonfly is a nice technology preview, but its real value will only be realised once all of Autodesk’s online initiatives are seamlessly linked together. What will be most impressive is when Showroom renderings can be produced from a Dragonfly model built using components sourced from Seek. Judging by the state of these three services this day may not be too far off, and once it arrives it will stand as a remarkable online milestone. In the space of ten years something that required dedicated computer hardware and expensive software will be possible from anywhere for free. This will result in significant business model changes and the increased use of architectural modeling and rendering tools by the public.

An example rendering from Project Showroom (click to enlarge)

An unexplored opportunity: consolidating a user’s Autodesk identity

As Autodesk’s web services grow your online identity will be instrumental in monitoring activity across these different applications. Beyond Labs, Autodesk has a lot of identity-centric services, such as discussion boards, license management and an online university. As these elements coalesce it is important that Autodesk make it easy for users to manage their online identity and the information related to it. The most basic step being to ensure each online application uses the same single sign-on (SSO) service in order to create a consistent experience.

Beyond basic plumbing, a user “portal” is required that stitches together the latest news and collaboration updates from all these sources. For example as Dragonfly or Seek content is shared with others there is a need for a central location where this can be managed and monitored. A significant opportunity Autodesk has in this regard is that the majority of their online customers use their desktop software on a daily basis. Integrating online profiles within these desktop tools would add value to the customer, and promote the use of its new online services. It would also mean that no matter what Autodesk application was open, a user’s shared content and their collaboration connections would be available.

Conclusion

Project Dragonfly is a promising release that offers a glimpse into a future where CAD and BIM tools are not the exclusive domain of architects. Assuming development continues and the tool is integrated with other Labs services the end product will break a great deal of online ground. Unfortunately at this time until its collaboration and export options mature, early adopters will struggle to find productive uses for Dragonfly. Still as a technology demonstrator Dragonfly performs admirably and provides a promising glimpse into the future.

Autodesk Seek gets a new look and more content

David — Wed, 17 Dec 2008 10:21:50 +0000

Autodesk has not yet abandoned their web-based services endeavours in spite of a wilting construction industry and sinking global economy. Just prior to Autodesk University 2008 their Seek service received a significant makeover. Now this week it was announced BIMWorld has been acquired by Autodesk so that its BIMLibrary catalogue can be folded into Seek's. These events all sound good on paper, but how do they stack up, and more importantly is this a step forward for the Seek service?

The new user interface

The old white on black style of Seek has disappeared in favour of pastels on white. Overall this is a welcome change, but more importantly the overall appearance has been tidied up, with more attention paid to the rendering of onscreen elements. The result still feels very database-driven, but compared to the previous interface it does have a better flow and a less haphazard look. The Javascript-based Yahoo! User Interface library has been used to good effect and overall it feels very snappy. Unfortunately under this new coat of paint some things have not changed, for example the URIs for each product are shockingly bad. The option to email a link of the product has improved, but most people are used to simply copying and pasting URLs from the browser. If Autodesk expect others to link to content they need to resolve this problem. Until then it is very difficult for people to collaborate using Seek as a point of reference.

The revised look and feel of Autodesk Seek (click to enalrge)

It is good to see that on some 3D models the option to preview the model before downloading is available. Whether this option appears seems to depended on the supplier, but when it was present the result worked quite well. On the Mac with Safari the preview was limited to Project Freewheel's static 3D rendering of model, but apparently an interactive 3D viewer is available for Windows users. Even with this limitation the preview provided by Freewheel is a welcome addition, and for most tasks provides all the validation a user may require.

Seek's new 3D model preview option (click to enlarge)

Beyond these specific improvements the overall interface has not fundamentally changed. This is not bad, you cannot help but feel one or two UI iterations centered around navigation and filtering could lead to something really innovative. This could be helped if 2009 Autodesk exposed Seek's index as a series of web services. Third parties would then be free to develop more varied interfaces and "mash-up" the data with external services.

The BIMWorld purchase

Whenever one large company buys a smaller one it is always fun to watch. Autodesk's acquisition of BIMWorld appears to be centered around two assets; the content catalogue and its supporting community. Whilst the catalogue and its supporting content should be relatively easy to integrate with Seek, preserving the community may prove more of a challenge. The motivation behind "buying" a community is simple, on the Internet page views are the linga franca of advertising dollars. The more users Seek can claim, the more valuable it becomes to advertisers, suppliers and potential users.

The challenge facing this forthcoming community migration is that BIMWorld has significant functionality Seek currently lacks, for example membership, ratings and the ability to upload new content. Such deficiencies may prove too much for many BIMWorld users to stomach. However it may turn out this "missing" functionality is added to Seek sometime in 2009. The inability to submit or comment on content handicaps the fledgling service, so you would hope planning and implementation of such features was underway prior to the acquisition.

Conclusion: It is getting there slowly

Seek is demonstrating slow but steady improvement on both the interface and content fronts. The purchase of BIMWorld illustrates that Autodesk are serious about the idea of a universal product catalogue and are willing to spend money to ensure it establishes itself. Hopefully in 2009 we see the implementation of user and community-centric functionality that lifts the service from a simple database interface to a thriving AEC specifications centre. Such an endeavour will prove most successful if the functionality can be tightly integrated with Autodesk's 2010 range of AEC products. The majority of AEC professionals spend their working lives buried in these tools, so for Seek's sake lets hope Autodesk does not expend too much effort bringing people to the website, and instead focus on taking the content to the people.

Autodesk Beyond Desktop CAD & BIM

David — Thu, 21 Aug 2008 12:30:52 +0000

or: How they Stopped Worrying and Learned to Love the Internet

It is my opinion that Autodesk is in the early stages of implementing a bold Internet-centric strategy that if successful will position it as the Software + Services giant within the Architecture, Engineering and Construction (AEC) industry. Excluding the spin-off and re-purchase of Buzzsaw during the Dot-com bubble one could say Autodesk's attitude towards the Web, like the rest of the AEC industry, has been tepid at the best. In a similar manner to Microsoft, the historical and financial foundations of Autodesk lie in the traditional, desktop software market. Here its catalogue of heavy-weight tools compete for domination of the competitive CAD, BIM, animation and rendering markets. Unlike Microsoft vs Google, Autodesk and its competitors (such as Bentley Systems) have yet to face serious competition from an Internet savvy, AEC software heavy-weight. Rather than waiting for such a competitor to emerge Mike Haley, Jeff Wright and the rest of Autodesk's Content division are building it 'in-house'.

The goal: building really big 3D models in the cloud

AEC software vendors have largely ignored the Internet and have been content to focus on what can be done on a single workstation. The problem is that simultaneously other industries have demonstrated what is possible on the network, for example virtual worlds and photo-realistic visual experiences. Hence as our expectations have grown we are finding a single workstation cannot hope to keep up with these perpetually increasing processing demands. Consequently at some point the AEC software industry must make the step from tried and true desktop CAD/BIM to the less understood, but potentially more capable platform now referred to as cloud computing.

But why are really big, 3D models important in the eyes of industry professionals and public? The answer is simple, architecture is not mass production and the first time a design gets built is generally the last. From the perspective of understanding the design and its issues this is not ideal as the shift from the abstract to real world almost never happens painlessly. Not only is there design problems, for example 'does the detailing of the design match the overall aesthetic and its surroundings?', but there are also performance questions such as 'what are the temperature and light qualities like in the lounge in late winter when the sun goes behind the building across the road?'. The ability to digitally realise the entire design - from the exact detailing of its window frames to its geographic context, enables those involved to 'virtually' build and experience the architecture in a very cost effective manner.

At this point many will be thinking, isn't this what I do in Revit, Microstation or ArchiCAD every day? The answer is yes, but on a scale that is almost impossible to fathom. At this level it is not just about what you as a single person can record about a model, but rather the bringing together of vast quantities of data from multiple sources in order for it to be experienced in one place and time.

An outsiders overview of the strategy

Whilst I have recently spoken with Mike Haley and Abhi Singh from Autodesk about Seek and their evolving Internet strategy, what follows is primarily my own summary of the bigger picture drawn from the thoughts of some of those involved. Expect to hear and see more definitive things from Autodesk during the course of the year, especially at December's Autodesk Univserity.

Note: Buzzsaw is not included in this discussion as it is a closed tool that is not widely available on the Internet (i.e. it conforms to the classical notion of the closed, corporate Intranet).

Autodesk's Internet strategy is driven by the Content division within Autodesk. The goal of the strategy is to harness the potential of Internet-centric infrastructure to scale beyond that considered possible on the desktop or traditional corporate network. With the efficient scaling of digital infrastructure comes the ability to push the boundaries of the digital model - not only in its scope and depth of detail, but also in the designer's ability to simulate its properties.

The infrastructure for achieving this goal has been broken down into four distinct functional components as illustrated by the diagram below.

Whilst each functional component is at a different stage of development, aspects of each have been demonstrated to the public in some way, shape or form:

Seek - Product and material index: http://seek.autodesk.com/
Dragonfly - Web-centric modelling: http://labs.autodesk.com/technologies/draw/
Showroom - Render-wall service: http://labs.autodesk.com/technologies/showroom/
Metropolis - Massive 3D environment space: Autodesk University demo video

Individually these projects break a little new ground, but when viewed as an integrated suite of cloud-based services their true potential becomes apparent. Together the four services form a platform that if successfully implemented, may revolutionise the way AEC professionals conceive, produce and experience digital models.

Seek

Seek is a sophisticated data conduit for architectural information. I have covered Seek previously and Mike Haley has an even better video presentation. The intention behind Seek is to build an index of architectural details and materials, their associated meta-data and any digital files which maybe associated to them (e.g. DWG and PDF files). Unlike a supplier-centric materials index, Seek's primary motive is to facilitate information sharing amongst architectural suppliers and professionals. The intention is that this data-store can be leveraged to help construct more precise 3D models, add richness to renderings and provide material performance data for thermal simulations.

Metropolis

Metropolis is the bridging of virtual world concepts (a.k.a Google Earth) and serious 3D modelling. Rather than focusing on the macro OR the micro the emphasis of Metropolis is to create a virtual space capable of handling everything from the planet down to a pencil. The challenge this project is attempting to overcome is how to efficiently retrieve and process massive amounts of 3D data. Whilst the technical barriers are huge, if they can be surmounted being able to quickly visualise fully furnished, architectural designs within their actual geographic context is a real possibility.

Dragonfly

Dragonfly is attempting to bring CAD concepts to the cloud computing environment. The intention of Dragonfly is not to recreate AutoCAD or Revit within the Internet browser, but to leverage this ubiquitous platform to deliver and manipulate 3D content. For example smart-phones ship with Web browsers capable of displaying rich content (i.e. images and Flash). Along another line is the growth of browser-based, virtual worlds such as Google's Lively. Whilst these technologies are currently in their infancy, it is fairly obvious that they will mature into a very capable platforms for interactive 3D experiences.

Showroom

Showroom is photo-realistic cloud rendering made available to consumers. The concept of render-farms is certainly not new, but making the technology easily available to the general public is. The current technology preview illustrates how Showroom can efficiently render dynamic, photo-realistic scenes 'on-demand'. Conventionally this processor intensive work has been conducted on a desktop computer, tying up CPU cycles and requiring installation and maintenance of complicated rendering software. By moving this task into Showroom not only are CPU cycles freed but the software and materials libraries used can be far more sophisticated. The end result is that cloud-based rendering may prove to be faster and of a higher quality compared to its desktop counterpart.

Why the need for change?

Autodesk is a financially profitable company that dominates many of the software sectors it competes in. Why is there a need to branch out into cloud-based computing, especially when success of these initiatives may in the long-term harm their conventional, desktop business?

Moore's Law can't keep up when it comes to 3D

Nothing has reinforced the limitations of working with 3D data on a desktop computer more than my time spent teaching CAD and rendering to architecture students. Experienced digital modellers gain a subconscious understanding of the processing limitations of their desktop computer. However, like children learning about gravity the hard way, those starting out with 3D do not have the same appreciation for these boundaries. Consequently the most challenging part about teaching students how to create effective 3D models and renderings is not the creation of geometric data, it is getting them to stop. The problem is once introduced to the concept of CAD, (or more recently BIM) students have an uncontrollable urge to model every screw and light-fitting. No matter whether this was five years ago on a Pentium 3 or today with a Core2 Duo, students will do their best to overload the available hardware through simple, blissful ignorance.

"Google is like lots of PhDs driving tanks. It is all about brute force - everyone is General Patton. They don't drive around the wall, they drive through the wall. It is dumb techniques used in large scale."

Adam Bosworth
Database Requirements in the Age of Scalable Services (13:04-13:18)
MySQL Users Conference 2005

Google Earth was the first mainstream demonstration of the power of integrating a vast online 2D/3D data-store with the interactivity of a rich client interface. However as far as processing went it is very simple. Digitally representing the Earth down to the individual building is made possible because the only data downloaded and rendered by the client is what can be 'seen' on-screen. This is fine for basic, macro-level visualisation but it does not work for a richly detailed Building Information Model (BIM). In this environment AEC professionals need the ability to digitally represent all aspects of the design - from its 3D properties down to the thermal characteristics of the materials. To make effective design decisions this potentially infinite data-set needs to be right at hand. As a result the challenge facing Autodesk is not just to store the underlying data in the cloud, but also the entire, 3-dimensionally realised model so that it can be efficiently navigated, manipulated and simulated.

Breaking existing vendor relationships with on-demand services

Unlike traditional desktop software an online offering will allow Autodesk to compete head-to-head on competing vendors 'home turf'. Currently the AEC sector is a patchwork of companies each committed to a particular CAD/BIM software vendor. This is primarily due to the licensing and training costs associated with this business critical functionality, but the vendors do their bit by making their products 'more compatible' with their own offerings. If deployed in an open and ubiquitous manner, Autodesk's Internet strategy could overcome these business firewalls by enabling Autodesk-centric functionality to be embedded into competing products. For example consider the following scenario:

John is developing a building model in Microstation, his architecture practice's primary BIM tool. He likes the work-group capabilities of Microstation but wishes that it had better tools for demonstrating to the client what the building will look like in its urban context. On a whim (and without "I.T's" approval) he signs up for an Autodesk.com account and installs the Microstation plug-in so that his model can be loaded into a very large Metropolis model of the city. He then emails the client with a link to a Dragonfly web-viewer that lets them see his building design within the context of the city within their Internet browser. They are really impressed and ask if they could see some renderings of the building from the street at different times on day. As the model is already in Metropolis he takes the plunge and requests some Showroom renders using the most trusted material definitions found on Seek. He is told that the renderings will take some time to complete so he goes back to working on his Microstation model. Within minutes he receives an email from Showroom to say that his renderings are ready. The quality of the results are more than enough to impress the clients, but the practice's part-time renderer/animation guru says he could have done better if there was the budget to upgrade to the latest version of his rendering software (and a faster computer). Overall John is more than pleased with the result, especially considering instead of a large upfront expense his account was billed as he chose to use the services on offer. He could see that even though the practice was not going to migrate from Microstation anytime soon, they were going to use Autodesk's online services more often in the future.

Reaching new customers and markets

After twenty-odd years of fierce competition in the CAD software space the battle-lines are fairly well defined. The Google Earth/SketchUp combination has demonstrated there are vast, untapped reserves of potential customers for 3D tools in unconventional sectors, developing economies and the casual market. Unfortunately trying to sell $1000-$5000 software to people who do not recognise the value, cannot afford the license fees or do not want to pay is an impossible mission. Cloud-based computing can potentially overcome these barriers through its ability to scale and be delivered to users at low cost.

The proven results of this cloud-centric strategy can be seen in the success of Google and SalesForce.com. Both companies have been able to enter markets previously inaccessible to traditional vendors, and simultaneously undermine the position of the well-entrenched competitors in existing, developed markets.

For example:

Google's online advertising (AdWords) gives anyone the ability to advertise and undermined the position (and cost structure) of conventional advertisers.
SalesForce.com uses a Software as a Service (SaaS) model to deliver feature-rich Customer Relationship Management (CRM) services to a broader audience and at considerably lower costs than traditional alternatives.
Google Apps is providing a suite of business services to educators, non-profits and small-businesses at zero cost whilst undermining the unquestioned dominance of Microsoft's Exchange/Office suite in larger corporations.

Autodesk the Software + Services company

A business strategy that includes online services diversifies Autodesk's income stream and protects it from any downturn in its traditional product offerings. The ability to sell additional services to users enables the up-front cost of the software to be lowered on the assumption that lost income will be recouped over the life cycle of the product. This provides a competitive edge over software vendors who's sole income is from the software's initial sale. This lower up-front cost in turn helps make the desktop software more palatable to a broader audience.

This "shavers and razors" approach is certainly not a new business strategy, but it has not yet been exploited within the AEC software industry. It would not be unreasonable to suggest that if Autodesk's Software + Services strategy were to successfully mature, high cost items such as Revit could be sold at a significantly lower rate (currently a Revit subscription is US$725 per year, per user). The mobile phone market uses this model to great effect, so much so that even Apple have adopted it in order to ship more iPhones.

An observation on ubiquity: The part of most value in a 'stack' rises as the components below become ubiquitous

Ubiquity is a powerful yet dangerous asset for a business. Ubiquity drives adoption and product sales which leads to healthy profits. On the other hand ubiquity results in imitation and a stifling of innovation due to the momentum of legacy. Reaping the rewards of ubiquity is the goal of any software company, but escaping its pitfalls is a harder and often undervalued proposition.

"..nobody who was an ice harvester became an ice factory, and nobody who was an ice factory became a refrigerator company, and nobody who is a refrigerator company is investing in biotechnology. Because most people stay on the same curve. Better saw... more horses.... bigger ice factory... more colours of refrigerator.

Very few people have the courage or vision to get to the next curve."

Guy Kawasaki
The Art of Innovation (17:25-17:55)
MySQL Users Conference 2007

Autodesk illustrated great foresight in its acquisition of Revit on the cusp of the Building Information Model's 'tipping point'. The purchase was also timely because it preempted the demise of AutoCAD as their venerable "cash cow". We can confidently state that AutoCAD is on the way out for three reasons:

Competition: There are now many low-cost and free alternatives on the market that do an excellent job of 3D CAD. Thanks to OpenDWG these competitors can read and write AutoCAD files.
Lawsuits: Any company that needs to resort to suing the competition to maintain an edge in the market is destined to loose out in the long-term.
Ribbons: The introduction of a 'ribbon' interface as the primary feature for any software release is a clear sign that its designers are clean out of useful functionality to add which justifies the upgrade cost.

Unfortunately for Autodesk nobody can be quite sure whether Revit will become ubiquitous, and if it does how long its time will last. This initiation of a bold Internet strategy acts as a safeguard to these uncertainties. Not only would a successful suite of Internet services reinforce Revit's hold on the BIM market, but it also allows Autodesk to "get to the next curve" before the competition.

Learning from and living on Amazon's cloud

Whilst it is early days yet, the thinking and implementation of this Internet strategy has no doubt been shaped by Amazon's suite of cloud computing web services. Not only are the services offered by Autodesk hosted on Amazon, but the manner by which functionality has been compartmentalised is very similar to Amazon's architecture.

The very existence of Amazon's services has enabled Autodesk's cloud-centric strategy to be launched with relatively little investment. Only a couple of years ago such a project would have required in-house development of a compute cluster. This expensive proposition becomes very difficult to justify when moving into uncharted business waters. In contrast, the flexibility offered by today's 'pay as you go' compute services from Amazon, Google and others enable clusters to be setup in a matter of minutes at extremely low cost ($0.10 per CPU hour on EC2). A significant and very attractive property of these rented compute clouds is their linear pricing model. This greatly simplifies business models for companies like Autodesk when choosing to build services because there is no cost penalty for success. In contrast choosing to build on a traditional infrastructure does not guarantee cost effective scale. This runs the risk of breaking the business model (operating at a loss) or failing to meet demand (momentum loss) as the service becomes popular.

It will be interesting to see how closely Autodesk follows Amazon's delivery model for these services. Currently the emphasis is on exposing functionality through Autodesk's own desktop and web products. However the opportunity exists to follow Amazon and publicly expose the underlying, low-level services to external developers via a set of for-pay web service APIs. Amazon followed this exact path in the release of their cloud-based web services stack, and what started off as an internal project soon flourished into a multi-million dollar industry. If things play out in a similar manner it is not unreasonable to suggest that one day the rendering engine of ArchiCAD could be Autodesk Showroom, or that Microstation models may happily co-exist next to legacy AutoCAD ones in a Metropolis cluster.

The effect of open source (or you can teach an old dog new tricks)

It is somewhat ironic that for Autodesk, an icon of the proprietary software world, the key enabler of this Internet strategy is open source software. Open source forms the backbone of the virtualisation technology (EC2 is based on Xen) and the host images that run on top of it (currently Linux and OpenSolaris). The freedom provided by the various open source licenses which make up this software stack enable its massive scale. This open source foundation is now beginning to extend beyond the virtualisation layer and is seeping into Autodesk's own programming practices. For example Seek is built on top of Java and makes use of many open source libraries such as Lucene and Spring. Whilst this is not a sign that a Linux version of AutoCAD will be released tomorrow, the acknowledgement by Autodesk that open source is a valid development model is a promising first step.

No plan survives contact with the enemy

Grand thoughts of a cloud-centric Autodesk are nice to postulate, but the reality is in the real world things are not so clear cut. In many ways the group behind this strategy is the Autodesk equivalent of Apple's Macintosh Pirates of 1983. Like the now infamous Macintosh developers, the group is small, intentionally isolated from the mothership and proposing products that may fundamentally shake up the tried and true business model (in this case desktop CAD/BIM). Whether or not such a promising start is allowed to blossom will not simply rest on the ability of the team to execute, but also the response they get from "old school" Autodesk and its competitors as this promising plan unfolds.

What will the "old schoolers" have to say about this?

For any online strategy to be successful it must be fully supported by the traditional software products offered by Autodesk. This goes well beyond the current (minor) integration that currently exists, to a point where venerable desktop products such as AutoCAD, Revit and Max are completely reshaped to take advantage of the possibilities on offer. Such an undertaking is not a simple task, especially when product managers have conventional feature requests to address and limited resources on hand.

Well beyond this practical matter is the degree to which a paradigm shifting Internet strategy can be successfully communicated within a software behemoth. For the Internet strategy put forward to take hold and flourish a significant portion of Autodesk's 7,000+ staff will need to comprehend and fully support the idea. Furthermore this clear sense of direction needs to come from the top and flow through the company in a similar manner to Bill Gates' 1995 'Tidal Wave' memo. This now infamous directive refocused all of Microsoft's software efforts to exploiting the Web's potential at a time where it could have been superseded by others. What is promising is that Autodesk's current CEO, Carl Bass, led the Buzzsaw team so he obviously understands the Internet and does not need to experience a Gates-like "eureka" moment.

Even if the concept is well communicated and Autodesk's desktop offerings are remodelled there is still the question of how internal divisions will react when their sales numbers are impacted by competing, cloud-centric products. For example taken to their ultimate (hypothetical) conclusions Showroom (rendering) and Dragonfly (modelling) will perform tasks well enough that for a subset, or even majority, of users the purchase of traditional desktop clients like Max and AutoCAD becomes unnecessary. Internal management structures within large companies are always fractured and at war with each other, so when this happens one of four things occur:

The new, competing product is terminated (the old guys win).
The new product is hamstrung or merged with a division that cannot manage it properly (the old guys win but the boss doesn't tell the new guys).
The existing product is put out to pasture (the new guys win).
The two products begin competing against each other and loose out to a third party (both guys loose).

There are many cases were internal competition over the same user-base has lead to conflict. Perhaps the most famous example brought to light recently was the 2001 internal struggle within Microsoft between Bill Gates and Steve Ballmer over the future of NetDocs, an Internet-based, Office competitor. The end result of this conflict was that NetDocs was unofficially cancelled, handing Google a lead in the online productivity market which Microsoft may never recover.

Concluding thoughts

Autodesk are making some bold moves when it comes to the Internet. Whether or not these initiatives will be allowed to mature and foster a healthy user-base is another matter. Time to market is crucial, not only will it preempt competition but it will also act as a very clear sign of the company's overall intentions. For the good of the industry we are all hoping that services like Seek, Showroom, Dragonfly, Metropolisis and their competitors flourish. Whilst picking a winner at this early stage is impossible, the mere fact that that CAD and BIM is about to make that 'one small step' from the desktop to the cloud can only lead much bigger (and hopefully better) things.

Autodesk Seek talk by Mike Haley

David — Sun, 08 Jun 2008 05:05:41 +0000

A day after posting my critique on Autodesk Seek I came across this presentation Mike Haley of the Seek team gave in March. Boy I wish that I had come across this last week as it answers some of the outstanding questions that I posed. The video covers the technologies that Seek is composed of, i.e. Atom syndication feeds (PartAtom), schema design, Amazon EC2 and open source modules. The entire thing looks surprisingly good (and open) for a big company like Autodesk. The presentation is an hour long but worth watching as it is probably the most significant thing one of the big-AEC software vendors have attempted on the Internet.

Another interesting thing Mike mentions is that Amazon are working on Windows-based EC2 instances...

Autodesk Seek steps towards ubiquitous AEC search

David — Fri, 06 Jun 2008 21:59:29 +0000

Note: Before reading this critque I would recommend checking out this Autodesk Seek presentation as it answers many of the questions raised here.

In May Autodesk released a beta of Autodesk Seek, a web-based Architecture, Engineering and Construction (AEC) specific, 3D model and specifications search tool. Rather than a free for all model index in a similar guise to Google's 3D Warehouse or CADoogle, the service is focused on exposing the model and specification catalogues of AEC suppliers. This is hardly going to interest the armchair designer, but for architects and engineers the ability to quickly locate, access and reference specifications and 3D data could potentially reduce design development time and costs significantly.

Gauging by the initial contents of Seek it would appear Autodesk have partnered with some large U.S. suppliers in order to kick-start their index. Whilst the index signals a clear sign of intent its current contents is hardly awe inspiring. That being said raw index size itself does not ensure success, to really make a mark and stand the test of time the Seek team need to execute on three things:

Quickly build out this index with up to date and relevant content so that it becomes the first place AEC professionals head to.
Create a compelling user experience which overcomes the idea that a specifications catalogue must be dull, unhelpful and always two months out of date.
Work to integrate Seek into as many aspects of Autodesk's existing modeling and drafting tools. By doing so the line between desktop and Web will be blurred and Seek will become a natural extension of their professional digital toolset.

What differentiates Seek from the crowd?

The idea of an online product catalogue for AEC specifications is certainly not new. However Seek is unique in that it is the first online product catalogue backed by a large company who's primary customer-base is not AEC suppliers. In the past online AEC catalogue initiatives have been spearheaded by suppliers or third-parties financially dependent on these suppliers. This close association has hindered growth and because for a Web-based, universal product catalogue to be successful it must stand independently from its data suppliers. This independence establishes trust which is important because users do not want the relevancy of their search influenced by who is paying the bills, nor do they want a 'walled garden' where only products from selected (paying) suppliers are on show. Consequently even though many supplier-backed catalogues exist, none can be considered the Google of the AEC world.

Seek has the potential of filling this 'Google' void because Autodesk's primary income is from people who make material purchasing decisions (architects, engineers and contractors, etc.) and not the suppliers themselves. This difference places Seek in the position of being able to design a catalogue that acts in the best interests of the search consumer. At the same time suppliers are practically forced to take part given Autodesk's vast global audience. The challenge facing Seek it is that Autodesk are not known for producing search indexes or successful Web products.

So given this background and the potential rewards on offer what works and what doesn't in this early beta release? Let's take a look...

Judging a book by its cover

The Seek team have yet to reveal anything about its inner workings so in this beta release all that can really be judged is the front-end usability and functionality. Unfortunately look and feel wise Seek is nothing to write home about. The interface is not confusing, it just has that late-20^th Century database feel that the cool 'Web 2.0' crowd left many years ago. This may sound immaterial but if the target audience is aesthetically motivated people like designers and architects the user interface has to look really good. Adobe understand this and make every one of their websites a work of art, for example just checkout their latest acrobat.com site. This is not to say that Seek should become one big Flash animation, they just need to break down the grid layout, pare back the interface elements and add a dedicated interface/graphic designer to the team.

Aspects that work

Aesthetics aside a good deal of Seek's exposed functionally works well; namely the classification, filtering and linked file support. Whilst these may not not seem that exciting they do illustrate the developers have a solid understanding of what AEC professionals are interested in getting out of Seek.

Classification

Seek applies multiple classification systems to the data stored within its index. As a result rather than coming across as a want-to-be Google for AEC search, the experience is more akin to the 90's-era manual categorisation by Yahoo. This may not sound sexy as we approach 2010 but it actually works pretty well. Experience has shown that performing 'dumb' searches within the rigid world of architecture generally is not very productive. When looking for AEC content we will have specific contexts in mind and classification systems help define their respective boundaries. By limiting search results to a specific subset of the building industry the potential for finding what you are looking for increases dramatically. Unfortunately the option does not seem to be available to perform a sub-search within a specific category. For example there did not seem to be a way to search for the term 'stainless steel' within the Transportion section of the CSI MasterFormat category. It is possible to filter the results from a category search but this is not as flexible as being able to define a custom search term within a category.

What would be interesting to learn about is how these classification systems are applied to the items in the index. Do the manufacturers have to manually define which categories their models/specifications fall under, or have Autodesk developed some intelligent algorithm that classifies incoming data similar to that described in this paper by Robert Amor? If it is the later then that would be very cool, but how accurate is it? Along this same line of thought is whether Seek can add other classifications systems to its index and if so how would this 'foreign' semantic system be mapped to the existing entities in the index? For example in New Zealand many practitioners use the CBI classification system, so for Seek to be accepted in this locale it would ideally need more than just the three categorisation systems currently supported. Personally I hope Autodesk do have plans for supporting a plethora of categorisation systems through some sort of mapping algorithm (i.e. system A, section 1 = system B, section 3 & 4). Such a mechanism could never be 100% accurate but it would make Seek more appealing to international users and future proof it for new categorisation systems which will surely emerge.

Filtering

Seek offers a wide range of attributes to filter on once a category or basic search term has been defined. This mechanism enables quick culling of large sets of results to identify a couple of the most relevant models or specifications. In this regard Seek behaves more like an e-commerce site rather than a search engine because the emphasis is not on providing you 50 relevant suggestions but one or two specific answers. At the moment it is difficult to test the usefulness or performance of the filter functionality given the limited size of the current search index. Still the interface is intuitive, so even when there are only ten search results the ability to quickly filter them still feels useful. This maybe because the filters provide a visual prompt as to how you can drill down to the product you really want, i.e. arctic white, gun grey or stainless steel window frames?

Seek's search results with its filtering system on the left (click to enlarge)

The question remains as to exactly how Seek facilitates filtering of its index. Are the filterable attributes automatically derived from indexed data or are they manually defined by the manufacturer or Autodesk themselves? The solution to this question is a double edged sword; an automatically derived filtering mechanism enables efficient scale (indexing bots) whilst a manual process provides a high degree of trust. Unfortunately automation generally comes at the expense of accuracy and manual data entry will stunt the index's growth. To be judged a success Seek needs to balance these demands to build a large yet accurate index. If it fails in this task the end result will be an index which is large and inaccurate, or accurate but too small to care about. Neither alternative will be suffered by users long before they go back to their conventional, paper-based specification libraries.

Linked file support

Of all the major AEC software vendors Autodesk is arguably one of the worst for equally supporting competing formats. Fortunately this attitude seems to have changed when it comes to Seek as it prominently supports a range of non-Autodesk formats such as Bentley's DGN and Adobe's PDF. The first time you download a linked file you must agree to Autodesk's terms of use which is interesting considering the files themselves are not hosted by Autodesk. Now I am no lawyer and there is probably good reason for this, but it still feels strange to have a search engine imparting terms of use on the content it links to.

Most products have numerous file attachments. Unfortunately the preview option is very limited at the best of times (click to enlarge)

In the future it would be great to see a more comprehensive file previewer be made available. There are currently thumbnail images of many referenced files but something that behaved in a similar way to Apple's Quick Look would be really useful. Whilst this may sound far fetched it is not an impossible considering Autodesk have Freewheel, a Web-based 3D model viewer. If used alongside a Web-based document viewer similar to Scribd it would allow users to quickly preview the contents of files without having to commit to a download. The inclusion of such functionality would not only enrich the user experience but open up further revenue opportunities. Attached files could be made available online through Seek for free and offered for download at a reasonable price from Autodesk or the third-party. This revenue model works well for many book publishers and stock photo distributors, so in theory the same could be achieved within the AEC industry if the content holds enough value.

Aspects that could do with development

Growing the index

To help build out the search index the Seek team will need to make public how interested third parties can get their own content into it. Given the intention of the project it is obvious that strangers off the street will not be granted publishing rights and for the integrity of the index it is important that some validation processes be put in place. That being said in the interests of long-term success the route to participation should be a public, devoid of NDAs, exchanges of money or unnecessary bureaucracy.

When it comes to creating an accurate and timely index blog search engines have demonstrated that the ability to push structured data to the search engine is far more efficient than using a conventional Web crawler approach. With this capability the very nature of the catalogue would shift from that of an online book to a living entity. If suppliers were able to push availability details and news about a particular product into the index it would mean that any consumer of Seek data would also be able to utilise this information. For example consider the following scenario:

An architect assigns a product specification from Seek to a component in their AutoCAD model. On making this assignment they select to be notified of important information on this product until the project is complete. In effect this configures AutoCAD a subscriber to the product-specific RSS feed on Seek. As any new information is announced by the supplier, for example it will be discontinued in December or a national safety test found it did not perform well under certain situations, then anyone opening the model would be alerted of this news. Note: The RSS product feeds themselves would not necessarily need to be contained within the AutoCAD file itself, they could exist in an externally referenced OPML file.

There are two proven means of achieving this push-like model, Seek could consume supplier generated Atom feeds, or Google Sitemap-like structured documents. In both cases the supplier should be able to 'ping' Seek to inform it that new content is available for indexing and be confident that in a timely manner Seek would be accurately displaying the data to users. The key behind such an approach is that the AEC-specific data (classifications, physical properties, etc.) within these feeds would need to be conveyed in a non-proprietary format. Whilst it would be easy for Autodesk to write their own format a wiser approach would be to take an existing Web format, for example GData and build upon that. By starting out with a ubiquitous format it makes the task of gaining third-party support much easier and it ensures effort expended by suppliers to create Seek feeds can be leveraged by other search engines and compatible software.

Exposing the Data

Crucial to the success of Seek is its web service component, i.e. the ability for other applications on the Web or desktop to use the data this service returns. Whilst Autodesk currently describe Seek as a 'web service' this is not the case in the contemporary sense. Seek's value will increase exponentially once it makes the leap from a visual catalogue to a service which forms the functional backbone of desktop and web-based applications. For example consider the following two scenarios and how a service-centric Seek could have:

An architect working on an ArchiCAD model is about to make a design decision regarding a set of shelves. The ArchiCAD Seek plug-in recognises that this is the case because the user has selected the appropriate modeling tool and layer set. The plug-in queries Seek and returns a list of appropriate 3D models based on the properties of the project (a residential dwelling in Auckland). The plug-in filters and orders this data to suit the architect's personal preferences - in this case supplies that satisfy green building standards. Without a single extra mouse click Seek in partnership with the desktop software is able to present a reasonably intelligent set of shelving options. This task, which would have taken hours of searching through conventional product catalogues and manual 3D modelling is completed in seconds.

A design team working on a medium sized industrial plant in Sydney is having a discussion within their Project Intranet on appropriate door fixtures to use. None of the available products seem to suit the requirements so the outstanding issue is recorded as something that needs attention later. The Intranet software constructs a Seek search query out of the issue's defined parameters and begins regularly checking Seek for potential matches. Weeks pass and the problem is forgotten about by the team. Then one afternoon the Intranet service issues an email informing the interested parties that a local supplier has just that morning started producing a new line of industrial strength fixtures which satisfy the design requirements.

In both these scenarios the use of web services transforms Seek from a user-initiated search tool to a context-aware information delivery service. With this relatively simple shift the value proposition of Seek from both the user and supplier's perspective changes immensely. The catalogue ceases to be a passive object and becomes a tool that can proactively solve decisions and sell products.

When it comes to exposing the Seek index via web services this should be implemented as simply as possible. This means following the example of many Internet-savvy companies and releasing lots of well documented, REST-based web services. These services should return simple XML (preferably Atom) or JSON data streams which any application developer can utilise. To support this API there also needs to be a set of Javascript components to enable non-developers (i.e. the CAD managers and "I.T. guys" of this world) to embed Seek functionality within company Intranets. Once Autodesk make this set of web services available it is a relatively easy task for third party developers to integrate Seek into their own applications to achieve the functionality described and more. Unfortunately the cloud hanging over this rosy picture is that Autodesk are not known for producing open and simple to use web services. Time will tell whether they can execute on such a strategy, but let's hope the thought has at least crossed their collected minds.

Sharing search results

Search results from Seek can be emailed to others for later reference but the mechanism for this is very primitive. This option feels like a nod in the direction of useful functionality rather than something that has been given serious attention. When it comes to externally sharing results the feature-set needs to be greatly expanded upon to be of real value. Currently it is not possible to email a subset of your search results or highlight specific results other than writing "here are the results and I prefer options 2 and 5". Also in need of development is the functionality surrounding the email format. Rather than emailing a dull URL there should be the option to send the selected results as a self contained message complete with thumbnails. Many (if not all) AEC companies use email as a quasi filing system, so a URL that displays different results over time is of little historical value. In effect what the email option needs to become is the equivalent of the Amazon or Dell 'wish list'. This way architects can have their clients look through Seek and build a list of 'things' they like the look of, i.e the digital equivalent of turning up to the practice with three Home & Garden magazines.

Seek does not use friendly URLs or have unique meta-data for each page. Consequently tools like Google Reader do not work well (click to enlarge)

Another way that specific items can be quickly shared or referenced is by hyperlinking. Unfortunately this is not made easy because Seek URLs are in no way 'friendly'. Take for example this URL that Seek generates for 'Window Guards':
http://seek.autodesk.com/#query=search%5Edetail%5EH4sIAAAAAAAAAEtMT7fKTU4vSizPyMzJsfILDrG0MDEGAOhs_2kWAAAA
Not only is this meaningless but the meta information within the Seek page does not change to suit the context being viewed. The title of the page is always 'Autodesk Seek' and the meta description a constant 'Autodesk Seek is the online source for building product information (...)'. As a result if you were to bookmark this page in a browser or online service the default bookmark attributes (the name and description) do not accurately reflect the subject matter of the page. In comparison if you take a look at a page from Amazon.com the URL, page title and description all clearly identify what the subject matter is:
http://www.amazon.com/Harry-Potter-Deathly-Hallows-Book/dp/0545010225/

This may sound a little pedantic but it is the details like this that make comprehension of hyperlinks possible for both people and computers alike. A failure of comprehension means that third-party services like Google Reader's ability to share interesting web pages with peers do not work so well, if at all when it comes to Seek.

Trusting search results

Whilst traditional web search engines like Google, Yahoo or Microsoft need to worry about 'search engine fraud' the factual correctness of the information is of little importance as long as it is considered relevant. In comparison for a service like Seek the user's ability to trust the information returned is exceptionally important. There is no point in using the service if it returns models or specifications that are incorrect or out of date. This issue becomes a real problem as the index grows, things get out of date and malicious suppliers attempt to game the system to boost sales by 0.1%. Even well intentioned suppliers and Seek itself are capable of making mistakes. Given these factors there needs to be a feedback mechanism in place for consumers to alert Autodesk and their fellow users of these problems. This feedback could be enabled passively or through active participation.

General purpose search engines establish 'correctness' through the concept of PageRank (i.e. if it is linked to it is probably right). Unfortunately for the closed and competitive world of architectural design this concept cannot be applied even if it was possible for Autodesk to go crawling the design plans of AEC professionals to identify which models and specifications are referenced the most. However it would be feasible to deploy an opt-in system within Seek where users could identify models and specifications they made use of regularly. For example during the drafting of construction details the CAD program could notify Seek whenever specifications stored in the index were referenced by the designer. In practice this would be similar to Google's Web History as the aggregate, anonymised data returned would help assist others to identify popular, and therefore by logical extension trusted, models and specifications.

Beyond passive observation is the ability for users to directly feed into Seek's index their own opinions and content. For example the real value of the Amazon web experience is not the search results but the user reviews. Basic online specifications is one thing, but knowing that someone in a very similar situation as yours found the actual product did not measure up to expectations is considerably valuable. However if this kind of conversation were to take place on Seek itself it may place Autodesk in an awkward position with suppliers who do not take kindly to poor feedback. Whether or not such functionality is possible will depend on the business model Seek eventually establishes. If the intention is to add value to Autodesk's other software offerings then such functionality is a possibility, but if Seek they are looking to generate an income stream through paid listings from suppliers then the chances of seeing such functionality is low. Personally I feel it would be great to see Autodesk take the open road and encourage user feedback on listings through a variety of mechanisms. Unlike dedicated online catalogue companies Autodesk can afford to take such a risk because their customer base is the decision makers in the building process, hence they stand to profit most when they give this group better decision making tools.

Working within an organisation or project team

Currently Seek is a standalone search service that lacks functionality specific to project work-groups. It would be useful to be able to register a practice or project account with Seek in order for selected index items or suppliers to be listed, shared and discussed within this social network. Many architecture practices work with selected suppliers and components that they are familiar with and trust. These trust networks would make the process of browsing, selecting and recalling past decisions easier for users because it establishes an internal hierarchy within the index unique to the individual or group (i.e. another layer of meta-categorisation). For example consider the following scenario and how this trust network would be useful:

An architecture graduate is trying to pick commercial kitchen fittings for the first project he has been issued at his new job. The graduate has no experience in this field so they elect to filter Seek search results to suppliers trusted by their architecture practice. On selecting a fitting Seek informs the graduate that a similar fitting was used in a project two years ago by a senior partner. This is reassuring in two ways; firstly it indicates that this choice is not completely off track (a senior partner made a similar decision), and secondly it identifies a pathway for future research ("hey John, how did that kitchen work out last year?").

Whether or not all the historical information referenced in this scenario would be stored in the Seek 'cloud' would be an operational preference of the organisation or project team. Even excluding the ability to track historical choices made by the collective the ability to create a Seek user account and limit search results to an identified subset of other users would go a long way to achieving this functionality.

Leveraging the social

Without a doubt the "Web phenomenon" of the past two years has been the move towards social-centric networks (e.g. Facebook, MySpace and Twitter). AEC professionals subscribe to magazines and catalogues, visit interesting buildings and attend lectures because they want to know what their peers are up to. Implemented correctly Seek would enable users to track what was 'in' and what was 'out' in the same way that a fashionista attends catwalk shows. Where this could get really interesting is in the field of paid recommendations like that of Amazon's Associate programme . The idea being that if my actions or recommendations influence the purchasing decision of another party then shouldn't I be rewarded by the supplier in some way? The supplier has sold a product, the third-party has solved their problem and Autodesk has promoted their brand - doesn't the person who initiated this transaction deserve some reward? Greed is a powerful motive for participation and a rewards mechanism would certainly encourage use. Such a system would not neccessary have to involve financial rewards, it could operate with the concept of 'Autodesk Points' which acrue in the same way as frequent flier miles and can be redeemed for discounts on Autodesk software. After all a similar concept to this made the AdSense programme Google arguably the largest advertising agency in the world.

In Conclusion

Seek is a promising step in a potentially very interesting direction for Autodesk. If they can continue to evolve its functionality and integrate it into their other product offerings it stands a higher than average chance of becoming a valuable resource within the AEC industry. Central to its success is a demonstration that the search index is capable of growing quickly and that the underlying data can be easily exposed to third-party developers. With these improvements and a lot of luck it is not unreasonable to suggest that Autodesk Seek may become the Google/Amazon (Goomazon?) of AEC specific search and specification.

Upcoming Revit Technology Conference in Sydney

David — Mon, 26 May 2008 02:48:14 +0000

There is an upcoming Revit Technology Conference in Sydney in June. The venue looks very nice although I doubt June is the best time of the year to be hitting the beach, even in Sydney. The schedule covers just about every conceivable functional aspect of Revit. If you can't spare the time or money to attend Autodesk University then this is probably the closest thing you'll get in the southern hemisphere.

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.

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.

Connected: A new Autodesk blog on collaboration

David — Thu, 25 Jan 2007 23:02:40 +0000

Alex Willingham, Jason Pratt and Mike Gemmell of Autodesk have launched Connected, a blog focused on digital collaboration within the AEC space. Hopefully the presence of three authors will not only ensure a steady flow of new content but also inspire some debate. Plus their positions inside of Autodesk will no doubt provide readers with an insight to where the company itself will be heading when it comes to online collaboration. So far nothing too juicy has been posted although Software as a Service looks like it will become a strong theme, not only in the blog but in the manner in which the authors will be working:

"In my office we use Salesforce.com, Buzzsaw, Constructware, and Gliffy. Heck I'm even writing this post in a web based application that has spell check..."

Autodesk sues the Open Design Alliance

David — Mon, 27 Nov 2006 08:58:17 +0000

For years the Open Design Alliance (ODA) have been working towards providing an 'open' (i.e. freely distributable) set of libraries and tools capable of reading and writing the DWG file standard. DWG is the default standard within the AutoDesk suite of CAD/CAM applications (the most notable and ubiquitous being AutoCAD). On November 13th 2006 AutoDesk filed a Trademark infringement lawsuit against the Open Design Alliance, apparently around the use of digital watermarks within TrustedDWG files created by the ODA libraries.

TrustedDWG is a digital watermark present within AutoCAD 2007 that ensures the recipient of the file that it was created using genuine AutoDesk software. This functionality has two uses, the marketing reason of course is that it protects customers from the dangers of nasty external programmers who cannot program to save themselves and as a consequence try to destroy your data. This is the marketing reason and like all good marketing reasons it is a completely lame excuse that attempts to cover up real technical issues. The fact of the matter is AutoDesk software is in itself notoriously bad for file corruption. After over five years of tutoring CAD I've seen numerous file corruption incidents and all have involved purely 'genuine' AutoDesk software. Perhaps if AutoDesk engineers were allowed to spend more time on developing a file standard with internal verification systems and less on monopoly protecting digital fingerprints they would not need to worry about third party applications damaging user's data?

No the real reason behind TrustedDWG is to protect AutoDesk (not customers) through the creation of a trademarkable data firewall to protect their ever shrinking DWG monopoly. What is the need for this firewall? Unfortunately of late things have not gone too well for AutoDesk when it comes to AEC file formats. There was a day when they 'owned' the space, AutoDesk generated DWG was king and all other file formats and DWG wannabes were pretenders to the crown. Nowadays they face a different reality, the Open Design Alliance has produced a set of DWG libraries that let everybody manipulate DWG files on an equal footing, and just to rub salt into the wound Adobe has come out and started pitching the PDF format as a serious AEC data transfer medium. This must be causing some shivers down the spines of managers at AutoDesk who, like Microsoft in the operating system arena, have always relied on market share and proprietary standards to maintain an edge over competitors such as Bentley and Graphisoft.

The outcome of this lawsuit will be an interesting moment for AEC file formats. If the ODA is found to be in breach of AutoDesk's trademark then it will be a sad day for interoperability efforts and the industry at large. From a narrow minded perspective the ODA has breached the trademark and are guilty as charged. However in the larger legal and business sense the legality of the trademark itself must be brought into question. What AutoDesk have tried to achieve with TrustedDWG is apply anti-competitive measures to maintain an industry monopoly. Hopefully for the sake of the industry the ODA can prove that this is the case and will be allowed to continue shipping their fully compatible DWG libraries. Whilst DWG is not perfect by a long shot it is still one of the most widely used AEC file formats and the closest thing CAD software vendors have to an interoperable standard (ignoring for the moment Industry Foundation Classes).

AutoDesk bus promotion in NZ

David — Wed, 03 May 2006 10:03:35 +0000

I am over vendor presentations after the CAADRIA conference but it was interesting to read that Salesoft are touring around NZ on a big bus (which looks a lot like the XBox360 bus repainted) to promote AutoDesk's new products (Revit, ADT). They were in Wellington today and are off south for the rest of the week. It is good to see AutoDesk staff member and blogger Shaan Hurley (of Between the Lines) tour down here as an indication AutoDesk takes this market seriously. Its kind of funny, after years of almost no active promotion all of a sudden AutoDesk and Bentley seem to be interested in this part of the world again.

New AutoDesk DWF blog - Beyond the Paper

David — Thu, 16 Feb 2006 08:11:58 +0000

There is a new AutoDesk blog about DWF from Scott Sheppard. He has an fairly nice overview of what a DWF is exactly and then goes on to explain why Adobe and AutoDesk are not 'at war' with their PDF and DWF standards. This is something I completely disagree with and I think subconsciously he does too with comments like "if you want to solve real problems... then PDF is not enough" and "never fly in a plane that was designed from a PDF".

A primary justification for DWF is the fact that it is intelligent and allows the capture of meta-data about a project for sharing. This is quite an ironic statement considering that that is exactly what a DWG and an IFC model do, the only difference is that for the time being DWF is firmly in the AutoDesk silo. DWF does have a lot more presentational characteristics compared to these two formats but the same effects are able to be generated using these formats without needing to create an entirely new proprietary standard.

AutoDesk and Adobe are fighting a battle within the collaboration space to establish a dominant standard for digital paper collaboration. It is a battle that at least in New Zealand Adobe is winning as most AEC professionals I have experience with exchange and accept PDF formatted documents whilst I know of only a couple that have experimented with DWF. Ultimately there will come a point where DWF will gain so many features that it will almost be impossible to distinguish it from its bigger brother DWG. When that time comes will we see a DWF Lite (or perhaps DWX as it sounds sexier).

Autodesk presentation and moves by Adobe

David — Wed, 25 Jan 2006 10:34:47 +0000

Before Christmas I watched a video from the AutoDesk University keynote. The theme of the keynote was interoperability but the goings on concerned how different AutoDesk applications could talk to each other using DWG and DWF formats. It is rather ironic that a single silo is only just beginning to tout its ability to exchange data within itself whilst the IAI is promoting the adoption of a generic IFC model. Something that stood out during the presentation was that even though 'interoperability' was the theme there was no mention of IFCs. This is a clear indication that AutoDesk is concerned about the security of their silo and through the promotion of their own exchange standards they retain format control, and consequently customer subscriptions, to their AEC silo.

On the other side of the New Year Adobe recently announced the immediate availability of their Acrobat3D software for imbedding 3D content into easily exchanged PDF files. This is a direct competitor to AutoDesk's DWF format and to a lesser extent both formats are simpler and immediately more accessible rivals to IFCs. This move also differentiates Adobe's PDF reader from the growing bunch of PDF viewers because at the moment only Adobe Reader 7.0 is capable of reading these 3D files. The success of this format in the AEC field is probably reliant on the acceptance or rejection of it by Bentley, Graphisoft and other CAD/CAM rivals to AutoDesk. Given the control AutoDesk has over DWG (even with the existence of OpenDWG) it would seem likely Acrobat3D will be picked up and promoted by competitors as a means of ensuring AutoDesk does not control the defacto 2D/3D document exchange format as well as the default 3D model format.