One of the most critical functions of this app is being able to manage a live jam, using the sets, songs, and slots on a given jam session.
Currently, it can be difficult to work out which sets are ready to perform, such as whether enough slots are filled to get at least a song or two performed, and which sets should be done in which order during the evening, according to how long a set is and who is checked in.
There is a prerequisite which will help the jam organisers manage their time. If the jam organisers know the length of a set (plus a few minutes setup/teardown time), they have an idea of how long a set will take.
First, extend the song table to include a song duration field, and a source field.
The song duration field will be used to determine roughly how long a song is, and will help calculate how long a full set is. Use a field type that allows easy addition without having to re-format, seconds would be my guess.
The source field can be a simple nullable text field.
If the user who created the set adds a song using our Deezer feature by explicitly selecting an artist and a song title from our provided drop downs, use the Deezer song information to save the song duration (in seconds) to the database, and update the "source" field to "deezer". This will help the jam organiser know whether the song's info has been pulled from deezer or another future source.
The live jam feature will consist of two parts: a management dashboard for the jam organiser, and a live dashboard for participants to see which sets are running and which sets are coming up.
These are the requirements for the management dashboard:
-
The dashboard should be completely dynamic, no page refreshes whatsoever. The dynamic update should be at a fast cadence, no longer than every 5 seconds.
-
The jam organisers will likely be using a phone or a tablet, so the UI must be clean and touch responsive.
-
The dashboard should show a clean list of sets for the current jam session, which users are assigned to what slots and songs, whether they are checked in.
-
The set's length is based on the sum of each song's duration, IF the song's source field is not empty. Additional time should be calculated if there are lots of assigned slots across different songs for different users. For example, a set with song slots assigned to the same users will take less time, because there will be nobody switching instruments or leaving/joining the stage. A set with song slots assigned to lots of different users will take more time, which should be factored into the time estimate.
-
The set's "health" should be calculated based on how many slots are taken in total. This should also update regularly as users check in.
-
The set's background and border style should correspond to the set's health. Red = no slots claimed, green = all slots claimed. Use a gradient between red and green depending on how many slots are taken on a set.
-
Each set has several possible states:
-
-
-
-
-
-
Each set should have clear buttons on the side of the set card, in ascending order: Bring Forward , Start, Finish, Postpone, Push Back.
-
- Start brings the selected set to the top of the list and gives it an animated "playing" or "running" icon, to indicate that this set is the one that's currently live or being set up. This button is hidden if the current state is "playing"
-
- Bring Forward brings the set further up in the list, indicating that it will be onstage sooner. this button is hidden if the current state is playing.
-
- Push Back pushes the set further down the list, indicating that it will be onstage later. this button is hidden if the current state is playing.
-
- Finish indicates the set has been fully completed. The set is marked as "finished" and is pushed to the bottom of the stack with a grey background and a green tick on the card. This button is hidden unless the state is "playing_now"
-
- Postpone indicates a set that likely won't be played, usually due to missing members making it impossible to play on this jam. The set will be set as "postponed" and given a grey style with a red X on the card. The only button visible shall be "Bring forward", which will recover the state of the set to "pending".
-
There are some display rules:
-
- The set that is "playing_now" is always at the top. Only one set can be "playing_now" at a time.
-
- The set just below the currently playing set is considered the "coming_up" set.
-
- The rest of the sets are displayed in the defined order, and are moved by either bringing forward or pushing back a set.
-
- All finished sets are at the very bottom, with all postponed sets just above.
To summarise the display order: playing now is at the top, coming up is below that, any other pending sets are in the order defined by the jam organiser. Postponed sets are near the bottom, finished sets are at the very bottom.
Once an order has been defined and appropriate statuses assigned to each set based on its position in the stack, an "Update" button will send the data updates to the backend, which will store them into a cache on the server, using the app's default cache provider.
All the set ordering and any other data related to the management dashboard should be saved to a cache because the data does not need to be persistent, because a jam is only ever on for one evening. Once the jam is over, the cache can be cleared.
The live dashboard should be a simple display, suitable for a larger screen, that shows the sets according to their status and order in the live session cache in the backend. It should update dynamically and regularly, and requires no user input.
One of the most critical functions of this app is being able to manage a live jam, using the sets, songs, and slots on a given jam session.
Currently, it can be difficult to work out which sets are ready to perform, such as whether enough slots are filled to get at least a song or two performed, and which sets should be done in which order during the evening, according to how long a set is and who is checked in.
There is a prerequisite which will help the jam organisers manage their time. If the jam organisers know the length of a set (plus a few minutes setup/teardown time), they have an idea of how long a set will take.
First, extend the song table to include a song duration field, and a source field.
The song duration field will be used to determine roughly how long a song is, and will help calculate how long a full set is. Use a field type that allows easy addition without having to re-format, seconds would be my guess.
The source field can be a simple nullable text field.
If the user who created the set adds a song using our Deezer feature by explicitly selecting an artist and a song title from our provided drop downs, use the Deezer song information to save the song duration (in seconds) to the database, and update the "source" field to "deezer". This will help the jam organiser know whether the song's info has been pulled from deezer or another future source.
The live jam feature will consist of two parts: a management dashboard for the jam organiser, and a live dashboard for participants to see which sets are running and which sets are coming up.
These are the requirements for the management dashboard:
The dashboard should be completely dynamic, no page refreshes whatsoever. The dynamic update should be at a fast cadence, no longer than every 5 seconds.
The jam organisers will likely be using a phone or a tablet, so the UI must be clean and touch responsive.
The dashboard should show a clean list of sets for the current jam session, which users are assigned to what slots and songs, whether they are checked in.
The set's length is based on the sum of each song's duration, IF the song's source field is not empty. Additional time should be calculated if there are lots of assigned slots across different songs for different users. For example, a set with song slots assigned to the same users will take less time, because there will be nobody switching instruments or leaving/joining the stage. A set with song slots assigned to lots of different users will take more time, which should be factored into the time estimate.
The set's "health" should be calculated based on how many slots are taken in total. This should also update regularly as users check in.
The set's background and border style should correspond to the set's health. Red = no slots claimed, green = all slots claimed. Use a gradient between red and green depending on how many slots are taken on a set.
Each set has several possible states:
Each set should have clear buttons on the side of the set card, in ascending order: Bring Forward , Start, Finish, Postpone, Push Back.
There are some display rules:
To summarise the display order: playing now is at the top, coming up is below that, any other pending sets are in the order defined by the jam organiser. Postponed sets are near the bottom, finished sets are at the very bottom.
Once an order has been defined and appropriate statuses assigned to each set based on its position in the stack, an "Update" button will send the data updates to the backend, which will store them into a cache on the server, using the app's default cache provider.
All the set ordering and any other data related to the management dashboard should be saved to a cache because the data does not need to be persistent, because a jam is only ever on for one evening. Once the jam is over, the cache can be cleared.
The live dashboard should be a simple display, suitable for a larger screen, that shows the sets according to their status and order in the live session cache in the backend. It should update dynamically and regularly, and requires no user input.