Selective Slide Inclusion Based on Presentation Format

[bsstahl]

Problem

Currently, creating presentations of different lengths or types requires maintaining multiple SlideDecks. This leads to significant duplication of slides across decks, making updates and maintenance error‑prone and time‑consuming.

Desired Outcome

Authors should be able to define a single SlideDeck that can be compiled into multiple presentation variants (e.g., ShortSession, Talk, Workshop, Keynote) without duplicating slide definitions. The selection of which slides appear should be determined at build time, based on the chosen LiquidVictor.Enumerations.Format value.

Requirements

• Single Source of Truth: All slides for a given presentation should live in one SlideDeck.
• Format‑Aware Compilation: The decision as to what presentation type is being built should be made a build time. Different presentation lengths or types can be generated from the same deck by changing only the format argument at build time.
• Default Behavior: Ideally, existing functionality should not be modified. Thus, a strong eye should be kept towards backward compatibility with existing decks.

Benefits

• Eliminates duplication of slide content across multiple decks.
• Simplifies maintenance and reduces the risk of inconsistencies.
• Provides flexibility to generate multiple presentation variants from a single source.
• Aligns with LiquidVictor’s philosophy of asset reuse and regeneration.

[bsstahl]

Superseded - See below

Implementation Recommendation: Deck-Level Exclusion Rules

Overview

Introduce a new ExclusionRules node at the SlideDeck level. This node defines, per Format (matching LiquidVictor.Enumerations.Format), which slides should be excluded when building a presentation in that format. This keeps the canonical slide list intact and centralizes format-specific differences in one place and replaces the Format property of the SlideDeck since the deck now represents all of the possible formats.

This feature is intended to be as backward-compatible as possible. If the ExclusionRules node is absent from a SlideDeck, or if the specified Format is not present within ExclusionRules, the build process will include all slides by default. Additionally, if no --format argument is provided at build time, the system will generate the full slide deck without applying any exclusions. This ensures that existing decks and workflows continue to function without modification. However, if a --format argument is provided and does not match any value in the LiquidVictor.Enumerations.Format enum, the CLI will throw a clear error to prevent unintended behavior.

---

YAML SlideDeck Example

Id: 9dbc6970-e816-41cf-8097-c783e2620eda
Title: Sample Slide Deck
ThemeName: dark
ExclusionRules:
  LightningTalk:
    - 4a824783-a10d-449e-9db6-238d9ff35f76  # Exclude Slide 2
    - c5e2e16b-0765-44cc-80a3-184c86bfc93a  # Exclude Slide 3
  ShortSession:
    - c5e2e16b-0765-44cc-80a3-184c86bfc93a  # Exclude Slide 3
SlideIds:
  - 4556dbcc-3386-4e44-b1e2-e664cc52a0a3  # Slide 1
  - 4a824783-a10d-449e-9db6-238d9ff35f76  # Slide 2
  - c5e2e16b-0765-44cc-80a3-184c86bfc93a  # Slide 3

[bsstahl]

Implementation Recommendation: Pivot to includes-Based SlideDeck Composition

Summary

This proposal replaces the previously recommended exclusionRules model with a simpler, more scalable approach: format-specific SlideDecks will use an includes node instead of a slides node. The includes list defines the ordered content for each deck, referencing reusable elements such as slide/{slideId}, group/{groupId}, and future types. This change enables modular composition while keeping each deck lean and format-specific.

---

Change from Previous Recommendation

The earlier recommendation introduced a centralized exclusionRules node to filter slides based on format. While effective for simple cases, it became limiting when:

• A single slide needed to appear in multiple places or formats with different sequencing.
• Slide reuse across formats required fine-grained control over placement.
• Filtering by ID excluded all instances of a slide, even when only one occurrence should be omitted.

These constraints led to complexity and maintenance risks, especially as decks evolved.

---

Why We Pivoted

By shifting to an includes-based model:

• We eliminate the need for filtering logic entirely.
• Each SlideDeck becomes a curated sequence of references, tailored to its format.
• Shared content lives in reusable SlideGroups, reducing duplication.
• Slide reuse and placement are fully controlled by the deck author.
• The system becomes easier to maintain, extend, and reason about.

This approach aligns with the existing pattern of maintaining separate decks per format, while introducing a clean mechanism for modular composition.

---

Examples

Id: d718d83c-3640-4c5e-84fe-f11f2c53451a
Title: Sample Slide Deck - Workshop
ThemeName: dark
Includes:
  - SlideGroups/fe7755d4-bed3-41d5-bf5d-a8e3a1a658c6
  - SlideGroups/2691b551-6296-4ed7-8d10-7dec466f0af7
  - Slides/4556dbcc-3386-4e44-b1e2-e664cc52a0a3
  - SlideGroups/407ed8dc-5c51-4393-b5e3-fb139746e506

Id: 3dce940b-c4a7-406b-afd4-4521e6052802
Title: Sample Slide Deck - LightningTalk
ThemeName: dark
Includes:
  - SlideGroups/fe7755d4-bed3-41d5-bf5d-a8e3a1a658c6
  - Slides/4556dbcc-3386-4e44-b1e2-e664cc52a0a3

[bsstahl]

This pattern also dovetails well with issue #23