Skip to main content

Dance - Documentation

Project Description

Dance at its core is a lighting and engagement framework with two APIs (or two endpoints), one to enable third party developers to build apps for any entertainment and engagement occasion, venue or other client and the other to allow third party developers to create apps where lighting designers can create and manage the lighting for an event. To enhance the features, events and possibilities of app variations, variety and to earn more money we will also include some third party functions into our APIs. The two APIs (or endpoints) will be Designer API and Dance API. Individually known as Product(s). The two Products combined, known internally as the Dance.

The Primary use case for Dance is to create beautiful lighting at events, shows and concerts using the audiences’ phones. Dance can also be used for a variety of other use cases where engagement is the goal (e.g. sending interactive notifications, crowd control and more)
The Designer API allows third party developers to create applications for controlling and creating the experiences on the third party app connected to the Dance API. (e.g. the Calm Studio that allows lighting designers and technicians (for concerts, shows, etc.) to control the screens of any connected device/app using the Dance API.) Dance will also have an api to facilitate the integration with third party lighting systems and a Designer on any of the Designer API third party apps can pre-plan and create lighting Chases to be played at a show (using the Dance API) 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.

Designer API: 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 API will allow a third party to interact with the lighting system or any other engagement that will be under control by the Designer API. 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 Designer API. The app should monitor battery level to avoid killing someone’s phone for the rest of the evening.

Definitions

Dance - refers to the project as a whole, that includes both the Designer API and Dance API.
Designer API - refers to the application used by lighting designers (“Designer”).
Dance API - refers to the consumer app that is used by concert goers.
Product - refers to the end result and what will be released, in this case Dance and Designer API are our ‘products’.
Designer - the lighting designer is the user of the Designer API that creates the shows and chases in the planning phase of the show.
Technician - the person who is at the show controlling the lighting.
Third Party - is a software or other entity that is not part of the Dance software, team, Calm Experts or Big Production.
Scene - is the practice of placing a drive of lights and colors together (e.g. yellow green red or right left).
Chase - is the practice of placing multiple scenes together (e.g. scene 1, 2, 4, 3, 2, 4, etc.).
Set - is the practice of placing scenes and chases along with a song timing or by the note of the song.
Jira - is a software for project management we use to organize tasks.
User Interface - is the process of building interfaces in applications, focusing on looks or style.
User Experience - is the process of creating products that provide meaningful and relevant experiences to users.

Products

Calm Studio -

Purpose of Documentation

The purpose of this document, the 01 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 Designer API and the Dance API, 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 / Calm Layout API. Once that is complete we will take an additional two week to add colors. Following we will take a pause from Designer API to focus on Dance API 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. This may change as issues arise, we will provide an update should that occur.

Phase One​

Estimated Start date: Feb 15, 2021
Estimated delivery date: Mar 5, 2021

Designer API​

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 API for some time. This will simply act as a pixel that displays the color selected in the Designer API Studio. Once we know we are reviewing the colors correctly we will focus on completing the Designer API and continue Dance after.

Phase Two​

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

Designer API​

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.

Phase Three​

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

Designer API​

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

Phase Four​

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

Designer API​

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

Dance​

The Dance API will have the last integrations needed.

Phase Five​

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

Phase Six​

Estimated Start date: Sep 23, 2021
Estimated delivery date: Sep 23, 2021

Designer API​

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

For more details about all the features we mentioned, check out the Designer API - User Documentation and 04 Dance API - 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 Designer API 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 Designer API, they are 04 Dance API - Documentation and 03 Designer API - 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: 04 Dance API - Documentation and 03 Designer API - Documentation. To understand the Development process, see 02 Dance Project - Development Documentation.