In this arti­cle we will shed a light on the forth­com­ing Down­Stage project. We sum­ma­rize as a com­pi­la­tion of ideas and thoughts, so regard it as work plan for fea­tures we want to have included. To keep track of the fea­tures, a split per­spec­tive from dif­fer­ent angles seems use­ful: Visions, Design and Pro­gram­ming. Each of the fol­low­ing sec­tions con­tains hints how to par­tic­i­pate, so you are invited to tell us your ideas and opinions.

Visions

A very impor­tant aspect is to gather a wish­list for fur­ther fea­tures and col­lect ideas by brain­storm­ing. Down­Stage is con­cep­tu­ally rooted in UpStage, an exist­ing plat­form for Cyber­for­mance. Down­Stage will include basi­cally all the fea­tures of UpStage, but also allow to real­ize things, which were cur­rently not pos­si­ble in UpStage. This includes a flex­i­ble way to han­dle media, for exam­ple to get text, images, video or audio files from dif­fer­ent sources (Face­book, Twit­ter, Flickr, YouTube, …). New fea­tures like audio– and videostream­ing will be natively sup­ported, also not restricted to a sin­gle source. Even more a con­cept of data stream­ing is included to allow to broad­cast dif­fer­ent pro­to­cols like OSC and MIDI, as also seri­al­ized for­mats like AMF or JSON. This will allow to inter­op­er­ate with many dif­fer­ent kinds of hard– and soft­ware: for exam­ple inter­fac­ing with new input devices like Microsofts Kinect or self­made Arduino cir­cuits, or inte­grat­ing exist­ing soft­ware and web resources. Extended func­tion­al­ity will also pre­pare the ground for new use cases, e.g. col­lab­o­ra­tive music-making or inte­grat­ing new forms of inter­ac­tiv­ity in your projects. This is yet not the whole pic­ture, just an appe­tizer, as there are for sure things we have not thought of yet and which may also be unfore­see­able in the future. So the idea of “change” and flex­i­bil­ity is also an impor­tant aspect and part of the over­all concept.

And let’s not talk too much about devel­op­ment details in this sec­tion. Mainly for the vision it is impor­tant to focus on new ideas and con­crete vis­i­ble fea­tures. A good way to par­tic­i­pate on this sec­tion 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 pre­con­di­tions). Next we see some ideas, which dif­fer from cur­rent pos­si­bil­i­ties in UpStage and will be real­ized with Down­Stage. Big thanks to Francesco Buon­aiuto for pro­vid­ing con­struc­tive ideas and nice images.

An exam­ple is the idea to open up the chat for com­mu­ni­ca­tions between par­tic­i­pants (pri­vate chat), between per­form­ers (pri­vate group chat) and to give the audi­ence more pos­si­bil­i­ties to par­tic­i­pate in an avatar chat. So an Avatar could pos­si­bly be fed by input from the audi­ence, instead of just allow­ing a player to use it (see image below).

Another idea is to cre­ate a net­work of con­nected stages, like this was pos­si­ble with rooms in MOOs or the Palace. Nav­i­gat­ing the stages could be done in a mod­er­ated way or also freely by every vis­i­tor (see image below). The basic idea is to give more free­dom to the per­form­ers to design and restrict the space them­selves. This also includes the pos­si­bil­ity to define a dif­fer­ent setup for each of the stages, for exam­ple to cus­tomize the stage and chat. For exam­ple “stage 1″ could be a fullscreen chat with­out a stage, “stage 2″ could be just a stage with­out chat, “stage 3″ could have more than one chat, “stage 4″ could have the pos­si­bil­ity for the audi­ence to con­trol the stage, and so on.

Do you also have a vision of how things should work? Do not hes­i­tate to give us more input for fur­ther fea­tures and use cases. You can tell us every­thing you want to see enabled on the new plat­form, and also every­thing you were not pleased with UpStage yet. You may also think of dif­fer­ent employ­ments, e.g. edu­ca­tion, col­lab­o­ra­tion and interaction.

