First off, Michael -- thank you so much for your work on this! It's so exciting to see it come together. I spent 3+ hours combing through all this and really analyzing it deeply. You've done a great job covering many different bases and documenting everything thoroughly.

This is by far the biggest feedback item I'd like to suggest. It is a little complex to explain, so thanks for hanging with me.

For context, I would like to note that I approach this from the perspective of working with call sheets and some of the detailed schedule data that is needed in those contexts that might exceed the detail found on a typical one-liner. Taking the approach I suggest below requires a slight shift away from the Movie Magic Scheduling approach to stripboards and focusing more on creating a structure that could accommodate either basic stripboard-like schedules or very complex on-the-ground call sheet schedules.

Also, it's very possible I'm missing something in this, so feel free to point out holes in my thought process.

The issue:

Currently, some schedule-related data is stored in the "breakdowns" object in the form of days and banners. These objects are then referenced when being tagged in a schedule.

This is not ideal for a few reasons:

• There is a lack of separation between scene breakdown data and scheduled related data. Ideally, I feel that there should be a hard separation between scene breakdown data and schedule data.
• The current approach results in a lot of unnecessary fields that are left null. For instance, if I have a schedule with 50 days, I will have 50 duplicate objects in the "breakdown" array that are essentially completely blank objects. Here is an example:

{
  "id": "6009aa7efac8810c058d304d",
  "type": "day",
  "scene": null,
  "description": null,
  "scriptPage": null,
  "pages": null,
  "time": null,
  "comments": null,
  "created": "2022-06-11T00:12:02.000Z",
  "elements": []
}

• Currently, breakdown items are placed in a stripboard simply by being listed in an array of IDs under the boards -> breakdownIDs field, as shown here:

{
  "id": "5cff4bcb10c4330017ab6da1",
  "name": "stripboard",
  "breakdownIds": [
    "5e2dd860fb4b2900171967fc",
    "5e2dd860fb4b2900171967fe",
    "5e2dd860fb4b290017196800",
    "5e2dd860fb4b290017196802" 
   ]
}

While this does the job of putting the elements in order, it is very limited in the ways it could be extended because there is no room for adding any metadata to an item on the schedule other than its order. This becomes a particular problem when working on schedules that might have specific notes that need to be added to items listed on the schedule or when working on a shoot where specific times or locations must be assigned to items on the schedule.

The proposed solution:

Remove the type field from the breakdown object. This would make all breakdown objects scenes by definition, since “days” and “banners” are functions of schedules, not of breakdowns.

Under the Stripboard -> boards array, the breakdownIds field should be renamed to stripElements (or something similar) and instead of being an array of string ids, should be extended into an array of objects. Please look over the following example:

{
  "id": "5cff4bcb10c4330017ab6da1",
  "name": "stripboard",
  "stripElements": [
     {
        "breakdownId" : "5e2dd860fb4b2900171967fc",
        "dayGroup" : 1,
        "bannerText" : null,
        "notes" : null,
        "startTime" : 09:00:00,
        "endTime" : 11:30:00
     },
     {
        "breakdownId" : "5e2dd860fb4b2900171967fe",
        "dayGroup" : 1,
        "bannerText" : null,
        "notes" : null,
        "startTime" : 11:30:00,
        "endTime" : 12:15:00
     },
     {
        "breakdownId" : null,
        "dayGroup" : 1,
        "bannerText" : "Lunch Break",
        "notes" : "MUST BOARD SHUTTLES: All cast and crew should take shuttles buses which will waiting near crew parking area for transport to the lunch location.",
        "startTime" : 12:15:00,
        "endTime" : 13:15:00,
        "_locationLatLong" : "47.45411460402577, -122.30092520253127",
        "_anotherCustomField" : "This allows custom data, such as exact location data, shot information, or even links to attachments such as parking maps to be added to any object on the schedule, including company move banners or scenes themselves."
     },
      {
        "breakdownId" : "5e2dd860fb4b2900171967fe",
        "dayGroup" : 1,
        "bannerText" : null,
        "notes" : null,
        "startTime" : 13:15:00,
        "endTime" : 18:15:00
     },
     {
        "breakdownId" : "5e2dd860fb4b290017196800",
        "dayGroup" : 2,
        "bannerText" : null,
        "notes" : null,
        "startTime" : null,
        "endTime" : null
     },
     {
        "breakdownId" : null,
        "dayGroup" : 2,
        "bannerText" : "This is just a banner",
        "notes" : null,
        "startTime" : null,
        "endTime" : null
     },
     {
        "breakdownId" : "5e2dd860fb4b290017196802",
        "dayGroup" : 2,
        "bannerText" : null,
        "notes" : "Due to COVID restrictions, only skeleton crew will be asked to stay for this pickup shot of scene 34. This is a comment on a scene object, allowing schedule-specific notes to be added to scenes within the schedule if needed.",
        "startTime" : null,
        "endTime" : null
     }
   ]
}

Here is a description of these fields:

  {
        "breakdownId" : string | this is the id of the scene breakdown that is being tagged | can be null,
        "dayGroup" : integer | this is used to group strips together into days. Any items with the same dayGroup number occur on the same day | required,
        "bannerText" : string | if this strip is a banner, the banner text should go here. If it is not a banner, this will be left null | can be null,
        "notes" : string | this optional field allows notes to be added to any item on the schedule. This typically would be used to add specific reminders or instructions that are directly pertinent to this scene or banner or company move | can be null,
        "startTime" : time (HH:mm:ss) | this optional field allows a start time to be specified to the schedule item. If no start time is needed, simply leave blank | can be null,
        "endTime" : time (HH:mm:ss) | this optional field allows an end time to be specified to the schedule item. If no end time is needed, simply leave blank | can be null
     }

