stressfree - web 2.0

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.

Doom & gloom programmer keynote by Tim Bray

David — Sun, 12 Oct 2008 09:38:47 +0000

Tim Bray's Future of Web Apps 2008 keynote has been published to the web. Unfortunately he does not paint a rosy future for developers given the current economic climate. Entitled "The Fear Factor", according to Tim he rewrote the script the night before after spending a couple of depressing days with London bankers and watching television news.

Tim gives a very down to earth presentation that sits in stark contrast to most bright and breezy keynotes you see posted to the Web. The underlying concept is that the credit crunch will force many companies to suspend broad, big budget development in favor of small, low-cost projects. In this environment there will be project cancellations and job losses, so if you are a programmer it is a case of staying competitive through learning and networking more than your competition.

Some of the interesting points raised in the half hour keynote were:

Monetisation will occur at the point of value. Rather than $100,000 up-front licenses, companies will be looking to pay only once a system is in production i.e. Open source will hold a significant business advantage.
Waterfall is dead. In an uncertain, credit-poor economy the idea that a project can go for 14 months without delivering value will be seen as unacceptable to decision makers.
The Cloud is good, but lock-in is bad. Companies will value the cost savings from on-demand services like Amazon Web Services and Google App Engine, but be wary of the pitfalls of vendor lock-in (we do not want another Windows monopoly).
With regulation comes business opportunities. Governments around the world will be passing legislation to ensure another financial crisis is avoided. From a software development standpoint this will create a significant opportunities for those in the right place with the right abilities.
Mobile technology and micro-transactions are the new fertile ground. Apple iPhone and Google Android have realised the development potential of the mobile device. Their application marketplaces are vibrant economies where micro-transactions of $1-$5 rule.
Build something for yourself. You will only be truly successful at building something that satisfies your own needs. Steve Yegge has said it best in "business requirements are bullshit".
Do not be a [insert language here] developer. The idea that someone can ever learn and use one computer language (e.g. Java, PHP, Ruby, etc.) in a competitive marketplace will not cut the mustard. Be a 'web developer' who is prepared to explore anything, even legacy code - you never know where it will lead.
Network, network, network. Nine times out of ten work will come from people you know rather than what you know. Do not expect the plum jobs to land in your lap if you do not participate in communities. e.g. conferences, mailing lists, blogs, Twitter, etc.

Overall it is a very good, down to earth talk that provides a valuable reality check in these "interesting times".

Google Chrome rethinks the browser

David — Wed, 03 Sep 2008 11:15:45 +0000

Yesterday (after a comic strip teaser) Google finally took the plunge and released their own web browser named Chrome. For years they have had a defacto relationship with Mozilla Firefox, but now they have decided to go it alone with their own, radically different offering. How this affects the Firefox/Google relationship is anyone's guess, but presumably for Mozilla having your number one revenue stream release a competing product is not a good sign.

So why should I care?

