CØDEshop

Three days of staking shelves for the new economies emerging from collaborative practices in art, digital culture and local politics.

Day 1: Curatorial Processes
_ is it a time for an alternative structure of exchange?
_ who are the protagonists in the performance of cultural production?
_ how does software change our relationship to memory?

Day 2: -O-b-j-e-c-t- contemporary art practice
_ how do you want your project, artwork, be remembered?
_ can software liberate you from the white cube?
_ what gets lost between the formal structures of established practices?

More detail ... context glue

Where we are ...

A show via liquid would be based on a number of works, in a traditional context we would consider the curator identifying the works in question, however this may not be the case in liquid. The physical and technical setting for encountering a work can be a highly significant factor, however for the present a relatively pragmatic decision is that the works will be browser ready. The feature of the setting that liquid will support is showing of the works and the contextual views that are associated with them or support them, that is providing a context. The contextual views can vary in technical complexity from windows about a work with static or independently dynamic content, through to "working with the work" views - for example a context view that provides some real-time interaction with the work. Architecturally, it makes sense for the working with the work views to be provided via the server hosting the work, where as independent views can supported by the liquid server. (See outline indicative XML image)

Technical Spec version two

Apologies for the delay in posting this. Here is the updated version of the technical specification.

Notes from Workshop 24th of July 2006

ATTENDEES:
Colm Lally, Simon Gould, Chris Roast, Fiddian Warman, Matt Wade

AGENDA FOR THE WORKSHOP:
1. Recap on where the project is to date [chris]
2. Questions from attendees
3. Questions from absentees [Graham Harwood and ap]
4. Questions from researchers
// break
5. reflect on the workshop and plan next steps

============
the following notes were recorded by Jo Hamshere and edited by Colm Lally

CRITICAL QUESTIONS RELATING TO WHERE THE PROJECT IS NOW:
- the project is currently heavily angled at the environment, is the project just about reskinning the browser interface?

A few days ago I wrote down some (very preliminary) ideas relating to liquid

1) Blog format doesn't work so well as a collaborative research tool (if this is the intention). In some way "bootstrapping" could occur to transition (as in any software development project) from description and ideas into the in some way finished project/software.

2) Exposed code as interface should be key. It doesn't make sense to tunnel down from an always already conditioned (static) interface into always dynamic code. The reverse process needs to take place.

3) Widgets, desktop - again operating in a one way street relation to code - (and mention of open source below). The desktop provides for an illusion of transparency - it is an horizon on which the real (the con trick of software which proposes its own license-wrapped existence) appears. That code defines and can redefine (cynical non-transparency) is the important part. The desktop is a limited field of action - action restraint (Mallarme). Examples of potential workflow include GNU Emacs and Planner mode - content and code are rewritten simultaneously with publication as a funneling markup (restriction) to HTML. Again the format/rendering of data is less important IN THIS RELATION - it could equally well be graphed pixels, a pie chart. What matters is that there is a reduction - we potentially leave code space but as in a conversation can re-enter at will - that is the active part.

Some questions that arose for me

All communication results in action otherwise no communication took place...
What actions will result from liquid?

How open is the system?
* why are you creating this project with this particular group of people?
* What can be gleaned of the power structures surrounding the project from this interrelationship? (interpersonal, organisational, economic and cultural) and how will this internal organisation affect the outcome of the project.
* where is the power to determine directions located.

How free is the system?
* What are the social, cultural, environmental, economic and political patterns that configure access to this project.

Galley context plane

The gallery itself can also be treated as a context plane. From a particular work, the gallery plane could be "foregrounded" and navigated and then allow the user to approach and view another work.

See the attached sketch.

Parallel context plane interaction - illustrated

The pdf shows the potential for a specific context plane to interact with the work, and for the viewer/user to interact with either as they wish.

Chris

Static online context plane and client dynamic planes - illustrations

An example of a static online context plane. The viewer of a work is able to breakaway and read related web-based material and then return to the work.

The second example is more dynamic but interactively is it still "interleaved", i.e. breaking wawy from the running work of art to exaine other information.

(Documented fully in the attached pdfs)

Context planes - ideas and types

Over the next few days, I hope to post some illustrations of differing context plane ideas. The ideas differ in terms of their likely interaction with works, in terms of their relevant server/network technology and in terms of their look and feel.

These will include a static online plane, a history plane, a dynamic parallel plane, as well as what I'd call a gallery plane. (These terms are labels/placeholders, and better labels are bound to exist!)

Please add to this with your own examples, but give a label so we can refer to them easily.

Thanks

Chris