Benefits of this approach

The key benefits of switching to this approach are as follows:

• Improved separation of concerns. The "breakdowns" object only contains scene breakdown information, not schedule banners and day items.

• The extensibility of the schedule is increased by allowing users to add more metadata to any item on the schedule. This includes the option to add both start and end times to schedule items (this is very important on certain shoots that may be working on strict and detailed time schedules) as well as adding schedule-specific comments to any stripboard item. Additionally, custom elements could be added using the underscore technique. For instance, if there was a company move to somewhere with a specific GPS coordinate, that could be added as a custom element called "_locationLatLong".

• Null data duplication is reduced The need to store duplicate, identical "day break" strips as their own breakdown items could be eliminated. By simply specifying a "dayGroup" field on the schedule items, it's easy to tell what items occur on the same day within the schedule and thus day break elements can easily be auto-generated between day groups when displayed schedules, etc. (note: this change is optional.)

Drawbacks of this approach

I'd love to hear if there are any drawbacks to this approach that others see. So far, I'm not seeing any big ones; however, there very well could be implications that I'm not seeing.

I hope this is helpful! As always, feedback and improvement to this suggestion are welcome.

Thanks for all the effort you've put into this, Michael!
Luke @ SetHero ([email protected])

I would propose renaming the time field on Breakdown object to duration. Duration is a more accurate description and using the name "time" could mislead people into thinking it is specifying the time of day (such as 12:30pm) rather than the duration.

{
  "id": string | UUID value | required,
  "comments": string | can be null,
  {....}
  "duration": number | millisecond duration to shoot scene | can be null,
   {....}
}

Luke @ SetHero ([email protected])

I have a question on this specific section of the documentation, which is found under the header Board Objects:

"The length of the combined arrays of the breakdownIds across all boards within a stripboard object must be equal to the total number of breakdown objects in breakdowns. For example, say you have two boards -- 'stripboard' which has 75 IDs and 'boneyard' which has 25 IDs -- you must have a total of 100 breakdown objects in your breakdowns array. Breakdown objects that are not referenced in a boards.breakdownIds array will be ignored."

I'm curious how this rule applies when having multiple stripboard versions. For instance, what if I had one board that was 1st unit, one board that was 2nd unit, add another board that was an alternate schedule version that I want to have saved as a backup. Between these three boards, it's very likely that some scenes would be listed on multiple strip boards. (For instance, my alternate schedule version might contain many of the same scenes as my first unit schedule, but in a slightly rearranged order.)

In such a case, the rule above which states that the total sum length of both arrays should be equal would not apply. I might be missing something in the way I'm interpreting this, but I wanted to double-check. Thanks!

Luke @ SetHero ([email protected])

Elements and Categories

In the mental model of the USS, Categories are a static list/taxonomy, and each Element belongs to exactly one Category.

Current Implementation

The current version of the USS models this relationship between by including an array of Element IDs inside the definition of the each Category.

{
  ...,
  elements: [{id: 'abc', ...}],
  categories: [{id: '123', elements: ['abc',...], ... }]
 }

Some of the drawbacks of this approach include

• The onus is on the developer to validate that every element is contained within exactly one category, which can be easily overlooked
• The act of changing the category of an element is a 2 step process: it must be removed from the old list and added to the new list
• It is slightly more work to see at a glance which category an element belongs to

Suggested Change

It could be beneficial to model this relationship in the following way:

• each Element has a required categoryId field
• remove the elements array from Category

{
  ...,
  elements: [{id: 'abc', categoryId: '123', ...}],
  categories: [{id: '123', ...}]
}

The same information is captured in this suggested model, but the rules of the relationship no longer require validation (each element belongs to exactly one category), and it is slightly easier to follow this relationship. The categories also become simpler, and look more like a static taxonomy which is in line with the mental model (and other models of taxonomies or "tags").

I hope this helps! Feedback on this suggestion is welcome, as well as additional context on how the current implementation came to be.

Thanks for all the work that you do!
Nick @ Cinapse ([email protected])

Adding "company" would allow several schedules belonging to the same company to be reported on.

The issue:

Currently, there is a field on the root universalScheduleStandard object named "version". To most people reading through this object (including myself), I think the version field would be interpreted as containing a version name or number for the production or breakdown data, rather than a place for indicating the current version of the USS standard being used.

Proposed Solution:

I would recommend one of the following solutions:

1. Rename the "version" field to ussVersion or formatVersion or something similar to this to make clear that it should not be used to store project or breakdown version data.

2. Move the "version" field outside of the universalScheduleStandard object and to the very top of the JSON object, such as this:

{
  "version" : "1.0.2" 
  "universalScheduleStandard": {
    "id": string | UUID value | required,
    "author": string | name of individual creator | can be null,
    "company": string | name of the company for which the schedule was created | can be null,
    [ .... ]
  }
}

Personally, I think I'm leaning toward option 2. But interested to hear what others think!

Thanks!
Luke @ SetHero ([email protected])