Skip to main content

Dance API - Documentation

Project Description

The Dance API is the beating heart of the Dance Project and all its functionalities and extended apps and projects. It’s purpose is to gain control of an audience’s devices and create beautiful lighting, interactive activities and any other functionality that can be based on this technology.
The API will need two sides to it or rather “endpoints” one for the consumer and another for the Studio to create the end user experiences. Each end will require an access key so we have full control over who can use the API.
The Dance API allows lighting designers and technicians (for concerts, shows, etc.) to control the screens of any connected device. It can integrate with third party lighting systems and the Designer can pre-plan and create lighting Chases to be played at a show in conjunction with a song. With the right integrations it can also auto adjust to the sounds being provided to the system through mics or third party integration. Note: this is a prototype and we may only be working on parts of the described features.

The projects that will be using the Dance API are…
Studio - designers create interactive experiences
Dance - end users enjoy, shop, and more

Studio: is an app where users can sign up in order to create lighting effects for shows and tours. There will be two main features: Library and Studio.

In the Library, a user can create folders which can hold any file type and is not associated with a tour or show; it can however be linked or moved into a show or tour. The user can also create a tour, which will hold shows, chases and/or scenes. Each show will store information about where and when it is going to take place (what arena and what date) as well as the list of songs that will be played (a song will be considered as a sound track and a chase or a sequence of chases). A chase will be made by joining different scenes together in sequence, while a scene will encompass a list of coordinate-color pair values and the time duration.

In the Studio, the user can access arena information/layout (previously built from an API/SDK) or can create a custom one in order to design tours, shows, chases and scenes. He or she can upload a sound track and can record the animations in which every seat will behave (this is the creation of a scene and/or chase).

When it is showtime, the technician can enter the Studio’s Live Mode. This is where the pre-built show data has to be triggered and played with the singer/band. Based on the location and date, an existing show should automatically be loaded but changes can still be done. There will be an option for switching to manual that will allow the user to change lighting manually and live. Also, the user can switch between the audience and the stage or display both side by side.

Dance: is an app where concert/show goers can interact with the lighting system that will be under control by the Dance Console. The app will confirm that this user is indeed in the arena based on his location. The solution our company is building for creating custom arenas is in beta phase, as soon as we get the coordinates precisely we will be able to use the location provided by the user’s GPS to display a range of seat options. The user will select his/her seat; otherwise, we can ask for his/her seating information without showing the closest seats. The screen should change its color based on data being received from Dance Console. The app should monitor battery level to avoid killing someone’s phone for the rest of the evening.

Purpose of Documentation

The purpose of this document, the Dance Project Documentation, is to establish the scope, means of development, features, definitions, acronyms and all else that is needed to accomplish the development of a prototype project. This document is intended for developers, UI and graphic designers, investors, marketers and any individual or company participating in the creation of this project. This procurement is not intended to be shared with other customers, users or any outside entity.

Scope

This document will cover the users, use cases, means of development and more. What is not included in this document is all and any text needed for the app itself (that should be created by a marketing team once the app is completed), images, graphics or any materials that are not reliant on a developer. The “Documentation” is not just this document but all the documentation attached in link format, in order to get a full understanding of the Dance Console and Dance, one should follow each link to fully grasp each idea and goal.

Accompanied Documents

Processes

Plans​

The process of development will be as follows. We will dedicate two weeks to integrating with the floor mapping / layout API. Once that is complete we will take an additional two week to add colors. Following we will take a pause from Dance Console to focus on Dance and return to add additional features such as Scenes and Chase should time and budget allow.

Estimates​

The estimates are the same as the ones from the proposal you’ve received, we will keep reporting the progress and updates on this every week.

Development Roadmap​

We have outlined the roadmap we are taking to complete the Dance Project. This may change as issues arise, we will provide an update should that occur.

0.01 release​

Estimated Start date: February 15th, 2021
Estimated delivery date: March 5th, 2021

Dance Console​

In this release we will focus only on the skeleton or “core,” all the components needed to support the features to come.
It may not look pretty yet but the functionality will be there, therefore we can test if user data is being rendered properly.

Dance​

Pixel: this is the only work we will do in the dance app for some time. This will simply act as a pixel that displays the color selected in the Dance Console Studio. Once we know we are reviewing the colors correctly we will focus on completing the Dance Console and continue Dance after.

0.02 release​

Estimated Start date: March 8th, 2021
Estimated delivery date: March 19th, 2021

Dance Console​

Most of the Studio will not yet be developed but the live feature will be working. This will allow us to test if the colors are being displayed well.

0.03 release​

Estimated Start date: March 22nd, 2021
Estimated delivery date: April 1st, 2021

Dance Console​

The Designer will have the ability to control the colors live using the Studio.

0.04 release​