Rather than a simple re-branding of Firefox, Google Chrome is a completely new beast built on top of the WebKit rendering engine (the same engine that drives Apple's Safari). Innovation is a term used pretty lightly in the technology industry, but in this case Google has really tried to break conventions and create something that is genuinely a generation better than the competition.

The Chrome interface with its Task Manager (click to enlarge)

Process isolation comes to tabs

The biggest conceptual leap the developers have made is thinking of each tab as its own distinct process. Traditionally your browser has run as a single process, which means when one tab or window goes haywire the whole thing goes up in a puff of smoke. By running each tab as a distinct, protected process the browser gains a level of robustness never considered possible. In fact in some respects Google Chrome is a lightweight operating system unto itself, it even has its own Task Manager for monitoring and selectively killing errand tabs.

What it looks like when you kill a tab (click to enlarge)

A lightweight, tab-centric interface

Google have also taken the interface concept of tabs to a new level by making it the primary interface element. Whereas conventionally the browser tab has been subservient to the navigation bar, in Chrome this relationship is reversed. Tabs are the high-level interface element which everything else is related to. Also gone is the 90's concept of a 'home page'. When you create a new tab in Chrome you are presented with a very tidy activity overview which displays frequently visited sites, new bookmarks, closed tabs and of course a big search box.

The activity overview tab (click to enlarge)

Chrome is fast... really fast

The decision to use WebKit over Mozilla's Gecko rendering engine helps in the speed stakes. For a while now Apple has been trumpeting how fast their browser is, but now Google have trumped them with this effort. Given that the majority of Google's web properties rely heavily on Javascript it is unsurprising to see that they have used a new and very fast Javascript engine. Thanks to the recent developments in Javascript run-time technology the language can no longer be considered 'dead slow'. Whilst it may not be as fast as compiled C, for most day to day tasks it is now more than adequate.

What does it mean for me the poor old web developer?

With Chrome's WebKit rendering engine you can be fairly confident that if your website displays correctly in Safari 3 it will work fine. In all the tests I did there were no obvious rendering differences between the two browsers. As far a Javascript goes this will be a different story as Chrome uses a custom engine. My guess is as long as you stick to well trodden tracks and make use of popular Javascript libraries such as Prototype, JQuery and Dojo you will not experience too many issues. To help developers out a Firebug-like inspector is included which lets you drill down into your HTML and Javascript for easy troubleshooting. Chrome also ships with Google Gears built in, so if you have been considering whether adding offline support to your applications is worthwhile, now maybe a good time to look into it.

The HTML/Javascript inspector (click to enlarge)

The beta for Windows is available now, OSX and Linux to follow

Like most things, first out of the starting blocks is a Windows beta release. It sounds like OSX and Linux versions will not be too far behind, but releases will not be anytime this month. Installation is very straightforward, simply run the small (475kb) installer and it will go ahead and pull the latest release off the network. When the browser first starts you can import your settings from Firefox. Then to ward off any anti-trust lawsuits a prominent opportunity is provided to change the default search engine to something other than Google (does anyone actually use Live.com?).

The 'don't sue us' change the default search engine pop-up

Final thoughts

Google Chrome is a great beta release of a truly next generation web browser. For anyone like myself who writes web applications for a living the introduction of tab-level process isolation is a very welcome sight. Whether or not the average user accepts Chrome will be another story. Many businesses will hesitate due to the privacy cloud hanging over anything from Google (even though the majority of their desktops, servers and mobile phones are exclusively Microsoft). Even if Google Chrome does not succeed in the market lets hope that some of its innovations at least rub off on its competitors.

Harvard Critical Digital Conference 2008 paper

David — Sun, 11 May 2008 10:08:06 +0000

In April I presented a paper at the GSD Critical Digital Conference at Harvard University. The paper was co-authored by my supervisor Mike Donn. The conference itself was pretty good considering it was the first time it had been run. You can find my paper along with all the others online at the Critical Digital website. However for posterity (and Google) I have included the text of my paper below.

Using Project Information Clouds to Preserve Design Stories within the Digital Architecture Workplace

Abstract

During the development of an architectural design a series of design stories form. These stories chronicle the collective decision making process of the diverse project team. Current digital design processes often fail to record these design stories because of the emphasis placed on the concise and accurate generation of the virtual model. This focus on an all-encompassing digital model is detrimental to design stories because it limits participation, consolidates information flow and risks editorialisation of design discussion. Project Information Clouds are proposed as a digital space for design team participants to link, categorise and repurpose existing digital information into comprehensible design stories in support of the digital building model. Instead of a discrete tool, the Project Information Cloud is a set of principles derived from a proven distributed information network, the World Wide Web. The seven guiding principles of the Project Information Cloud are simplicity, modular design, decentralisation, ubiquity, information awareness, evolutionary semantics and context sensitivity. These principles when applied to the development of existing and new digital design tools are intended to improve information exchange and participation within the distributed project team.

1. Preserving design stories within Project Information Clouds

Design stories form within architectural projects through the interweaving of design conversation, decisions and outcomes. These design stories are valuable in determining a project's current state and they increase the accessibility of information within the design team. Unfortunately, current digital architectural design tools emphasise production and communication of outcomes ahead of the preservation of conversations and decisions. To resolve this shortcoming the concept of Project Information Clouds is proposed as a means of digitally recording and maintaining these design stories. The Project Information Cloud is not a discrete entity but a set of principles. These principles when applied to the development of existing and new digital design tools are intended to improve information exchange and participation within the distributed project team. The principles that comprise the Project Information Cloud are derived from concepts similar to those that fostered the World Wide Web.

Although the architecture, engineering and construction (AEC) industry was slow to adopt digital design processes it is now undergoing rapid digital evolution. This digital migration was both a response to and an enabler of increased information processing demands. Hampering the recording of design stories during this evolution was the disconnect between the tools used to communicate and record design outcomes. Whilst digital communication through email and the Web have significantly improved the quantity of project communication¹, this data often fails to be directly or indirectly associated to the digital design outcome in any structured way. Likewise whilst digital tools used to model architecture can record design outcomes in exacting detail, they do so in a closed, virtual environment devoid of real context. Not only does this closed environment restrict participation, it also limits the ability of those interacting with the model to comprehend design decisions. Subsequently, whilst the AEC industry currently has powerful tools for communicating vast amounts of data and recording virtual outcomes in exacting detail, it lacks a digital vocabulary for weaving these two distinct information streams into coherent and maintainable design stories.

2. Deriving value from digital architecture's design stories

Architecture is as much about personalities and decisions as it is about the eventual built form². A project has multiple design story threads, each one is a subset of the personalities, decisions and outcomes contained in the overall design. The understanding of these design stories is instrumental in enabling a project team to collaborate effectively during the course of the design and construction process. Whilst of limited value at the moment of project conception, these stories appreciate over the building’s life-cycle to fulfill the role of decision making aids and historical learning resources. Traditionally design stories were established through direct participation and narrated to others should the need arise. Digital design is eroding these bonds through its ability to break down geographic constraints and consolidate project information around tightly controlled, data-rich models. This has led to more distributed and efficient design processes. However, it has reduced the ability for all design participants to comprehend and in some cases take part in ongoing design stories. Ironically in an effort to improve efficiency and distribution, digital design tools may in fact be degrading the underlying strength of the design process.

The project team must be able to digitally establish, reinforce and derive value from design stories. Therefore, they must be able to participate in the linking, categorisation and repurposing of all project information, whether it be complex virtual model, conventional plan or digital message. In order for this to take place there needs to be a shift in the way design participants treat their digital archives. Digital design artifacts cannot continue to be isolated and shielded from other project data. Instead these data points and their associated meta-data should be considered as part of a larger network, which when viewed as a whole forms a Project Information Cloud. There are two challenges to overcome if discrete project data is to be treated as part of this larger meta-network. The first is the organisational and legal constraints which accompany any professional exchange of data. Whilst a Project Information Cloud will need to respect the ownership and privacy requirements of existing data, the contributed meta-data used in the establishment of design stories should be considered property of the collective project team. Communal ownership is an essential element of this meta-layer because it will ensure all parties are free to copy, preserve and build upon existing digital stories in perpetuity. The second and perhaps more difficult challenge is to overcome the dominant trend within digital architecture to record all design outcomes within a single, complex and highly regulated digital building model.

3. Why digital building models compromise design stories

To efficiently manage the increased amounts of project information, the current trend in digital architecture is to build increasingly complex and information-dense virtual models. The premise of this trend is that the more comprehensively and accurately a virtual outcome can be modeled, the more efficiently the project team will be able to manage the information and processes associated with it. This objective has seen the traditional notion of Computer Aided Architectural Design (CAAD) evolve into the concept of the Building Information Model³ (BIM). Unlike CAAD, which at its core is a digital extension of the drafting table⁴, BIM accurately records the analytical and semantic characteristics of an architectural design within a highly structured, semi-intelligent digital model. BIM is not a fundamentally new idea and draws much of its technical inspiration from Product Model technologies proven within the aerospace, shipbuilding and manufacturing industries. This combination of CAAD and Product Model results in an architectural information modeling tool capable of utilising semantic data structures to create efficient and versatile working environments⁵. However to attain these benefits the design team must consolidate all significant architectural information around a single, highly structured BIM. Regrettably, by establishing this concise and complex point of truth, the ability of all participants to accurately record and comprehend design stories is diminished.

3.1 Complexity reduces participation

Participation is important to design stories because architecture is the physical representation of a collective decision making process⁶. BIM imposes process and knowledge barriers to participation due to its dependence on a single, complex data structure. In an effort to ensure the digital building model's integrity, the authority to manipulate the data is restricted. Even when permission is granted participants must understand and be capable of using the complicated software interfaces which govern the building model⁷. This participation bottleneck means the project team generally relies on selected participants to funnel relevant design data and decisions into the BIM. Owing to their status in the project team and close association with the digital building model, the role of digital shepherd generally falls to the architect. The architect undoubtedly is appreciative of this fact as it reinforces their place as the project's information and decision making hub. Unfortunately, those who take on this role can consciously or subconsciously filter out information vital in the recording and comprehension of design stories.

3.2 Rigid centralisation leads to editorialisation

Compounding BIM’s participation bottleneck is its rigid and often proprietary data structure. This limits the type and quantity of information capable of being stored within the digital building model. Whilst this enables consistency and efficiency it often requires third-party information to be editorialised and associated with a foreign semantic system before it can be included within the project BIM. This manipulation can potentially lead to degradation of the design stories through editorialisation and confusion. Vendors of BIM are aware of these data storage limitations and are continually extending the semantic structures within their products⁸. However this semantic extension occurs at the risk of increased complexity and also with the knowledge that no rigid structure can handle all potential data or semantic needs during the telling of design stories.

3.3 Virtual accuracy confuses practical reality

Accuracy within an architectural project is crucial but it is equally important to know where inaccuracies and tolerances lie. Architecture ultimately manifests itself in the physical environment and it is important for the project team to understand where, how and why the physical form deviates from its virtual blueprint. Traditional design representation depicted an abstract and partial description of the intended built form. In contrast BIM's capacity to depict a highly accurate, yet ultimately idealised, virtual truth risks impeding the ability of design participants to comprehend or accept the discrepancies between the virtual and physical realms. This is an issue that becomes pronounced as rapid design changes and construction inconsistencies are introduced into the process. If those administering the BIM cannot keep pace with these changes then information will be lost, incorrect decisions made and the design stories will suffer.

It is possible that eventually BIM implementations will evolve to account for the issues raised in this discussion. However, it is highly unlikely that within the foreseeable future a single digital building model will efficiently or accurately capture a project's design stories. Therefore, to ensure accurate recording of the design stories, the Project Information Cloud must exist as a distinct yet supporting element to BIM.

4. Learning from the Web to create the Project Information Cloud

Attempting to accurately record design stories using BIM highlights the inherent problem of using a centralised, highly structured data model to capture decentralised, unstructured decision making. A better means of capturing such data is to establish a distributed Project Information Cloud where all participants can contribute equally. Fortunately, many of the underlying principles and technologies necessary to create such a space exist already within the World Wide Web. The Web is the most successful distributed digital information network currently in existence. This success stems from its ability for anyone to create and link to other relatively unstructured data in meaningful ways.

The AEC industry has not ignored the Web but it is yet to embrace its full potential within the architectural design process. As with every industry, the availability of the Web and email has revolutionised the speed and distance across which project teams can communicate and exchange data. However, the actual processes of the industry itself have yet to be considerably influenced by the Web's principles or technologies. Project intranets have been adopted in a limited fashion within the AEC industry. However, these have primarily acted as digital extensions of traditional filing cabinets rather than as new methodology for collaborative design⁹. Whilst these tools can be valuable management and auditing aids, their centralised nature and the fact they are controlled by one group of design participants generally relegates their role to digital document manager for a specific project team or organisation. If implementations of the Project Information Cloud are to be based on similar technologies then they must overcome these shortcomings. This can be achieved by adhering to a common set of principles which emphasise decentralisation and ubiquitous data formats that all participants can utilise. Establishing a common set of principles will ensure that design stories can be created and openly syndicated amongst the distributed project team.

5. The principles of the Project Information Cloud

For the Project Information Cloud to be established seven guiding principles should inform the methodologies and technologies that constitute it: simplicity, modular design, decentralisation, ubiquity, information awareness, evolutionary semantics and context sensitivity. These principles are inspired by the concepts that have driven development of the World Wide Web¹⁰ yet reflect the objective of the Project Information Cloud to be a common, distributed environment for exchanging design meta-data and preserving cohesive design stories.

The principles of simplicity, modular design and decentralisation are intended to ensure implementations of the Project Information Cloud are capable of accommodating the largest and most fragmented project teams. The principle of simplicity aims to ensure that the underlying data formats and structures that form the Cloud's fabric are easy to understand and replicate. This principle will ensure a broad range of digital design tools can evolve to interact with this space and the design stories it contains¹¹. The principle of modular design aims to ensure that undue influence cannot be exerted by a single participant or software vendor. To achieve this, any component of the Project Information Cloud should be able to be replaced by a similar, independently developed component. The centralisation of digital information is a key inhibitor to storing design stories within the Building Information Model. To avoid this problem the principle of decentralisation declares that the Cloud cannot be formed around, or rely upon, a specific digital information source. Within this space all points of data are of equal significance to ensure scalability and equal participation by all project members.

The principles of ubiquity, information awareness, evolutionary semantics and context sensitively are intended to promote the intelligent distribution of design information throughout the project team. The principle of ubiquity should influence the nature of the digital information exchanged. Rather than stipulating data formats the emphasis of the Project Information Cloud should be on identifying the most common formats available within each project team. As this data is referenced in the Cloud, the principle of information awareness will then ensure that these changes are efficiently syndicated throughout the design team. The principle of evolutionary semantics states that the taxonomy of the Project Information Cloud must be capable of changing¹². This will assist in meeting the diverse and shifting classification requirements of the design stories. Finally, the principle of context sensitivity ensures that design team participants are only presented with information that is appropriate for their role or the project's current state. Through the embodiment of these seven principles implementations of the Project Information Cloud will be successful in digitally recording a project's design stories.

6. Conclusion

Design stories are a valuable outcome from the architectural process. Despite this, project teams lack the ability to easily weave digital information streams into cohesive design stories. The current trend towards centralised Building Information Models has further degraded design stories as these models impose barriers to participation and rigid semantic data structures. The concept of a Project Information Cloud is proposed as a means of allowing participants to record design stories within a meta-data layer that inherits properties of the World Wide Web. By learning from the underlying lessons of the Web the AEC industry can position itself to evolve its digital methodologies and tools. This will enable the formation of Project Information Clouds. Once in place these clouds should improve the project team's ability to digitally record design discussion and its relationship to the Building Information Model. It is envisaged that the Project Information Cloud will provide AEC professionals with a more capable means of utilising their design stories for problem solving and collaboration.

References

1 see Aragon, Patrick. 2006. Reinventing Collaboration Across Internal and External Project Teams. http://www.aecbytes.com/viewpoint/2006/issue_28.html (accessed 3 March, 2007).

2 see Kvan, Thomas. “Collaborative Design: What is it?” Automation in Construction 9, no. 4 (2000): 409-15.

3 see D’Agostino, Bruce, Marisé Mikulis, and Mark Bridgers. Eighth Annual Survey of Owners. FMI/CMAA, 2007.

4 see Willis, Daniel, and Woodward, Todd. “Diminishing Difficulty - Mass Customization and the Digital Production of Architecture.” Harvard Design Magazine 23 (2005): 71-83.

5 see Ibrahim, Mary. “To Bim Or Not to Bim, This is Not the Question.” Paper presented at the Communicating Space(s) 24th eCAADe Conference Proceedings, Volos, Greece, 2006.

6 see Cooper, Graham, Cerulli, Cristina, Peng, Chengzhi, and Rezgui, Yacine. “Tracking Decision-Making During Architectural Design.” ITcon (2005): 125-39.

7 see Kiviniemi, A, M Fischer, and V Bazjanac. “Multi-Model Environment: Links Between Objects in Different Building Models.” Paper presented at the CIB W78's 22nd International Conference on Information Technology in Construction, Dresden, Germany, 2005.

8 see Amor, Robert, Ying Jiang, and Xiaofan Chen. “Bim in 2007 – Are We There Yet?” Paper presented at the Bringing ITC knowledge to work, Maribor, Slovenia, 2007.

9 see Al-Reshaid, K, and N Kartam. “Improving Construction Communication: The Impact of Online Technology.” Paper presented at the CiB W78, Vancover, Canda, 1999.

10 see Berners-Lee, Tim. 1998. Principles of Design. http://www.w3.org/DesignIssues/ Principles.html (accessed August 10, 2007).

11 Berners-Lee, Tim, and Mendelsohn, Noah. 2001. The Rule of Least Power. http://www.w3.org/2001/tag/doc/leastPower.html (accessed March 20, 2008).

12 see Mathes, Adam. “Folksonomies - Cooperative Classification and Communication Through Shared Metadata.” Computer Mediated Communication - LIS590CMC (2004).

A great Web 2.0 Dilbert strip

David — Mon, 10 Sep 2007 08:36:10 +0000

Sad because it is true...

Yahoo Pipes brings mashups to the masses

David — Thu, 15 Feb 2007 10:04:29 +0000

Yahoo Pipes is aiming to be to Web mash-ups what Microsoft Access was to relational databases. Prior to Access, relational databases were primarily the domain of the highly trained database administrator and software programmer. Microsoft Access significantly changed the game by providing a relatively powerful database experience in a manner that the mainstream audience could comprehend and be productive with. As a consequence the business world is now saturated with mission critical Access databases put together internally by the employees themselves to meet a set of data challenges unique to that particular company or department. With Pipes, Yahoo is attempting to become the Microsoft Access of the Web 2.0 market space.

Yahoo Pipes hit the Internet with a splash little more than a week ago. At its heart it is a GUI which enables inexperienced users to perform operations on an infinite number of RSS feeds (and a few select websites). The service does not do anything that a software programmer cannot do already; in fact even slightly experienced programmers can do things more efficiently and with greater flexibility when not using Pipes. Fortunately Yahoo Pipes, like Microsoft Access, it is not aimed at the developer market. Instead its target audience is the overwhelming majority of people out there that do not know anything about programming but do know they have a data problem and a potential solution.

The Yahoo Pipes user interface (click to enlarge)

For example say you are a stock broker and you are interested in news articles related to certain stock, how do you find this information? The 'old fashioned way' would be to scan the various news sites, but this takes a lot of time. A contemporary solution maybe to subscribe to a bunch of RSS feeds from those news sites and keep track of everything on one screen. But even with this approach there is still a lot of on-screen chaff plus sharing this information with others in your business is difficult. Yahoo Pipes enables you to aggregate these news feeds, filter out articles that don't deal with the businesses you are not interested in and then generate a new RSS feed that can be subscribed to by yourself or colleagues. If you think this all sounds too good to be true then checkout this Pipes creation which does exactly what is described.

Sure it is not rocket science but the easy to use interface means that undertaking these mundane tasks is now within the grasp of the interested parties themselves and not confined to software developers. Inexperienced users are helped even more by the fact all Pipes creations are searchable and can be cloned. This means if you are not sure how to solve a problem you can look around to find someone who has solved a similar one and literally copy off them. This conceptual 'open source' is not only a boon for new users but I am sure it will drive lots of talented people to do some really inventive stuff just for the publicity and kudos from other Pipes users.

Yahoo Pipes sure is interesting from a capability perspective but whether it gains widespread business adoption like Microsoft Access is another question. The difference between Pipes and Access is that Access deals primarily with data owned and understood by the user whilst Pipes draws its data from the Web. Consequently not as many applications spring to mind when thinking about generic Web data compared to the well defined internal business data present in most Access databases. Where something like Pipes may begin to gain traction is in the field of linking and making sense of multiple internal data sources, for example a businesses' CRM (i.e. Salesforce.com) and its financial system. The only problem in this field is that privacy comes to the fore and the idea of having an external Yahoo service access and aggregate sensitive business information would go down faster than a lead balloon in most workplaces. What this could mean is that in order for Yahoo Pipes to really take off in a business sense it may have to manifest itself as a standalone device along similar lines as the Google Search Appliance. This would enable businesses to harness the power of Pipes whilst maintaining their privacy and preserving ownership of the data. Who knows, maybe in a few years you may have a server rack half full of Google and Yahoo appliances....

Google to replace Microsoft Exchange & Office at Pixar?

David — Wed, 14 Feb 2007 10:00:21 +0000

This Business Week article 'Google Steps Into Microsoft's Office' is interesting because it is the first time I have seen a rather large corporate entity (Pixar/Disney) express an interest in moving to a non-Microsoft, Web-based platform like Google Apps for your Domain. The other interesting point to note is published user-base of Microsoft Office Live which is sitting at 250,000 businesses, quite a respectable number for a new, non-free service.

I have been a user of Google Apps for your Domain for a while now on a number of domains and have got a few other well entrenched in-house email fans to sign up as well. By far and away the best things about it has been the spam protection and the fact that within an evening you can have a fully functioning email and calendar service up and running with no fuss at all. It has been slightly disappointing that the applications list has not grown to cover the Docs and Spreadsheets products already and many of the new GMail features such as the very handy retrieve mail service or increased storage sizes have not become available to Apps users sooner.

What is the answer to HTML, Web 2.0 and everything?

David — Tue, 13 Feb 2007 11:09:07 +0000

Well it may not be 42 but this great video by Michael Wesch an Assistant Professor at Kansas State University does an excellent job of visually explaining what Web 2.0 is all about and how it differs from conventional media and the Web we all go used to prior to this Century:

Web 2.0 ... The Machine is Us/ing Us

An identity presentation that is not boring

David — Mon, 22 Jan 2007 21:44:37 +0000

Identity presentations can be boring because by and large it is a boring topic full of acronyms, complexities and unresolved issues. This presentation by Dick Hardt at OSCON 2005 breaks the mold so to speak by talking about complicated issues in a very interesting and visual manner. It is worth watching if you are interested in identity or looking for an interesting visual presentation technique for your next Powerpoint/Keynote.

Dick Hardt at OSCON 2005 - Identity 2.0

The Search for Web 3.0

David — Mon, 04 Dec 2006 09:43:11 +0000

The buzz around Web 2.0 may have only started in the last year or so but already industry commentators are putting their opinions in the hat for what will constitute Web 3.0? Such talk strikes me as more than a little premature and what is being discussed appears to be a regurgitation of the technologies proposed during the dot-com boom of the mid-nineties rather than original ideas on how to take what we have learned from the previous two incarnations of the Web.

Discussing Web 3.0 is premature because no one has come to grips with what exactly what the concept of Web 2.0 is right now. There are loose ideas of community, interaction and the writeable Web but no simple, easy to understand description has yet crystallised. Until this occurs its hard to tell where one set of conceptual ideas finishes and another begins. The bursting of the dot-com bubble signaled the end of one distinct period of Web development much like the K-T boundary marked the end of the dinosaurs (mostly). This intense moment of destruction followed by relative calm gave those on the Web time to pause, disseminate what came before and evaluate the best way forward.

To make matters worse discussion about what Web 3.0 could be appears to be centered around the relatively old concepts of the Semantic Web. Whilst a nice idea such arguments ignore the fact that Semantic Web ideas existed well before Web 2.0 concepts and in terms of realising these grand ideas not a great deal has changed. From a technical perspective the enabling technologies are still overly complicated and at a practical level no clear upgrade path exists from our current dumb Web to this idealised space (apart from millions of hours of painful, manual classification). Of greatest significance the Semantic Web relies on our ability to generate classification systems for many different forms of data. Given that a single office document standard cannot be agreed to and development of in-depth, domain specific semantic languages such as Industry Foundation Classes are stalled such a proposition seems far off.

Rather than a complicated semantic model I believe a more suitable candidate for the Web 3.0 crown would be the concept of the Learning Web. A Learning Web would successfully marry human input (gestures) to digital processes and would be an interesting proposition because unlike the Semantic Web it builds on social groups, can be understood by the casual observer and most importantly offers a clear monetisation pathway in the form of the Gesture Economy (something Steve Gillmor has been talking about for a long time). Emerging tools like Riya are beginning to embody such concepts. Riya is a visual search tool that uses human input to train search algorithms (similar in the way speech recognition works). Without human input searching is no better than contemporary technologies, but once real-time user feedback enters the fray things start to get really interesting. The beauty of such an approach is that whilst the results are smart the underlying data-set is still inherently dumb which means simple underlying technologies and an easy uptake for developers and users alike. Such a place would not be nearly as intelligent as that proposed by Semantic Web advocates but from a practical perspective it would work just as well for many tasks. But perhaps of more significance to us, the end-users and inhabitants of this space, it would operate at a human level well below the Matrix-like autocracy of that envisaged by the semantic model.

The emerging future: Software as electricity

David — Wed, 11 Oct 2006 10:04:23 +0000

There has been rumblings about software as a service and Web 2.0 revolutionising the way people work with their computers and data but very little to really illustrate this point. Whilst the average person is comfortable with having their email and chat hosted by Google, Microsoft or Yahoo the idea of businesses trusting third parties with hosting their software and data is a foreign one.

Companies like Google, SalesForce.com and now Zoho are out to change this attitude with a direct push at the business marketplace. You know an I.T. concept has momentum when it has its own conference, and now with the Office 2.0 Conference there is a showcase for business orientated, software as a service applications. TechCrunch has been doing a very good job covering the new applications released during this conference. Zoho seems very interesting from a software capability perspective although successfully marketing this service within the industry as it stands today will no doubt be difficult. However it is probably more likely that Zoho is concentrating on their application feature-set with an end-game of being purchased by a larger company (Yahoo, AOL). This larger company will then rebrand Zoho and use it to compete with Google's emerging online office suite and Microsoft Office Live.

Whilst promising the major barrier to serious online office migration is psychological rather than physical. Arguably the Web applications and infrastructure exists to move many traditional office tasks and accompanying data to a remote, online environment. Sun's CEO Jonathan Schwartz has been talking and blogging a great deal about businesses ability to centralise and externalise their data-centers and in a completely practical world this makes sense. However the largest barrier to all this is people's assumption that the Internet will go down. Unfortunately in many places this belief is a reality, such as with low-end DSL/cable connections in New Zealand, but at the high-end Internet connections are just as reliable as electricity or other established services.

As Internet reliability improves there will come a time when network access is viewed in the same light as phone, gas and electricity services; as long as you pay your monthly fee it will work. When that time comes there will no doubt be a significant shift in offices from internally hosted identity, email, file services and applications to remote services maintained by third parties. The office space and infrastructure savings alone will justify the remote hosting costs and more importantly removing the headache of maintaining internal data-center infrastructure will, in theory at least, allow businesses to concentrate on the things they do best.

The company that stands to potentially loose the most from all this is Novell as their primary market is internal server infrastructure. In an environment where office server infrastructure declines Microsoft will still have the desktop whilst online companies such as Google and Yahoo will be at a greater advantage compared to Novell with their compartmentalised application suites. In this light it is especially unfortunate that iFolder, Novell's most promising product in this emerging environment, appears to have been put out to pasture without it ever gaining the emphasis or adoption it so greatly deserves. Whilst it will be a long time before software as a service and the whole Office 2.0 concept becomes a reality when it does I hope Novell is not caught napping like they were with every other technology change that has occurred in the last ten years.

Reasonate testing completed and a good quote

David — Mon, 26 Jun 2006 04:55:45 +0000

I have been taking a bit of a break after the successful completion of the Reasonate testing within the BBSc303 course. There's been a couple of interesting articles appear in my newsreader recently. The first has a good construction analogy for 'Web 2.0'.

"An analogy from the world of building construction perhaps clarifies the distinction. Web 1.0 was like building houses from cement, sand, crushed bricks and aluminium. You had to mix cement, bricks and sand together to make concrete, then use concrete to make the house. With newer Web 2.0 technologies you effectively have concrete, prefabricated walls, corrugated iron sheets, etc to build houses. So you can make more interesting and elaborate houses than before.
Many Web 2.0 building blocks are available as open-source software products. These products are, for the most part, free to use. Further, the source code (ie, the engineering blueprint) is usually available for developers to modify as needed. Since there is a huge variety of open source software (for example, SourceForge, a repository of open source software, has over 115000 projects), the programmer can mix and match the right tools and build a program very quickly (and cheaply.)

So, continuing our construction analogy, Web 2.0 programmers not only have ready-made concrete, but it is free ready-made concrete!"

Unfortunately there has been a lot of debate recently over the term 'Web 2.0', mainly caused by O'Reilly making moves to copyright the term because apparently it was Tim O'Reilly who originally coined it. This move certainly peeved a lot of people off who had considered the term more a definition of a genre/ideology rather than some new trademark to be monetised. Anyway in the future I'll be steering clear of using the term Web 2.0 just to avoid any controversy that will continue to plauge the term over the next six-twelve months.

About Reasonate

David — Mon, 15 May 2006 04:00:49 +0000

For the last few months I have been very busy developing and testing Reasonate within the BBSc303 ‘Digital Craft’ class at the VUW School of Architecture. The main purpose of the testing was to evaluate the adoption rate and usage trends of blogging and tagging within a simulated team design process. In concert with this goal the testing was also used to establish what sort of toolset design-orientated bloggers require, especially when operating within a structured environment of project groups, tutors (fellow students) and course coordinators (the lecturer, Mike Donn and myself).

In this test the ‘process’ is the digital modeling of an existing art gallery. The ‘design’ aspects are centred around the decisions the teams must make whilst modelling and rendering this existing building. The types of decisions ranged from the selection process of the gallery, choices on CAD standards and the moves made to overcome modelling/rendering issues during the project. Previous BBSc303 courses have run for the last eight years using a similar format, but rather than using a blogging system the design process documentation occurred at the end of the course and was presented in the form of a static HTML website (usually one or two pages linked together).

The major drawback of the process previously undertaken was the quantity of last minute, post-event justification that took place. Rather than documenting the actual processes as they happened the final submission was usually a last minute exercise outlining how things hypothetically occurred in an ordered fashion (whereas arguably most project decisions where more evolutionary or accidental in nature).

The functional purpose of Reasonate was to get students blogging their activities as they happened. In the course introduction guidelines on exactly how this blogging should be undertaken (in terms of frequency and content) were deliberately left open for interpretation. What was made clear however was that the marking process would only concentrate on Reasonate submitted content so the obligation was on the students to get as much online as they felt comfortable with in order to qualify for marks. In a follow up lecture nine weeks after the beginning of the course further emphasis was placed on the story-telling requirements of the process after observation that many blogs had a very strong scrapbook feel to them.

Functionality

Reasonate was developed as a web application and made available for student use within and outside of the University at http://www.reasonate.co.nz. For the testing process Reasonate had to support the following functionality in order to satisfy course requirements:

Identity of students and flexible project groups

Arguably the most important feature of the system was the ability to create student identities that could then be associated into project teams. Creation and basic management of project teams were left up to students to perform whilst the administrator (Mike Donn) held final sway as to whether the proposed project and student combination was accepted or not. The project construct aggregated the blogs of the participating students. This aggregation generated project blogs that were the sum of all the student blogs associated to a particular subject. This aggreated blog system is very similar to the philosophy behind the Planet project.

The aggregated project blog (click to enlarge)

Blog posts

The primary form of data entry was through blog posts. The interface provided a Javascript based WYSIWYG HTML editor (TinyMCE). The HTML editor provided the ability for students to set font and colour characteristics and easily insert tables, hyperlinks, tables and lists. One feature not included was a spelling checker as at the time this was seen as superfluous to requirements. In practice however a spelling checker probably would have been appropriate given the often poor quality of grammar employed by students.

The new post interface of Reasonate (click to enlarge)

Uploading of files to posts

Digital design is a file-based process so the simple uploading of files was viewed as necessity. The upload process utilised the email philosophy of ‘attachments’ rather than embedding file links directly within the HTML posts. When students uploaded a file a basic form of versioning was employed, the file was saved on the server with a datestamp preceding the real filename. This allowed multiple versions of the same file to be uploaded without naming conflicts occuring. Within the Reasonate database a file entry was created that linked the datestamped file with the original filename. Project files of the same name were considered to be different versions of the same file and within the Reasonate interface it was possible to view and navigate between the different versions of the same file.

Tagging of blog posts

Tagging was employed as the second level of semantic categorisation above the basic project construct. Tags could be applied within the system to all pieces of data (blog posts, people, files, projects). The interface employed an AJAX mechanism that allowed tags to be added relatively quickly. During the tagging process dropdown list of tags were displayed that matched the letters already typed by the user (predictive tagging).

The tagging system in Reasonate

The mechanism employed had a number of issues. Firstly the suggestion system was very basic and relied on initial user input to provide suggestions. This of course required the user to have a fairly good idea of what they wanted to tag in the first place. Del.icio.us employs a much more intelligent system where tags can be suggested to the user prior to any input being entered. This suggestion system however requires a unique fingerprint (in del.icio.us’s case the unique URL) and a large body of fingerprints/tags to search against. Within Reasonate this large body of fingerprint/tag combinations does not exist to search against plus the posts themselves hold very little characteristic information in order to automatically suggest tags based on the subject’s content.

The del.icio.us extension for Firefox showing tag suggestions (click to enlarge)

An interface issue was the fact tags could not be added to content as it was created. This was an application issue as the underlying tag data-structure required content to exist before a tag could be associated with it. This interface issue made tagging rather convoluted, content had to be created and then tagged in a two step process. A far more efficient and user-friendly process is to have content creation and tagging all part of a single step process.

Another interface issue was the single entity nature of tagging. Rather than using a basic text field and adding tags as a comma delimitated set of words tags were added one by one. In hindsight whilst arguably more aesthetically pleasing this process was slow and disjointed compared to the simple data-entry mechanism that is a text-field.

Finally yet another limiting interface issue was the minimal tag browser interface employed in the first half of the testing process. Rather than tag clouds or different lists showing personal, project and class tag lists the initial interface only listed a users personal tags and next to it a number indicating how many posts had been tagged with this item. This was very limiting from a functionality perspective as it did not allow for the simple browsing of team tags or relate this information to how the individual was using tags. These information issues came down to development time (or lack of it) and the necessity to develop other pieces of functionality such as the search engine before coming back to reassess user interface characteristics.

Indexing and searching of blog posts, tags and files

The search index used Ferret, a port of the Java Lucene search engine to Ruby (with a C search indexer backend). The search engine is very capable and allowed for different weighting of fields (tags given precedence), full text indexing of content and a complex boolean search query language. Overall implementation of the search engine went well and the resulting search capabilities were simple yet powerful. The degree to which this functionality will be used in the test environment is uncertain however given the short term nature of the project and limited quantity of data employed by the students.

The Reasonate advanced search interface showing the different options for finding things (click to enlarge)

RSS feeds of blogs and search results

All aspects of the Reasonate system are RSS enabled. Feeds can be generated for student and project output, search results, use of tags and changes to a particular file. Application of this functionality within the course was limited by two factors. Firstly most of the students worked side by side and as a result did not need to utilise RSS functionality in order to understand the progress of their team.

Secondly there was a technical issues regarding the use of RSS readers in the University and other locations. At the University RSS bookmarks were deleted when students logged out of their workstation. Consequently using RSS soon became a chore as each time the students logged in they were required to recreate their RSS bookmarks. In many other locations (such as office workplaces) students were not allowed to install third party software (Firefox/Sage) and as a consequence it was felt RSS could not be used. After these issues were brought to light a few online RSS readers (Newsgator/GReader) were illustrated to the students as a means of tracking project work.

RSS was very successful from an administration perspective however because both Mike and myself had well established RSS software and reading habits. Consequently it was easy to keep an eye on student output which assisted in the early identification of problem areas and low output students. From this teaching/supervising perspective RSS was very interesting. Rather than meeting with students at a specific tutorial time there was a greater sense that work was being evaluated continuously 'on-demand' so to speak. Following through with such a concept could be a very interesting way to run tutorials in the future, rather than paying tutors to be present at a certain place for a period of time emphasis could be placed on RSS based tutor support. Half a tutors time could be spent in physical tutorials whilst the remainder allocated for solving problems as they occur online.

Hierarchical commenting to blogs.

Easy commenting was important in order to establish a platform for post blogging discussion. Many blog posts require either some form of clarification or discussion between users following the initial action of posting to the service. The commenting system employed was hierarchical in order to distinguish between different discussion threads on the same blog post. I was concerned that comment threads could change subject or be commandeered by another user to promote ideas not related to the original post. To counteract this threat the comment field was kept relatively small in size in order to give the visual impression that comments should be quick and to the point.

Another feedback mechanism discussed but not yet implemented in the test environment is the concept of a Trackback. A trackback is a completely new blog post by another user (or the same user) related to the ideas of the original post. The new post notifies the original post of their actions through the use of a simple ‘ping’ action. This action notifies the original blog of the new post, its author and url. The system tracks these Trackbacks and displays them as a list of hyperlinks following the post. At this point in time Trackbacks have not been implemented and given that there is no demand from students for such a service they will not be added to the test environment. From a pragmatic perspective the hardest part about Trackbacks is not the technical implementation but explaining to users how and when such a feature should be used. The concept is difficult for many technologically savvy users to understand, let alone explain to a class of students who have only just begun publishing content to the Web.

Implementing the test environment

Most of the Reasonate functionality was in place at the start of the course (late February) after a brief but intense development period in late January. Commenting and search functionality where not introduced until mid-April primarily because for the opening month the emphasis was on getting the posting and project mechanisms working correctly.

For the first six weeks Reasonate was hosted on one of my own servers whilst the core system was built and the majority of the bugs ironed out. For the most part this hosting went well apart from a few Internet outages and one major hardware failure. Bandwidth was stretched in the final week of hosting as students, unaccustomed to the low-bandwidth nature of the Internet struggled to upload multiple 20-30 megabyte Powerpoint files to the server.

Following this period Reasonate was moved to an upgraded School of Architecture server. This move removed the bandwidth bottleneck but made management and regular backups slightly more difficult.
During this testing regular nightly backups were taken of the Reasonate database to allow for time-based analysis of data entry activity and usage trends at a later date.

Uptake

Students were slowly introduced to the Reasonate concept over a few weeks during the introductory tutorial process. A questionnaire for the students past computer experience has not been carried out but it is planned in the near future. From past experience however most students have little or no Web knowledge at the beginning of the course (learning about the Web is a primary factor for taking the course). Given this limited base of experience students were quick to take up the blogging aspect of Reasonate. For the tutorial process lasting three weeks most students averaged approximately four blog posts whilst some did far more.
After the initial phase of testing the following functionality requirements also became apparent:

Email notification of new blogs and comments

Students knew RSS feeds were available to the course co-ordinators and as a consequence assumed any piece of content they published was immediately read by those in charge or in their group. Consequently some important questions posed in blog content were not answered as quickly as possible by Mike and I. In our defense we were suffering ‘information overload’. 50+ students plus 30-40 other sites content is a lot of RSS content to parse and respond to regulary, especially when faced with a similar number of other communicae (in the form of emails, meetings, instant messages, mobile phone txt’s). Also it was found that in order to undertake digital conversations with or between students data had to be entered twice, once with the comment post and a second short email saying a comment had been posted. Otherwise the alternative was to just send an email and bypass the test system. In practice a method of capturing email collaboration would be the preferred solution but in the testing environment it was ideal for most Reasonate specific conversation to travel through the comments mechanism and be captured for later analysis. To satisfy these needs email notification of comments was added to provide the best blend of email’s ability to alert people and Reasonate’s capability to capture and search conversation.

WebDAV support for the project hand-in on student produced mini-websites

This capability was very course specific and added in order for students to create their own mini-websites and have them easily published to the Internet. In practice such a system would be of limited practical use and in many respects actually worked against the underlying principles of blogging where normal people do not have to worry about such things as Web naming conventions and html standards.

Whilst perhaps superfluous to the ultimate goal I did like the way WebDAV seamlessly integrates onto the users desktop (all the major operating systems support WebDAV file shares). This coupled with a versioned file-attachment system for blog posts would be very useful. In practice the WebDAV share would need to be read-only as the spec and its implementations do not provide for on the fly versioning of files but even then a file browser view of the latest project files as uploaded by participants would ease usability.

Wrap-up functionality to allow the simple aggregation of multiple blog posts into a cohesive story

This functionality is very important, so important in fact I will be giving this one its own post on this blog. Thinking about this started when a couple of things occurred. Firstly it was observed that most students were using the blogging system as a form of virtual scrapbook. Whilst most were blogging very regularly their posts were not a cohesive or descriptive as one would have imagined. In fact for the most part blog usage was quite different to general blogs you see on the web today. Rather than larger posts on a single subject many students blogs resembled stream of conscious thought process in a highly conversational (email) style. This was not a ‘bad thing’, we had on purpose left students free to develop their own blogs. Rather than returning with the more conventional long-hand style writing as employed conventionally the students had, either subconsciously or through peer observation, developed a very brief (one/two sentence) prose.

Mike’s observation at this was that he was not going to read through all these tiny posts in order to mark the project at the end. Initially we discussed using the student’s basic html web page submission as the venue for the summary texts for the blog but after a bit of thought this just felt wrong. The intention of Reasonate was to capture the design development process and to a certain degree we had. Ironically what we had captured was like any design development process, fragmented, terse and by itself not enough to understand the overall objectives, processes and achievements associated to the endeavour. What was needed was a mechanism easily ‘wrap things up’ into a format that was easily disseminated by the casual observer yet retained the rich chronological underpinnings the blogging process had successfully established….

Windows Live to host college email

David — Wed, 03 May 2006 08:32:31 +0000

I talked about Windows Live a while back and so news that 72 U.S. colleges will be using Windows Live for student email services seemed quite relevant. It makes sense financially for the colleges and from Microsoft's perspective it gets customers early before they have made a definite decision on who their email provider will be. No doubt Google and Yahoo will soon be following this same path with their mail services in an effort to build (Google) and maintain (Yahoo) their user-base.

The move is another vindication of the software as a service concept and will help bring some sanity to educational IT departments. Victoria University should adopt the same policy for student email and file storage. If not sponsored by Microsoft/Google/Yahoo they should at least scrap student email and file storage services in favour of Google/Microsoft/Yahoo email and personal USB keys. The savings whilst not huge would add up over time, plus I am in no doubt that the big players could provide a better level of service and featureset than what any over-stretched educational IT department could ever provide.

Software as a Service - myths destroyed

David — Mon, 01 May 2006 11:48:03 +0000

Recently I have been giving a lot of thought to the Software as a Service concept. The basic idea behind this catch phrase is that rather than paying a lot of money up front for a piece of software and/or server combination you subscribe to the software online and have it hosted remotely. There's obviously a couple of concerns over such a model, firstly you have got to trust that these companies do not go out of business plus you have to be confident that your Internet connection (and theirs) will be working whenever you need the service. A lot of these myths have been put to rest as this Business Week article illustrates, but for hard-core (old school) network administrators the idea of out-sourcing essential software sends cold shivers down their spines.

The concept really got stuck in my head when a friend of mine sent a general email asking for people to help him convince a small business to purchase a general purpose (mail/calendar/file/print) server. After having my share of bad server experiences and over demanding clients I eventually came to the conclusion that installing a new server in a small/medium business is a really difficult thing to justify when pitted against the new Software as a Service model. For example if you were to sign-up for the GMail hosted email service (where they host your email domain) you get email, calendar and instant messaging services all for just a few only slightly annoying adverts. Alternatively you could go the Microsoft Office Live path which does not provide as much storage space and costs more but could get very interesting as these services are integrated into the traditional Office suite. For data there are some pretty interesting looking NAS (Network Attached Service) devices available that provide local network storage without the hassle of running a full blown server. Then as long as you purchase decent network-enabled printers you have a complete small/medium office solution for a lot less setup and ongoing support costs than a conventional Linux/Windows/Netware server.

From a network administrator's perspective this model is at first scary (on one likes being out of a job) until you realise that you can now spend your time working with users to get these services working for them rather than just simply working, which is their current (and only) ongoing concern.