On the Down­Stage project page (also called “Trac”), you have the pos­si­bil­ity to add your ideas in the wish­list. For this you just have to cre­ate a new ticket and assign the “wish­list” type (if not already selected). Reg­is­tra­tion for this is not nec­es­sary, but it will also allow you to cre­ate and edit wiki pages.

Design

Before the imple­men­ta­tion starts it is very use­ful to have some mockup designs which visu­al­ize how the user inter­faces will look like and how they will be used. Aspects in this sec­tion are of aes­thetic qual­i­ties, and do also take care of usabil­ity and acces­si­bil­ity. Some wire­frame designs are done quite fast and will enable to talk about fea­tures and func­tion­al­i­ties, but also allow to val­i­date log­i­cal and behav­ioural structures.

Essen­tially there is a need for both the client and server to incor­po­rate a user inter­faces, mainly meant to be used via web browser. Apart from the client and server user inter­faces, addi­tional ones might use­ful for the inte­gra­tion of hard­ware con­nec­tors, e.g. all kinds of sen­sors and con­trollers. The con­nec­tors will mostly be exe­cuted on a client machine, there­fore it is not absolutely nec­es­sary for it to have a web user inter­face. Any pro­gram­ming lan­guage offer­ing user inter­face capa­blilites might fit then, prefer­able a portable solu­tion able to run on dif­fer­ent plat­forms or oper­at­ing sys­tems is appreciated.

In the fol­low­ing mockup screen you can see an exam­ple wire­frame for a web fron­tend, which allows to select and join a stage on a world map. Screens like this are very use­ful to see how things may work (or not), although they are not com­pa­ra­ble to a final lay­out. For exam­ple you can already see there should be a search and a fil­ter func­tion, and you might also imme­di­ately know how to use it (if you have seen sim­i­lar maps like this). So an image can some­times tell more than a thousend words. Nev­er­the­less writ­ing addi­tional notes or com­ments will help to under­stand, although mak­ing intu­itive user inter­faces prob­a­bly should not need much explanation.

Besides a con­cep­tual scrib­ble, like the above wire­frame screen, there is also the need to cre­ate “real” screen lay­outs and prob­a­bly all kinds of graph­ics, like for skins or wid­gets. Very impor­tant are also designs for the stages, includ­ing icons, palettes, etc.

To par­tic­i­pate in this sec­tion you can pro­vide sketches and visu­al­iza­tions, either for the user inter­faces or any kind of visual ideas. There are a lot of tools avail­able, which allow eas­ily to gen­er­ate user inter­face mock­ups. The above screen was made with Wire­frameS­ketcher (a plu­gin for the Eclipse IDE), but there are also other tools, e.g. Bal­samiq, an online wire­frame tool. For advanced graph­i­cal designs there are edi­tors like Gimp, Blender, Inkscape or even online tools like Pixlr or X-Icon Edi­tor. And for the Flex client you can cre­ate an MXML design with Flash Builder.

Pro­gram­ming

At this point I will avoid the men­tion of agile devel­op­ment meth­ods, because these are often mis­un­der­stood in terms of “every­thing 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 cer­tain meth­ods, instead we pick best prac­tices of mod­ern soft­ware development.

