Chorus: Multi-Device Coordination for Data Visualizations
📊

Chorus: Multi-Device Coordination for Data Visualizations

Published
April 30, 2018
Tags
Projects
Author
Stephen Wu
📊
During my time as a Research Assistant for the Interactive Data Systems Group, I built a prototype library for seamless, real-time, multi-device data coordination of interactive JavaScript-based data visualizations called Chorus.
OK, that's a bit of a mouthful, so let's break that down!
What's an interactive JavaScript-based data visualization?
That's any visualization of data: dashboards, graphs, charts, maps, infographics, etc., that can be interacted with: zoomed, filtered, brushed, scaled, linked, and so on.
Some examples: NYTimes, D3.js.
For Chorus, this can be any front-end web application with a JavaScript data store.
What's real-time multi-device data coordination?
That's coordinating data between multiple devices: computers, tablets, or phones, so that the data is synchronized between them without significant latency.
What makes it a prototype?
In short, security and scaling. There are notable security and scaling issues, and transactional data concerns with this prototype.

Motivation

While working for Ohio State's Interactive Data Systems Group as a Research Assistant, I was exploring different data systems-related projects. My PI, Dr. Arnab Nandi, suggested I explore multi-screen visualizations, like a massive chandelier or forests of interactive information, where individual devices can affect each other. He suggested I check out socket.io, a WebSockets library, which later became a key library for Chorus.
Eventually, we pivoted to the idea of building a general library to help data visualizations become real-time data-coordinated apps.
Many JS-based web apps, whether in a classroom, research facility, or workplace, may be more effective with data sharing and collaboration. I decided to build Chorus to help enable these apps to easily become collaborative experiences.
This idea can be summed up in the tagline: "chat rooms for data."
Goal: Minimize the amount of time to turn a data visualization built in JavaScript to a multi-device, interconnected experience.

Model

To build a generic model for data sharing, we used the concept of "data rooms" with "Main" and "Auxiliary" Data Stores.
  • Any user can create a data room with a name of their choosing, or join an existing data room.
  • Within that room, there's one Main Data Store. Anyone in the Main Data Store will receive real-time updates from all other clients connected to the Main store in the room.
  • Clients can detach to Auxiliary Data Stores, where they can make their own local updates without getting real-time updates, and Return or Push to Main later.
  • Clients in Main can also Push to All detached clients, sending their updates to all clients in Auxiliary Data Stores.
This is the Chorus model. Each Chorus room can have multiple clients and multiple data stores, but only one Main Data Store. Clients can disconnect, make updates, and then go back to the Main Data Store when desired.
This is the Chorus model. Each Chorus room can have multiple clients and multiple data stores, but only one Main Data Store. Clients can disconnect, make updates, and then go back to the Main Data Store when desired.

User Interface

These are the three states of the Chorus UI: Disconnected, Connected/Main, and Connected/Detached.
These are the three states of the Chorus UI: Disconnected, Connected/Main, and Connected/Detached.

Results

I presented Chorus at the 2018 Denman Undergraduate Research Forum, building a couple of demos with other JS libraries like MIDI, Leaflet, Crossfilter, and React.
Chorus is available on GitHub under an MIT License.
Check out the poster below or my summer update presentation.
notion image