The Collaborative Dynamic Art Project



The Collaborative Dynamic Art Project

CSE 403 – Software Engineering

Cy Khormaee

Andy Olson

Alex Zheng

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 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 web-service 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 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 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 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.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download