From a devel­op­ers point of view, the foun­da­tion for a exten­si­ble and flex­i­ble solu­tion is to rely on open stan­dards and pro­to­cols, and also on best prac­tices and principles. Open Stan­dards, e.g. HTML, pro­vide a long-term com­pat­i­bil­ity and offer a solu­tion for tech­ni­cal dif­fi­cul­ties. A prac­ti­cal prin­ci­ple for exam­ple is to “not rein­vent the wheel”, a prin­ci­ple that in soft­ware design can be trans­formed to the par­a­digm of “Don’t Repeat Your­self” (DRY). Another prin­ci­ple is “Separation-of-Concerns” (SoC), which means that every com­po­nent should have  a sin­gle respon­si­bil­ity, com­po­nents should not mix their respon­si­bil­i­ties. For exam­ple, an imple­men­ta­tion fea­ture like pro­vid­ing data­base access should not be spread across the whole sys­tem into mul­ti­ple com­po­nents, instead it should be imple­mented just in a sin­gle com­po­nent, while affected com­po­nents should make use of that com­po­nent. This avoids imple­ment­ing the fea­tures mul­ti­ple times and main­tain­ing the fea­ture is much more sim­ple. This also is a huge ben­e­fit for avoid­ing and fix­ing  bugs. Another prin­ci­ple is “Sim­plic­ity”, mean­ing “if you have the choice of mak­ing some­thing com­pli­cated or sim­ple, just make it sim­ple”. An exam­ple for good prac­tice in soft­ware devel­op­ment is to do iter­a­tive devel­op­ment and to pro­vide incre­ments. Iter­a­tions estab­lish a work­flow of short-term-loops with sev­eral phases cov­er­ing analy­sis, design, imple­men­ta­tion, test­ing and releas­ing. Incre­ments pro­vide ben­e­fits for devel­op­ers and users, as this means for a devel­oper being able to release quick and highly auto­mat­i­cally. Each incre­ment is a build of the soft­ware with a incre­ment­ing minor ver­sion num­ber, so it is easy to iden­tify. There are for sure more best prac­tices and prin­ci­ples worth to con­sider, above ones seem very essen­tial to me and should be kept in mind dur­ing development.

Speak­ing of pro­gram­ming tasks, this is cur­rently the part where most work has to be done. The core of the server appli­ca­tion is writ­ten in Java and employs sev­eral tech­nolo­gies for devel­op­ment, like Spring, Maven, Jenk­ins and more. From an archi­tec­tural point of view the core is mainly com­posed after the Com­mand Query Respon­si­bil­ity Seg­ra­ga­tion pat­tern (CQRS) and relies there­fore on Axon­frame­work, a java-based frame­work for CQRS. Around the core the dif­fer­ent mod­ules are arranged and mostly are respon­si­ble for inter­fac­ing the core func­tions (com­mands and queries).

Com­mu­ni­ca­tion between a client and the Down­Stage server is done using the Exten­si­ble Mes­sag­ing and Pres­ence Pro­to­col (XMPP). XMPP in gen­eral is a open pro­to­col for sophis­ti­cated real­time com­mu­ni­ca­tion, pri­mary Instant Mes­sag­ing (IM). There are libraries for all major pro­gram­ming lan­guages and lots of servers avail­able. Besides send­ing and receiv­ing mes­sages, either text or other pay­load, XMPP han­dles pres­ence of its users (e.g. avail­able, away or not logged-in). The pro­to­col con­sists of RFCs and a col­lec­tion of var­i­ous exten­sions, which not all are imple­mented by all servers. Most impor­tant for Down­Stage are the broadly used exten­sions XEP-0045 (Multi-User Chat) and XEP-0114 (Jab­ber Com­po­nent Pro­to­col). The first allows to cre­ate and con­fig­ure chat rooms, the sec­ond allows to cre­ate server com­po­nents which pro­vide a con­nec­tion between the XMPP server and Down­Stage. For more infor­ma­tion the book “XMPP: The Defin­i­tive Guide” can be rec­om­mended, as it is IMHO one of the best books on this topic.

For dis­tri­b­u­tion and broad­cast­ing of media files, the server will use a REST­ful HTTP inter­face (also highly suit­able as pri­mary user inter­face and API to the server). In “Richard­son Matu­rity Model: steps toward the glory of REST” you will find a overview of prin­ci­pal ele­ments of a REST approach. For all kinds of streams an imple­men­ta­tion of the Publish-Subscribe pat­tern will be used (this is work­ing on a event based man­ner, like “don’t call us, we call you”). Both these approaches allow a high level of per­for­mance, exten­si­bil­ity, scal­a­bil­ity and inter­op­er­abil­ity due to sim­plic­ity, loose cou­pling and the ben­e­fit of being able to make eas­ily use of caching mech­a­nisms. Fur­ther­more client access by many dif­fer­ent hard­ware devices and all major pro­gram­ming lan­guages is sim­ple to imple­ment and handle.

