The Board

Five status columns — pinned headers that stay put as you scroll, live counts, and a + on each column that opens the New-task dialog and creates into that status (absent in All projects and My view: a status column names no project to create in — §3). Drag individual tasks between columns; the board updates directly without a success popup. Tasks sort by priority within their card groups. A task in a project you can only read doesn't lift at all — the drag never starts, rather than snapping back when the server refuses it (§12).

Empty cells stay blank, with room to drop a task; a valid destination still highlights while dragging over it.

While dragging over another valid status or assignee cell, its existing cards dim together with their parent headings, leaving the column outline clear. They return to their usual appearance when you leave that cell or finish the drag. The task's current cell and invalid destinations neither highlight nor dim. In Swimlanes by assignee, another eligible person's cell still highlights at the same status because dropping there changes who holds the task. Dropping changes status, assignee or reviewer according to the layout; it does not make the dragged task a child of the task beneath your pointer. Existing siblings still group together in their destination column.

Blue, Dark and Light use the same full-panel board design. Each lane has a continuous background, an enclosing border and dividers between status columns, with rounded task cards inside. While a Canvas image is showing, the panels turn translucent in every theme, letting the photograph show through the panel material and in the gaps between lanes. Without an image, Blue uses solid navy panels and Dark solid dark panels, each over a darker workspace; Light uses white panels over a pale workspace. The same design applies to Swimlanes, Swimlanes by assignee, Pooled and Side-by-side boards.

The Board controls sit 24px above the board panels. In Swimlanes and Pooled, the shared status header stays above the task scroll area, so the vertical scrollbar starts below it. In Swimlanes, an 8px gap separates the status row from the lane heading below it.

Lane headings stay pinned while you scroll. In Swimlanes, scroll through a project or sub-project until its last task is fully visible. The next downward mouse-wheel or trackpad scroll advances to the next heading, tucked under the status columns. From a lane's heading, an upward scroll returns to the previous lane's last tasks at the bottom of the window. If that lane fits in the window, it aligns at its heading instead. This also works if a wheel step has carried the heading slightly below the status columns. Inside a tall lane, upward scrolling first moves through its earlier rows until you reach that lane's own heading. A snap briefly holds same-direction wheel input while the board moves into place. Once it arrives, continued scrolling reads through the tasks or advances to the next lane if all its tasks fit. You do not need to pause between wheel ticks. Reversing direction during a snap returns toward the edge you just left. Taller lanes scroll normally between their heading and final task row. A large wheel step stops at that edge before a later step enters the next lane. Keyboard and scrollbar navigation scroll freely. The last headed swimlane can reach that same position even when its cards do not fill the window: the board leaves enough blank space below it to scroll its heading into place.

Each side-by-side mini board's header also pins as you scroll, keeping its project identifiable. Its task columns share one enclosing panel.

A project lane's name is a way in. Click it and the whole app scopes to what it names — the project, in All projects and My view where a lane is a project; the sub-project, on a project's own board. It works the same in the side-by-side layout, on each mini board's header, and on the roadmap, where the rail's track and sub-project headings are the same kind of link (the chevron beside the name still folds the rows, as before).

Board layouts#

When you scope a whole project, choose how sub-projects are arranged. The switcher itself names the choice in a word — Project, Assignee, Pooled or Separated — and its menu spells each layout out: Swimlanes by project (one lane each — the lane's name pins under the status headers while its cards scroll, so you always know whose column you are reading, and the next lane pushes it out), Pooled, one board (everything merged, cards carry the sub-project name), or Side-by-side boards (a mini board per sub-project). The same switcher works in All projects and My view, where the unit it arranges is the project — one lane, or one mini board, per project, with each card still naming its sub-project (and, on the pooled board, its project too).

Lane headings — project, sub-project and assignee alike — show their names without a task counter; the status columns carry the counts.

In Swimlanes by project and Side-by-side boards, drag between statuses within the task's existing lane or mini board. Other project or sub-project groups do not highlight as drop targets, and releasing there leaves the task unchanged. The drag preview can still follow your pointer outside its board. Pooled keeps status dragging across the shared columns.

Swimlanes by assignee, directly below Swimlanes by project in the menu, groups tasks by the person or agent who owns them: the assignee, or the reviewer while a task waits In Review with one (§2), so Review cards sit in their reviewer's lane. Names appear alphabetically, with Unassigned last. This option also works within a single sub-project. Cards retain their project context and the current filters still apply.

Dropping a card within its own lane changes only its status; a task that has a reviewer then moves to the reviewer's lane as it enters In Review. A drop that the new status alone hands to the target lane changes only the status too: dragging a Review card from its reviewer's lane into In Progress in its assignee's lane returns it to the assignee. A drop into another person's lane in any column but In Review makes them the assignee. In the In Review column it makes them the reviewer and leaves the assignee alone; a drop onto the assignee's own lane there clears the reviewer instead, and the Unassigned lane there refuses a task that has an assignee. The new assignee or reviewer must be eligible for the task's project. In the project-based layouts, dragging between columns continues to change only status.

Cards#

Tasks with the same direct parent share one card within each status column and swimlane. The parent's title names the group, with a small assignee portrait beside the person's first name. It has no Parent label or status. Indented compact rows below show the tasks in that cell, joined by a branch rail that ends at the last child. If siblings are spread across columns or lanes, the parent heading appears above each local group. Hover the parent's assignee to read their full name.

Each child has its own title, priority, remaining hours, due date and assignee portrait on the right, larger than the parent's portrait. Hover the portrait to read the person's name; an unassigned child has an unassigned indicator. When you can edit the task, click its portrait to choose an assignee without opening the task window. The searchable picker offers eligible people and agents for that project, plus Unassigned to clear the assignment. This also works on the smaller parent portraits and unassigned indicators. While a task waits In Review with a reviewer, its portrait is the reviewer's, and the picker changes the reviewer instead, with No reviewer to clear it. Project and sub-project names appear when the current layout needs them. The parent's project label is omitted when every visible child already repeats the same project. A paused task keeps a small amber pause mark visible. Delay banners still identify tasks that are slipping or delayed.

Click a child row or the parent title to open that task's usual window. Drag a child row to move that child between statuses. Parent headings cannot be dragged between statuses and add nothing to column counts. Filters apply to the tasks, so a matching child keeps its parent heading visible even when the parent does not match. A group with no matching descendant tasks has no card of its own.

For nested subtasks, the headings retain the ancestor context above the tasks that do the work. Tasks outside these groups keep individual cards. After the last active subtask leaves a parent, that parent returns to a normal card in its saved status column. Hovering a task leaves the other tasks at their normal brightness.

Stale tasks fade#

Tasks untouched for longer than the standard stale threshold (120 days) render dimmed — still readable, fully restored on hover, and isolatable with the Stale filter. In a grouped card, only the stale task's own row fades; hovering restores that row. Done tasks never count.

✦ What sets this apart — Neglect becomes visible instead of silently accumulating: unfinished old tasks fade in place where you can still see them — only Done work ever archives itself (§9), and anything archived is restorable in one click.