Estimated Start date: April 6th, 2021
Estimated delivery date: April 23rd, 2021

Dance Console​

This release will have the scenes and chases implemented as well as library will be available to the designer.

Dance​

The Dance app will have the last integrations needed.

0.05 release​

This will be the first release that will be moved out of internal and onto private, we will setup a release channel and provide access to the client and any third party that the client grants written permission. See the testing process for details on how we proceed from here.
Estimated delivery date: April 27th, 2021

For more details about all the features we mentioned, check out the Dance Console - User Documentation and Dance - User Documentation.

Reports and metrics​

We will continue reporting the project status every Friday, this way we can show you and also measure all the progress in comparison to our roadmap.

Working Paper​

These documents exist to keep track of all engineers’ ideas and thoughts during project implementation. We are going to use Jira to add tasks related to any thoughts on how to solve technical issues and to each task there will be a place where the engineers can add their solutions. While it shouldn’t be the major source of information, these documents will help us to retrieve highly specific project details if needed.

Standers​

All coding standards are listed in Development Documentation, but to summarize we will use the best development practices such as Clean Code and Clean Architecture to ensure that any developer who reads the code understands what it does and also to ensure that the code is well-structured and testable.
For User Interface and User Experience our strategy is to follow the UI guidelines of the platform we are currently working on (iOS, Android or web). This will allow us to spend less time on User Interface and User Experience as well as make use of some components like authentication, navigation, billing and more that we made for all projects. Another benefit of following these guidelines is that we can integrate with other applications being developed on the platform allowing us to add features and capabilities later on. Publishing the Dance Console on the platform is free however there may still be transaction fees and other fees depending on the platform or third party integrations.

Research

We have done extensive research, primarily technological, and we strongly suggest additional market, business and user research take place once the prototype is complete. We have outlined only the conclusions in a condensed format in this document.

User Documentation

The design we planned is mostly related to the functionality and the User Interface will be simplified because it’s meant to be a prototype. There are two User Documents, one for Dance and another for Dance Console, they are Dance - User Documentation and Dance Console - User Documentation, respectively.

Development

The development details have also been excluded from this document for the purpose of greater elaboration into technical details that may not be necessary for all involved and is specifically meant for technical personnel such as UI/UX designers, developers and the project manager.

This concludes the first part of the Document. To fully understand the work that has gone into creating this document see Dance Project - Research. To have greater insight into a particular Product, see the product’s User Documentation: Dance - User Documentation and Dance Console - User Documentation. To understand the Development process, see Development Documentation.

​

​

Studio - User Documentation

Definitions

Grey - The documentation is meant to be focused on the immediate development (the prototype) however in order to keep the documentation for future development consistent we will include any information in this document in a grey color.
User Interface - is the process of building interfaces in an application or computer program, focusing on looks or style.
User Experience - is the process of creating products that provide meaningful and relevant experiences to users.

User Story

The “User Story” is meant to give a first person interactive point of view of the full project, every feature and every use case/scenario. We have not completed this process and plan to leave it for the MVP.

Data

The data structure and all data information can be found in the Dance API Documentation.

​

​

​

Dance Console​

As for the floor plan, we have a technology called Calm Layouts we built and we will try to apply it here (the solution that allows the Designer to build custom arenas). We will use Calm Layouts to create custom sections besides the default (physical) ones, so the designer can set sections and then create patterns by selecting a section. Before that, the Designer should select a color and place it on a track (load a song side by side).
We will have a list of sections organized by arena, location or a subcollection of the arena; we will also link it to the user.
We will match the user’s input data to a section’s location data to determine which phones turn which color. (E.g. all devices at section “A” turn red for 3.5 seconds and after that turn blue for one second and then red for one second in a sequence). We plan to make these data transfers extremely small otherwise it would cost a lot.
For the ticketing, we’ve done extensive research and we discovered that the data is not easy to access from ticketing websites, so we have decided to build something that we can use across many projects as well as yours. This will be an additional saving as we are developing it for our own use as well.
In dance console, the user is going to be able to register tracks which are going to synchronize the clients' phones with certain colors according to the music moment. In those tracks there will be scenes and chases, which will be able to be saved in pre-sets.
A chase is a composition of colors which are going to be displayed by the client (Dance). Those colors are going to happen in a pre-defined sequence, each color during a certain amount of time, until there are no more colors in that sequence. A user can specify the amount of times that chase is going to be repeated in sequence, as well.
A scene is a composition of many color periods or chase periods. Basically, a track consists of many scenes, which might be composed of many chases.
During a live concert, a user can schematize a sequence of tracks and when they are going to be played and synchronized in a way that if the user starts playing a session, the tracks are going to be played at specific times after the start of the sessions' playing. Those sessions are the queues. A user can also save a list of queues to be played live. The queues should be chached to the phone, in order to unallow stutterings during a live session.