On the client side there is no restric­tion on the usage of dif­fer­ent pro­gram­ming lan­guages, as long as they are able to incor­po­rate a library for XMPP com­mu­ni­ca­tion and prob­a­bly also do a lit­tle bit of HTTP, like GET and POST verbs.

At first, the goal is to have a client writ­ten with the free Flex open-source appli­ca­tion frame­work, espe­cially because cur­rently HTML5 seems cur­rently not mature enough for RIAs and even slower and more com­pli­cated than Flash. For mobile devices like smart­phones or tablets, the future is def­i­nitely HTML5, thus sooner or later a HTML5 client for Down­Stage will be cre­ated. Finally we keep the doors open, espe­cially due to the con­cep­tual archi­tec­ture, even allow­ing to inte­grate yet unknown clients of the future.

Addi­tion­ally on both client and server side, hard­ware and soft­ware con­nec­tors will allow to inte­grate dif­fer­ent kinds of data, both input and out­put. Typ­i­cally these will work like wrap­pers, trans­lat­ing low level API func­tions to com­mands and queries, or incor­po­rat­ing (open) stan­dards like OSC, AMF, MIDI, etc. (see above).

The pro­gram­ming part offers a lot of pos­si­bil­i­ties to par­tic­i­pate. Prob­a­bly the most advanced code will be in the server core. Build on top of the core, there will the other mod­ules, inter­fac­ing the exter­nal world (XMPP con­nec­tor, REST inter­face, stream­ing inter­face with Red5, etc.). On top of this there will be clients (Flex client, HTML client, etc.), using these exter­nal interfaces.

There is also the task to develop clients for con­trollers and sen­sors (like Kinect, MIDI con­trollers or Arduino), which in effect will push for­ward data to the server. A good thing to have will also be tools to test and debug the inter­faces, for exam­ple a com­man­d­line client for XMPP to debug the pro­to­col, com­mands and queries.

Feel free to get involved in pro­gram­ming — it really is not impor­tant if you are just a begin­ner or an advanced coder — there is plenty of pro­gram­ming to do and it cov­ers a full range of sim­ple to com­plex stuff.

Get in contact

It would be great, if you want to get involved and par­tic­i­pate in the project. We are open for lis­ten­ing to your opin­ions and ideas, and we are look­ing for­ward for every­one tak­ing care of one or more top­ics men­tioned above. The goal of Down­Stage is to have an open space, where peo­ple can get involved from the begin­ning. So here we are!

Right now I am at the res­i­dency of APO33 in Nantes, France until Feb­ru­ary 19th. If you are nearby there may be some inter­est­ing events com­ing up:

• 15th Feb­ru­ary: Hack­er­space @ APO33LAB, 2pm to 6pm, 17, Rue Bel­lamy, free entry
• 16th + 17th Feb­ru­ary: UpStage Work­shop, 2pm to 6pm, Plat­forme inter­mé­dia, 10 € for both days
• 19th Feb­ru­ary: UpStage Per­for­mance, 2pm to 6pm, Plat­forme inter­mé­dia, free entry

Dur­ing the work­shop there will also be the pos­si­bil­ity to par­tic­i­pate online:
open link for the online chat and video stream­ing
(will only work dur­ing the work­shop and performance)

And while I am in Nantes you can join us any­time in IRC chan­nel #apo33 (Freen­ode).

In case you nei­ther can join us dur­ing the work­shop or in the live online meet­ing dur­ing these events, you can any­time sub­scribe to the Down­Stage mail­inglists. We are look­ing for­ward hear­ing from you!