30
team members. However, it was time-consuming to read and not comprehensive. At the end
of the exercise, I had no time or incentive to contribute any tips of my own.”
This finding corroborates observations that knowledge databases can have limited effectiveness
unless a system of incentives is provided (McDermott 1999), such as through implementation of
reputation mechanisms similar to those found in online auction websites (Jensen et al. 2002). It
also merits investigating the extent that implementation of intelligent search mechanisms
(Zaychik and Regli 2003, Fruchter and Luth 2004) can improve the usability of IDRAK.
5
FINAL CONSIDERATIONS
The main contribution of this research is a novel methodology to evaluate the usability of
prototypes for supporting digital socialization in geographically-dispersed, or ‘virtual’,
engineering design teams. We should not, however, lose sight of the limitations of lab
experiments. While the majority of the participants found the experiments a valid simulation of
‘virtual’ work, the real-world is much more complex than our lab setting. Engineering design
projects involve more than four participants, decision-making involves many more intricate
variables and problems, and the Delta exercise itself only mimics the demands of work at the
feasibility stage. Thus, there is a case for investigating new evaluation methodologies that can
provide even more accurate insights on the extent proof-of-concept prototypes can be scaled up
to enhance collaborative work in real-world projects. Because organizations appropriate similar
technologies in different ways, it would also be beneficial to understand how rules in formalizing
digital collaboration can affect the usability of digital systems: under which circumstances should
design teams resort to chat-based communication vs. voice/video vs. getting physically together?
What privileges should digital systems exclusively grant to project managers? How should lines
31
of authority be communicated in virtual teams? These and other questions clearly demonstrate
the need for further research in this area.
APPENDIX I – THE ARCHITECTURE OF IDRAK AND IMPLEMENTATION
The architecture of IDRAK (Figure I.1) is based on two protocols: Real Time Messaging
Protocol (RTMP) and Hyper Text Transfer Protocol (HTTP). IDRAK uses RTMP to support the
synchronous communication in the Dialogue, and HTTP to support asynchronous
communication in the Repository. IDRAK also uses a server-based platform – Macromedia Flash
Communication Server (FlashCom) – to support the implementation of the interactive web-
based, real-time collaboration application.
Figure I.1 Web Architecture of IDRAK
AMFphp
Remoting
AMFphp
Remoting
HTTP
RTMP
php
SQL
Query
Application
Server
FlashCom
Server
asc
Streams
Shared objects
FlashCom
Application
Directory
Database
Server
FLV
FSO
Flash Client 1
Flash Client 2
Flash Client 3
PHP
scripts
ActionScript
scripts
Data
Integration
Layer
32
The implementation of IDRAK is based upon a 3-layer architecture: Data Integration, Business
Logic, and Presentation. The Data Integration layer manages the data required by IDRAK ─
‘Shared Objects’ and ‘Streams ─ through a MySQL database server (an open source relational
database management system) and a FlashCom Application Directory. The Business Logic layer
contains and executes the rules that run IDRAK using Server side scripts; it is written in PHP
language and ActionScript. PHP is an open source server-side programming language that allows
creating dynamic content to interact with databases. ActionScript is an object-oriented
programming language based on ECMAScript, the international standardized programming
language for scripting. ActionScript files are used by the Flash Communication Server and
executed by the ActionScript Virtual Machine (AVM) built into the Flash Player – a universal
rich client for delivering video, text, audio, and graphics across desktops and devices. The
Presentation layer delivers the application to the end users on the WWW in a Flash Player.
The Business Logic layer is the ‘middleman’ between the Presentation and Data Integration
layers. A request performed by an end user on the Presentation layer first goes to the Web server.
The Web server directs the request to the application server on the business logic layer, which is
processed in a request/response model through Flash Remoting. The remote client makes a
request on the application server, which returns the information in the response object. Flash
Remoting is a technology built into the Flash player core that enables sending data between the
server and the client seamlessly. IDRAK uses AMFPHP as an open-source Flash Remoting
gateway that can seamlessly synchronize Flash user interface elements with databases and other
data stored on distributed systems. Finally, the processed request is returned to the Web server
where the information is encoded and sent back to the user’s browser on the presentation layer.
This architecture enables IDRAK to be consistent and extensible. IDRAK looks exactly the
same to every user without requiring users to install additional components, although different