Problem statement
Creating blueprints requires YAML knowledge and has no UI support, making it inaccessible to users who build automations entirely in the visual editor. Additionally, optional inputs require unsupported workarounds (e.g. input_boolean.none, empty arrays), resulting in fragile blueprints. This limits who can contribute blueprints and reduces their quality across the ecosystem.
Lowering this barrier supports OHF's approachability goal by enabling more users to create and share reusable automations. It also supports the community contributor experience goal by expanding the pool of people who can meaningfully contribute to the blueprint ecosystem.
This is a first step. The way users discover and consume blueprints isn't great either, but we believe solving the creation experience is the right place to start.
Community signals
- Optional input workarounds are widespread in community blueprints and flagged as a consistent pain point
- Blueprint authoring is done almost exclusively in YAML today, making it inherently less approachable (thus conflicting with our goals)
- Users/contributors (we see you @jpitlor) have tried to take on this daunting task by themselves in long-running pull requests (like this one) that for various reasons were closed
- This feature request, asking for the ability to conditionally display blueprint inputs
Scope & Boundaries
In scope
- A UI for creating and editing blueprints (mapping from a regular automation to a blueprint with exposed inputs)
- Native support for optional entity/selector inputs in the blueprint schema
Not in scope
- Blueprint discovery or sharing
- Blueprint consumption UI
Foreseen solution
A blueprint editor that lets users define input types, defaults, and whether they're optional (with optional inputs handled properly in the schema rather than via workarounds). Alternatively (or both), an "Export as blueprint" flow in the automation editor that guides the user in choosing which values to expose as inputs.
Risks & open questions
- How do we handle blueprints that reference advanced features not expressible in the visual editor? Should we add support for these features?
Appetite
2 cycles. Core schema changes, frontend editor work, and documentation updates. Currently unsure about where the technical complexity lies, but the cross-coordination across teams has proven time-consuming, so we need to take ample time to get this right.
Execution issues
No response
Decision log
Problem statement
Creating blueprints requires YAML knowledge and has no UI support, making it inaccessible to users who build automations entirely in the visual editor. Additionally, optional inputs require unsupported workarounds (e.g.
input_boolean.none, empty arrays), resulting in fragile blueprints. This limits who can contribute blueprints and reduces their quality across the ecosystem.Lowering this barrier supports OHF's approachability goal by enabling more users to create and share reusable automations. It also supports the community contributor experience goal by expanding the pool of people who can meaningfully contribute to the blueprint ecosystem.
This is a first step. The way users discover and consume blueprints isn't great either, but we believe solving the creation experience is the right place to start.
Community signals
Scope & Boundaries
In scope
Not in scope
Foreseen solution
A blueprint editor that lets users define input types, defaults, and whether they're optional (with optional inputs handled properly in the schema rather than via workarounds). Alternatively (or both), an "Export as blueprint" flow in the automation editor that guides the user in choosing which values to expose as inputs.
Risks & open questions
Appetite
2 cycles. Core schema changes, frontend editor work, and documentation updates. Currently unsure about where the technical complexity lies, but the cross-coordination across teams has proven time-consuming, so we need to take ample time to get this right.
Execution issues
No response
Decision log