snapboard documentation
Choose a version
Version 0.2.5
Boards & Columns #
This is archived documentation for SnapBoard 0.2.5 Alpha, not a guide to a current SnapDock feature.
Data Model #
SnapBoard stored an array of boards. Each board contained an ID, name, and ordered array of columns. Each column contained an ID, title, and ordered array of cards.
application state
└── boards[]
└── board { id, name, columns[] }
└── column { id, title, cards[] }
The first launch created My Board with To Do, Doing, and Done. A board created through the state method started with no columns; the three defaults applied only to initial application setup.
What the Final Interface Implemented #
The final interface rendered the current board and its columns. Users could:
- add an empty column with Add Column;
- rename a column by double-clicking its heading, entering a non-empty title, and pressing Enter or leaving the field;
- cancel a rename with Esc;
- add and delete cards.
Column titles and card counts were escaped before insertion into the page. The board area scrolled horizontally as columns accumulated. No enforced 32-column limit or documented performance capacity existed in source.
Partial Board Management #
The state module implemented functions to create, rename, delete, and select boards. The HTML also contained a slide-out sidebar with an empty board list and a New Board button. However, the final sidebar module only opened and closed the panel; it never populated the list or attached actions to the board controls.
Consequently, multiple-board support was partial: the persisted schema and manipulation methods existed, but the archived UI did not provide a complete way to manage or switch boards. Board renaming code also existed but its setup function was never called.
Incomplete Interactions #
Column deletion had a confirmation handler and a working state method, but the handler searched for an obsolete .flex ancestor that the final column markup did not contain. Column reordering was not implemented.
Card movement had a complete state operation for removing a card from one column and inserting it into another. The drag-and-drop UI prototype, however, listened for .card and .drop-zone, while the final renderer emitted .sb-card and .sb-column-body. The final archived interface therefore did not provide reliable card movement or reordering.
Deleting a column in the state layer also deleted all of its cards; there was no archive or recovery container.