The Collaborative Dynamic Art Project
CSE 403 – Software Engineering
Cy Khormaee
Andy Olson
Alex Zheng
1
Operational Concepts
With the advent of the internet, the overhead of communications has become effectively nullified.
The artistic community has taken great advantage of this fact to expose their work with a broader
audience. However, artists have not yet begun to truly embrace the opportunities for cooperative
project development offered by the advancement of this new media. The postmodern ideals of
embracing fragmented diversity and rejection of abstract meaning can be best realized by calling
upon several different minds to develop a single work of art.
The Collaborative Dynamic Art Project’s objective is to provide an online forum through which
artists can meet to develop each other’s work. By leveraging the reach and diversity of
individuals contributing to online content, an artist can integrate an unprecedented volume of
diverse intellectual content into their work. And, if The Collaborative Dynamic Art Project
enables artist to successfully apply this content in a cohesive manner to a single piece of art, it
will represent a proof of concept for a new framework for the development of a new ideal for of
postmodern art.
System Requirements
In order to promote collaboration as the primary objective of this project, an extremely portable
and versatile online digital art form had to be selected as the primary media for The
Collaborative Dynamic Art Project. The Processing environment, developed by Ben Fry and
Casey Reas in the MIT Media Lab, is an open source (GPL) enables users to create dynamic
interactive digital visual art with the benefit of OpenGL 3D acceleration. And, while this
environment allows for simplified serial port access, and video integration, its primary focus is
the translation of algorithms into visual art. Compositions developed in Processing are compiled
into a Java applet, and inherit all the portability of that media.
Processing is also optimal for the development of a collaborative artistic environment simply
because of its versatility and ability to encapsulate complexity. Its temporal element is able to
capture an infinite amount of complexity from a variety of authors. Also, the fact that Processing
art is typically algorithmically based, developing filters for or additions to the original algorithms
offers a simple but effective manner in which users can constructively develop a composition
However, the primary focus of The Collaborative Dynamic Art Project would be to provide the
communications infrastructure through which artists would be able to cooperate. Primarily, this
entails porting the Processing application to an online service and the creation of a community
framework. In order to port Processing to an online service, we will have to develop a front end
user client development environment which can communicate with a server capable of on-the-fly
remote compilation. The primary reason for this division is that the size of the Processing IDE is
currently 26 MBs, which is clearly untenable for a ported applet.
The community framework of The Collaborative Dynamic Art Project will primarily consist of a
front end user portal through which users can create and modify projects as well as communicate
with each other via a contextual (project centric) message board. More specifically, after a user
selects a project, its evolution will be visualized via a directed graph where each node represents
2
different variation on the original piece. A user may create a child for any node by simply using
that node as the original for a new piece of art. In the end, a piece will consist of a tree
representing the progression of the work over time.
It is important to note the distinction between The Collaborative Dynamic Art Project and
collaborative source control systems such as CVS or even a Wiki. The goal of this project is to
provide artists with the capability to observe and take part in the evolution of an initial idea and
composition. The tree representing the evolution of a composition is the finished product rather
than a single document as is the case for a product developed with CVS or a Wiki.
Also, in recent years, a few have attempted to create a framework with a similar idea of
promoting collaboration. Most notably the Collaborative Art Project authored by Tom Groves.
This project provides users with a simple 2-D drawing interface which users have been
continually editing over the last two years. While a few interesting variations arise, more often
than not, the canvas is simply overwritten by another user. This represents an interesting, but
largely unsuccessful foray into public collaboration.
The Collaborative Dynamic Art Project is able to remedy much of the issues of the original
Collaborative Art Project by provided a temporal element to the composition. The Processing
“canvas” is infinitely large, so users will be able to simple add to rather than overwrite
preexisting work. Also, the versatility of algorithmic manipulation enables users to make
modifications which alter rather than replace the original essence of a piece. And, lastly, the
evolutionary structure provided as a navigation element in The Collaborative Dynamic Art
Project will encourage users to adapt a common theme of the lifetime of the piece rather than
using the evolutionary structure as a chronicle of disjoint compositions.
System and Software Architecture
The software architecture for The Collaborative Dynamic Art Project can be divided into two
major domains: Client and Server. It is important to reiterate the fact that the Processing IDE
will have to be split into a compiler (residing on the server) and a client editor (residing in a java
client). When a user wants to run their script, the script will be sent to the server, which will
then compile it into Java code and insert it inline into the user’s view page. This will eliminate
the need for a user to download all 26 MBs of the Processing environment. In other words, the
server side does the hard work for the client, and the client only sees the results.
With this in mind, the Client domain as a whole will consist primarily of the mechanisms to
visualize the project information and the front end client for the Processing Environment. And,
the server would contain mechanisms to handle the transfer of data (between client and database),
servicing page service requests, and dynamically generating the HTML to display the page
information.
The implementation of The Collaborative Dynamic Art Project can be composed of either the
open source LAMP (Linux, Apache, mySQL, PHP/Python) architecture or the Microsoft webservice architecture. In the LAMP architecture, the server would be a Linux based system
running an Apache web server. When a page is requested by a client, the Apache server would
3
request a PHP or Python script to be run which would use the data from the mySQL database to
dynamically generate an HTML page to pass back to the user. The primary advantage of this
architecture is its strong security and low cost.
The alternative Microsoft web-service architecture would use a computer running Windows
Server with Microsoft Internet Information Services (IIS). When a page is requested by a client,
the IIS server module would request an ASP.NET application to use data from the SQL Server
database and use it to dynamically generate an HTML page to pass back to the user. The
primary advantage of this architecture is its development speed and advanced feature integration
(such as ActiveX COM Objects).
While both of these architectures have their own unique strengths, in the end the architecture will
be contingent upon the expertise and preferences of the development team as well the available
technologies. Nevertheless, in the end, all of the components of our online services platform are
industry standard and have been used in other large scale projects. The larger risk in the
architecture of The Collaborative Dynamic Art Project is that we would have to rewrite a large
portion of the Processing Environment source to allow it to be divided into client and server
pieces.
Lifecycle Plan
The Dynamic Collaborative Art Project proposal is targeted primarily as a lightweight
collaboration and development tool for the Processing community, however it also has impacts
into the broader art community. The project creates a simpler, more portable and accessible
method of digital graphics production. This could potentially increase the popularity of digital
artwork and specifically Processing based artwork. It should be noted that the project allows for
increased online collaboration and idea sharing, which are common threads in current
technological progress. The open-source computing technology in general can benefit from
online demonstration projects of concepts such as collaborative work, distributed programming,
and community-based idea sharing. The University also benefits from hands-on experiments in
student learning for software engineering such as this one.
We chose the Staged Delivery (Agile) Model of development for constructing our project. The
choice of development process was rooted in the need for high levels of organization and strong
upfront design in this large project. The modular nature of the project lends itself to using the
Agile model. The project as a whole can be split into parts for separate or parallel development.
Since the project is also heavily based in user interaction, having multiple release points gives us
several chances to gauge user acceptance and respond to it accordingly.
There are several major components in the project that can be separately developed. The main
ones are the database, sever applications (drawing, displaying old projects, and editing new
projects), communications infrastructure (message board), the client interface, and the
interactions between the various parts of the project. Each application can be tested as a
standalone application, and then combined with the other working applications as part of the
integration process. The big risks in development are in creating the client interface and
database infrastructure, since they play such a central role in the project and in the performance
4
of the application as a whole. This involves separating the Processing application into a client
and a server part, which is a non-trivial task. Many of the components need to draw information
from the database to yield anything useful. Therefore, the database should be developed early so
that useful development of the other parts can be done. The user interface should also be
developed early, at least in a preliminary form, so that user feedback can occur. After those
components are completed, the applications and the message board can be developed in parallel
and integrated with the infrastructure one at a time. This minimizes the risk in integration
because each component can be attached to the others separately, and allows for deliverables at
each stage because the project is developed in modularity.
Feasibility Rationale
With any project, the design is often limited by the resources available, in terms of both time and
human and computing resources. In designing a project for 6-8 people of varying abilities and
availability over an 8 week period, there should be an inherent flexibility within the design. The
design that we have proposed allows for modular development of system components, and a
large spectrum of variability as to what should be added to the core project. At the core, the
project should be allow users to start new projects, see old projects, edit old projects, and post
their own projects after they are done. This requires that the database, drawing applications,
display applications, and user interface are all completed. Beyond those basic requirements,
there are also many additional upgrades that can be done that can be added on top of the core
system. For example, the addition of a forum for commenting on drawings, or the modification
of the drawing application to allow for multiple users to edit the picture at once, or the addition
of user logins for protected work environments. These are all optional additions that could be
added in if resources permit, but that are not crucial to the fundamental operation of the idea put
forth.
The architecture of the project design is not extremely risk-prone. The design is based on proven
client-server architectures, taking advantage of existing software, such as the Processing
application and the .NET framework. The design made use of widely-used applications as much
as it could to provide consistency, and there are several backup software applications that could
be substituted in for any particular part of the design if we are unable to gain access to certain
software suites. The idea is not extremely risky. All of the components that we have chosen
have been proven by industrial applications, and are generally considered reliable and easily
integrated with other components.
Conclusion
The Collaborative Dynamic Art Project is an idea that would change the way that people think
about artwork, online collaboration, and the Processing community. While it is not a trivial
project, it has been designed with proven software and processes to reduce risk. We hope that
we will be given the opportunity to develop this project in the coming weeks.
5