Board Appview

Board AppviewComing Soon

I can't do proper Product Management and CRM without a Board Appview with document states. This is hurting my/our productivity a LOT.

This weekend, as an experiment, I am going to do the same exercise as with the Surveys Appview and build a Board Appview.

Ideas are welcome

Steps

Board Stories

Product Vision Activity: Plan a Workflow Core Principle A Board is an AppView. A Card represents a Document inside a Board. The Board owns workflow state. The Document owns knowledge. Multiple Boards can organize the same Document simultaneously without duplication. Queries are the primary mechanism for building dynamic AppViews.

Board Concepts

I would derive the concepts by asking: What nouns have identity and behavior? Not "column" because Trello has columns. Not "status" because Jira has status. Instead, identify the stable concepts in the domain.

Inspirations and Sketches

XState

Protocol Blobs

From what we’ve discussed, I’d map Board AppView onto existing Seed blobs like this: 1. Change Blob 2. Ref Blob 3. Capability Blob 4. Comment Blob / Discussion Change 5. Query Blob / Query Change 6. Blob / Media Blob Clean model

Developer Experience Pains

I want clear documentation with hello world example and Get Started steps I want to create the Boards Appview. Why can't I use the Auth System directly without so many questions from the AI? Creating a Server, running a new branch, and building the new code takes 80% of my Vibe Coding time Complete Uncertainty on the Presentation View Layer should work I want to understand how the system and protocol works I have no idea on how to run this without branching the app, can't we have an easy way to run my own software? It would be useful to have a protocol analyzer that tells the developer in real time protocol verification feedback

Board Schema

Persist the Board as a board-owned Seed document at a reserved, hidden path, not inside the home document and not as local UI state. Reserved path: /:apps/board Then the public Board URL stays: /:board But internally, it loads/saves the Board state from that reserved document. { "version": 1, "query": { "includes": [ { "space": "site-uid", "path": "design", "mode": "AllDescendants" } ], "sort": [ { "term": "UpdateTime", "reverse": true } ], "limit": 50 }, "workflow": { "columns": [ { "id": "backlog", "title": "Backlog" }, { "id": "ready", "title": "Ready" }, { "id": "in-progress", "title": "In Progress" }, { "id": "review", "title": "Review" }, { "id": "done", "title": "Done" } ], "cards": { "hm://site-uid/design/example-doc": { "columnId": "backlog", "labels": ["UI", "Research"], "assignees": ["account-uid-1"], "dueDate": "2026-06-30", "priority": "High" }, "hm://site-uid/design/another-doc": { "columnId": "review", "labels": ["Docs"], "assignees": [], "dueDate": null, "priority": "Medium" } } } } Key idea: Why this is best: I would avoid daemon-only persistence for now because then published web Boards will not reliably work. Recap Persist the Board in a hidden/reserved Seed document like /.seed/board, while keeping the user-facing route as /:board. Store the query definition and workflow overrides there; compute cards dynamically from the query. version: 1 query workflow cards

Where Should Board State Live?

Board State Persistence: Board Document vs Distributed Document Attributes

Do you like what you are reading? Subscribe to receive updates.

Unsubscribe anytime