In this article we will shed a light on the forthcoming DownStage project. We summarize as a compilation of ideas and thoughts, so regard it as work plan for features we want to have included. To keep track of the features, a split perspective from different angles seems useful: Visions, Design and Programming. Each of the following sections contains hints how to participate, so you are invited to tell us your ideas and opinions.
A very important aspect is to gather a wishlist for further features and collect ideas by brainstorming. DownStage is conceptually rooted in UpStage, an existing platform for Cyberformance. DownStage will include basically all the features of UpStage, but also allow to realize things, which were currently not possible in UpStage. This includes a flexible way to handle media, for example to get text, images, video or audio files from different sources (Facebook, Twitter, Flickr, YouTube, …). New features like audio– and videostreaming will be natively supported, also not restricted to a single source. Even more a concept of data streaming is included to allow to broadcast different protocols like OSC and MIDI, as also serialized formats like AMF or JSON. This will allow to interoperate with many different kinds of hard– and software: for example interfacing with new input devices like Microsofts Kinect or selfmade Arduino circuits, or integrating existing software and web resources. Extended functionality will also prepare the ground for new use cases, e.g. collaborative music-making or integrating new forms of interactivity in your projects. This is yet not the whole picture, just an appetizer, as there are for sure things we have not thought of yet and which may also be unforeseeable in the future. So the idea of “change” and flexibility is also an important aspect and part of the overall concept.
And let’s not talk too much about development details in this section. Mainly for the vision it is important to focus on new ideas and concrete visible features. A good way to participate on this section is to think of use cases, which expose details or give an idea about who will do what, and what is the expected result (maybe also with preconditions). Next we see some ideas, which differ from current possibilities in UpStage and will be realized with DownStage. Big thanks to Francesco Buonaiuto for providing constructive ideas and nice images.
An example is the idea to open up the chat for communications between participants (private chat), between performers (private group chat) and to give the audience more possibilities to participate in an avatar chat. So an Avatar could possibly be fed by input from the audience, instead of just allowing a player to use it (see image below).
Another idea is to create a network of connected stages, like this was possible with rooms in MOOs or the Palace. Navigating the stages could be done in a moderated way or also freely by every visitor (see image below). The basic idea is to give more freedom to the performers to design and restrict the space themselves. This also includes the possibility to define a different setup for each of the stages, for example to customize the stage and chat. For example “stage 1″ could be a fullscreen chat without a stage, “stage 2″ could be just a stage without chat, “stage 3″ could have more than one chat, “stage 4″ could have the possibility for the audience to control the stage, and so on.
Do you also have a vision of how things should work? Do not hesitate to give us more input for further features and use cases. You can tell us everything you want to see enabled on the new platform, and also everything you were not pleased with UpStage yet. You may also think of different employments, e.g. education, collaboration and interaction.
On the DownStage project page (also called “Trac”), you have the possibility to add your ideas in the wishlist. For this you just have to create a new ticket and assign the “wishlist” type (if not already selected). Registration for this is not necessary, but it will also allow you to create and edit wiki pages.
Before the implementation starts it is very useful to have some mockup designs which visualize how the user interfaces will look like and how they will be used. Aspects in this section are of aesthetic qualities, and do also take care of usability and accessibility. Some wireframe designs are done quite fast and will enable to talk about features and functionalities, but also allow to validate logical and behavioural structures.
Essentially there is a need for both the client and server to incorporate a user interfaces, mainly meant to be used via web browser. Apart from the client and server user interfaces, additional ones might useful for the integration of hardware connectors, e.g. all kinds of sensors and controllers. The connectors will mostly be executed on a client machine, therefore it is not absolutely necessary for it to have a web user interface. Any programming language offering user interface capablilites might fit then, preferable a portable solution able to run on different platforms or operating systems is appreciated.
In the following mockup screen you can see an example wireframe for a web frontend, which allows to select and join a stage on a world map. Screens like this are very useful to see how things may work (or not), although they are not comparable to a final layout. For example you can already see there should be a search and a filter function, and you might also immediately know how to use it (if you have seen similar maps like this). So an image can sometimes tell more than a thousend words. Nevertheless writing additional notes or comments will help to understand, although making intuitive user interfaces probably should not need much explanation.
Besides a conceptual scribble, like the above wireframe screen, there is also the need to create “real” screen layouts and probably all kinds of graphics, like for skins or widgets. Very important are also designs for the stages, including icons, palettes, etc.
To participate in this section you can provide sketches and visualizations, either for the user interfaces or any kind of visual ideas. There are a lot of tools available, which allow easily to generate user interface mockups. The above screen was made with WireframeSketcher (a plugin for the Eclipse IDE), but there are also other tools, e.g. Balsamiq, an online wireframe tool. For advanced graphical designs there are editors like Gimp, Blender, Inkscape or even online tools like Pixlr or X-Icon Editor. And for the Flex client you can create an MXML design with Flash Builder.
At this point I will avoid the mention of agile development methods, because these are often misunderstood in terms of “everything should be or is agile”, while in fact it is not. Sure, we want to be agile too (who doesn’t?), but we will not restrict to certain methods, instead we pick best practices of modern software development.
From a developers point of view, the foundation for a extensible and flexible solution is to rely on open standards and protocols, and also on best practices and principles. Open Standards, e.g. HTML, provide a long-term compatibility and offer a solution for technical difficulties. A practical principle for example is to “not reinvent the wheel”, a principle that in software design can be transformed to the paradigm of “Don’t Repeat Yourself” (DRY). Another principle is “Separation-of-Concerns” (SoC), which means that every component should have a single responsibility, components should not mix their responsibilities. For example, an implementation feature like providing database access should not be spread across the whole system into multiple components, instead it should be implemented just in a single component, while affected components should make use of that component. This avoids implementing the features multiple times and maintaining the feature is much more simple. This also is a huge benefit for avoiding and fixing bugs. Another principle is “Simplicity”, meaning “if you have the choice of making something complicated or simple, just make it simple”. An example for good practice in software development is to do iterative development and to provide increments. Iterations establish a workflow of short-term-loops with several phases covering analysis, design, implementation, testing and releasing. Increments provide benefits for developers and users, as this means for a developer being able to release quick and highly automatically. Each increment is a build of the software with a incrementing minor version number, so it is easy to identify. There are for sure more best practices and principles worth to consider, above ones seem very essential to me and should be kept in mind during development.
Speaking of programming tasks, this is currently the part where most work has to be done. The core of the server application is written in Java and employs several technologies for development, like Spring, Maven, Jenkins and more. From an architectural point of view the core is mainly composed after the Command Query Responsibility Segragation pattern (CQRS) and relies therefore on Axonframework, a java-based framework for CQRS. Around the core the different modules are arranged and mostly are responsible for interfacing the core functions (commands and queries).
Communication between a client and the DownStage server is done using the Extensible Messaging and Presence Protocol (XMPP). XMPP in general is a open protocol for sophisticated realtime communication, primary Instant Messaging (IM). There are libraries for all major programming languages and lots of servers available. Besides sending and receiving messages, either text or other payload, XMPP handles presence of its users (e.g. available, away or not logged-in). The protocol consists of RFCs and a collection of various extensions, which not all are implemented by all servers. Most important for DownStage are the broadly used extensions XEP-0045 (Multi-User Chat) and XEP-0114 (Jabber Component Protocol). The first allows to create and configure chat rooms, the second allows to create server components which provide a connection between the XMPP server and DownStage. For more information the book “XMPP: The Definitive Guide” can be recommended, as it is IMHO one of the best books on this topic.
For distribution and broadcasting of media files, the server will use a RESTful HTTP interface (also highly suitable as primary user interface and API to the server). In “Richardson Maturity Model: steps toward the glory of REST” you will find a overview of principal elements of a REST approach. For all kinds of streams an implementation of the Publish-Subscribe pattern will be used (this is working on a event based manner, like “don’t call us, we call you”). Both these approaches allow a high level of performance, extensibility, scalability and interoperability due to simplicity, loose coupling and the benefit of being able to make easily use of caching mechanisms. Furthermore client access by many different hardware devices and all major programming languages is simple to implement and handle.
On the client side there is no restriction on the usage of different programming languages, as long as they are able to incorporate a library for XMPP communication and probably also do a little bit of HTTP, like GET and POST verbs.
At first, the goal is to have a client written with the free Flex open-source application framework, especially because currently HTML5 seems currently not mature enough for RIAs and even slower and more complicated than Flash. For mobile devices like smartphones or tablets, the future is definitely HTML5, thus sooner or later a HTML5 client for DownStage will be created. Finally we keep the doors open, especially due to the conceptual architecture, even allowing to integrate yet unknown clients of the future.
Additionally on both client and server side, hardware and software connectors will allow to integrate different kinds of data, both input and output. Typically these will work like wrappers, translating low level API functions to commands and queries, or incorporating (open) standards like OSC, AMF, MIDI, etc. (see above).
The programming part offers a lot of possibilities to participate. Probably the most advanced code will be in the server core. Build on top of the core, there will the other modules, interfacing the external world (XMPP connector, REST interface, streaming interface with Red5, etc.). On top of this there will be clients (Flex client, HTML client, etc.), using these external interfaces.
There is also the task to develop clients for controllers and sensors (like Kinect, MIDI controllers or Arduino), which in effect will push forward data to the server. A good thing to have will also be tools to test and debug the interfaces, for example a commandline client for XMPP to debug the protocol, commands and queries.
Feel free to get involved in programming — it really is not important if you are just a beginner or an advanced coder — there is plenty of programming to do and it covers a full range of simple to complex stuff.
Get in contact
It would be great, if you want to get involved and participate in the project. We are open for listening to your opinions and ideas, and we are looking forward for everyone taking care of one or more topics mentioned above. The goal of DownStage is to have an open space, where people can get involved from the beginning. So here we are!
Right now I am at the residency of APO33 in Nantes, France until February 19th. If you are nearby there may be some interesting events coming up:
- 15th February: Hackerspace @ APO33LAB, 2pm to 6pm, 17, Rue Bellamy, free entry
- 16th + 17th February: UpStage Workshop, 2pm to 6pm, Platforme intermédia, 10 € for both days
- 19th February: UpStage Performance, 2pm to 6pm, Platforme intermédia, free entry
During the workshop there will also be the possibility to participate online:
open link for the online chat and video streaming
(will only work during the workshop and performance)
And while I am in Nantes you can join us anytime in IRC channel #apo33 (Freenode).
In case you neither can join us during the workshop or in the live online meeting during these events, you can anytime subscribe to the DownStage mailinglists. We are looking forward hearing from you!