Restructuring the relationship between breakdowns and strips, extending stripboard options about universalschedulestandard HOT 2 CLOSED

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.

from universalschedulestandard.

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

from universalschedulestandard.