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.