#direnduvar Case Study

“Wall of Resistance”



This Case Study is written for AWWWARDS, “The Best 365 Websites around the World — 2013”.

Synopsis

#direnduvar is a social media focused, expanding interactive art project with a visitor curated content. It is a surface of self-expression where visitors can leave their marks to share their message to the world. It is a wall of freedom that feeds (from) social networks.

The project is triggered for its birth by the extreme violence of the government in the latest events happening in Turkey, started with #direngezi (Gezi Park Resistance). It combines two turkish words to support its publicity purpose: “diren” (resist) and “duvar” (wall). During the peak days of the protests, the word “diren” has also become a local fad on social networks (for instance, #direncheesecake would be an appropriate tag for Instagram pictures depicting someone devouring the poor cake). Hence, we combined these two words, which almost translates into “wall of resistance” whilst retaining an ironic meaning in itself.

We’re aware that Turkey is only one of the many countries that are suffering because of their government. We want to increase public awareness with this project, with the help of people who view and share the content. This is why we think #direnduvar is a global project with a simple focus: freedom.

Everything aside, #direnduvar is a communication tool with a naive purpose: UX based storytelling.

Roots

The first idea behind #direnduvar was proposed for another project, XOYO; an infinite wall where the visitors could draw whatever they want, wherever they want. Although #direnduvar and XOYO are technical siblings, the purpose of #direnduvar made it clearly powerful compared to XOYO and all its simulants.

At the core of #direnduvar lies a remake of the real-time visual chat project Undream did earlier. “Chatbody” is an experimental project where visitors could become (mouse) pointers and chat around the browser page. During the remake process we’ve discovered a lot of potential of this real-time interaction which led the project to the very first version of XOYO, a real-time drawing space where visitors could draw at the same time, fully interacting with each other.

WIP Samples

At that stage, XOYO was a neat experiment for us which quickly became our interactive shared working space for online meetings and project development. Funnily, the rest of the project progressed with intense use of the tool itself; which also quickly became a core asset of our project management process.

While we were working on XOYO, #direngezi and media blockades happened in Turkey. We decided to create #direnduvar as a detached version of XOYO. We instantly made the necessary changes, only left the safe features and made it public.

#direnduvar got instant feedback starting from Twitter and Facebook and quickly became viral on Turkish social media.

“Time” as a Medium

One of the main features of #direnduvar is the way it stores and displays the entries. Every single entry on the wall is not only positioned in an infinite 2D map-like surface but also positioned in time. The result is a 2D looking 3D project which uses x, y and t dimensions.

“Time” as an addition to this project is what makes #direnduvar unique. Since every entry is also replayable, they become a tool for interactive narration of their creation process. This replayability feature also lets visitors to fully view every single entry, even if the entry is old and covered by other drawings on #direnduvar.

Replay in progress

The Main Shortcoming

Despite not being an overly complex application, most of our time went into maintaining the codebase. #direnduvar had underwent a number of wildly different iterations before reaching its final stage. To sum up, the application lies on top of an infrastructure with real-time communication primitives in mind, which is (obviously) unnecessarily complex for our final needs. This is the focal reason why we’re planning on revising #direnduvar: One-thirds of the codebase is not required anymore.

Nevertheless, we may break it down into a few core components:

Client-Side/Frontend General

The application itself was fated to be more custom-made than what we frequently see on the web. This lead us to using no frameworks at all. Obviously though, we used plenty of hand picked libraries. A number of jQuery plugins and event libraries are in place for ameliorating the mobile device experience.

The only thing UI-wise that’s left for the current frontend was to design a clean interface that supports the character and usage of the product. A MVVM-oriented framework or library (such as Angular or Knockout) will definitely be used in our newest revision as we had to deal with lots of UI elements that affect each other and the underlying data.

The Wall

Leaflet (a slightly modified version thereof — we had to hack away some of the outstanding bugs for our purposes) is the main library used to render the wall. Nothing extreme happens on the background: We have various PNG images created by our server application, which are grouped in terms of zoom levels. Although we haven’t exposed it to our users yet, it is also possible to request the PNG image of a single drawing as well.


V of #direnduvar


Drawing Canvas and Brushes

Although #direnduvar sports a single type of brush for the sake of simplicity, an elaborate scheme was needed for other brush tools (and once again, for complying with legacy code). Mainly, we were concerned in consistency of users’ drawings with relation to their representation on browsers and the application server. For instance, a custom bezier procedure had to be in place for this reason (although it hadn’t been used for #direnduvar).

Clients’ data model had to be in perfect sync with our servers. To do so, all of the brush movements (read: mouse and finger input) are stored for future submission. Also, our focus was to ensure that the rendering consumes as little processing power as possible, so we only have incremental updates on the rendering canvas.

Similar restrictions have led #direnduvar to have various limitations as a result of not being pre-planned due to the its roots in real-time communication (i.e. undoing a brushstroke is impossible at the moment).

Submission and Storage

Even though rendering images on the client side effectively leads to a immensely reduced workload from the servers’ viewpoint, we had to ensure that clients could not send anything that can’t be represented using our brush presets. Hence, as mentioned above, we only exchange brush movement data between the two.

A custom binary file format is used both for sending a drawing and storing the relevant replay data. This is actually inherited from our previous iterations when we had to send real-time drawing data and we didn’t need to use a standardized format (such as JSON) since the communication primitives are exclusive to our server infrastructure.

On average, the replay data takes only 20% of disk space of the PNG file representing the drawing itself. Not storing the image data and forcing clients to render the information is also possible, although it’s more or less established that rendering hundreds of drawings procedurally will singlehandedly destroy our users’ browsing experience.

Debugging the curves

Server-Side/Backend General

Due to previous iterations’ requisites (among which the most significant is WebSockets support), we needed additional software that we simply call “module”s alongside a regular HTTP server.

“Listener”s are in place to establish a socket connection. Then, we have “renderer” modules to which listeners may send a submitted drawing. As such, modules are implemented in terms of a distributed system since our main concern was being capable of scaling out. We’re planning on reducing the need for sockets in our new revision since two-way communication is rarely needed outside of drawing submissions.

Facebook and Twitter authentication takes place on the server side. This used to be a security measure for the previous real-time application, but it is now merely needed for identifying our users.

The main proponent of the language choice boiled down to a simple personal preference: The developer tends to steadily lose his sanity every time he has to code in Javascript.

Therefore, Haskell programming language had been chosen as the main server-side language. Snap Framework is used for handling HTTP requests, whilst renderer and listener modules were hand-rolled. All three modules use ZeroMQ for intercommunication. Our preferred database systems are Postgres (for persistent storage, mostly drawing metadata) and Redis (Facebook and Twitter credentials of our users). There wasn’t much benefit in using a database for storing the images and replay files themselves: They are simply stored on the disk. Cairo Graphics had let us porting the client renderer code with ease. Most of the remaining libraries, bindings and frameworks can be readily found through Hackage, the default library repository for Haskell.

Despite its various shortcomings, the programming model is a huge win in our opinion and Haskell will still be our preferred server-side language for the time being.