Restructuring the relationship between breakdowns and strips, extending stripboard options

[ldeboer]

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 (luke@setheroapp.com)

[modemmute]

Thanks @ldeboer for this very detailed and thoughtful post! I agree with many points you made above, but would like to further some of your ideas with a few of my own.

Regarding the separation of concerns - I think you've hit the nail on the head with this point. Overall, this is an overarching problem in stripboards. The root of this issue is found in a brief digression into the history of scheduling.

History

In the past, assistant directors would purchase pre-made cardboard strips which came in a variety of colors - generally white, green, yellow and blue. The back faces of these strips were dark-grey or black. There were no dedicated strips for banners. Banners were generally just messages you wrote on the white strips. Day strips were just standard strips that you flipped upside down to show the black color. They contained no day or page count information.

So when it came time to create scheduling software, the original creators were faced with the quandary of how to replicate this very organic behavior in software. Overall, their solution was to classify strips into three different types - breakdown strips, banners and day breaks. There was seemingly little to no concern about a separation of concerns. They just wanted to get the functionality into the computer.

Now it comes to us to solve this seminal problem. What are banners - are they breakdowns or meta data? What are day strips - are they also breakdowns or are they simply dividers?

Proposal

I think there's a lot of elegance to your solution, but I'd add that I think you may only be half right. I agree that the separation of concerns is a root problem of the current proposal and you solution goes a long way to resolve that. But because the three types of strips weren't separated for the past 30 years, they have now grown some connective tissue.

It is now fairly common for scheduling software to allow banners to contain some breakdown information. Certainly duration is common, but also you can add elements in both Movie Magic Scheduling and Think Crew (others may support this as well). Because of this, I think it makes sense to include banners in the breakdowns array.

That said, day breaks do not commonly contain any breakdown information and only serve as a visual cue to communicate date and page count information.

Therefore I'd propose the following solution, which is based on your well thought out idea:

{
   ...
   breakdowns: [
      { "id": "603c49bb9d67b45889ade2a7", ..., "type": "banner" },
      { "id": "5d9fc8cfc0efae0017a32e31", ..., "type": "strip" },
      { "id": "5d9fc8cfc0efae0017a32de8", ..., "type": "banner" },
      { "id": "623c9a26aad4d876cc370bf0", ..., "type": "strip" },
      { "id": "5d9fc8d0c0efae0017a32e39", ..., "type": "strip" },
   ],
   stripboards: {
      ...
      "boards" : [
         { 
            ...
            "name": "Stripboard"
            "breakdownArray" : [
               [
                  "5d9fc8cfc0efae0017a32e31",
                  "5d9fc8cfc0efae0017a32de8"
                  "5d9fc8d0c0efae0017a32e39"
               ],
               [
                  "603c49bb9d67b45889ade2a7",
                  "623c9a26aad4d876cc370bf0"
               ]
            ]
         }
      ],
   }
}

The above example keeps the banners with the breakdowns, as the banners may need the ability to store some breakdown information. This keeps their concerns together.

The order of the breakdowns is set in the temporarily named breakdownArray array in the boards object. The breakdownArray array contains children arrays, each with an ordered list of ids for each shoot day. The shoot day number is inferred by the order of the children arrays.

const dayOneStrips = boardObject.breakdownArray[0]

This inference is important. Explicitly naming the days with their own key (ie "dayGroup": 2) could lead to issues if an exporter skipped a day number or listed day 4 before day 3. The numbers of the shoot day are inferred both in scheduling software and in production as well - whatever occurs after day 2, it's always day 3.

Additional Keys

The extensibility of the data is always important, but as the breakdown objects are ultimately the source of that data, I'd propose that any extended values be placed there. The schedule object should only really be concerned with the ordering and dates of the breakdown data and shouldn't add anything that could be considered content. My two cents.

Some thoughts on the additional proposed keys -

• bannerText - i think this may have real value in the breakdown object itself. Currently we're storing that value in the description, which is shared with the description of the scene. Giving the banner text its own home seems appropriate.

• notes - there's already a methodology for creating notes for a breakdown. You can add a notes element to a breakdown.

• startTime, and endTime keys could potentially offer real value, but I'd propose that they are included in the breakdown object itself, not in the board. Also, I don't know if any scheduling software that currently allows you to set the time of day of a particular breakdown item (but please correct me if I'm wrong). The duration of a scene is commonly denoted, but if any start or end times are reflected, they are inferred from the lengths of the preceding scenes. This point is worthy of further discussion though.

Could you open a separate issue where we could discuss the addition of these keys to the breakdown object. I like the ideas, but it's probably a separate discussion than this one.

Thank You

Thank you very much for this and all of your ideas. I had to take a few days to really come up with a thoughtful response to this because your idea was so strong - and ultimately foundational - to the proposed standard. I'm completely open to furthering this discussion or hearing more ideas, if you have them. Now's the time to resolve any structural issues with the standard.

[modemmute]

With no more comments on this topic, I'll be implementing my solution above and am closing the issue.