# Keep work moving

Board: https://swipefile.design/board/keep-work-moving/
References: 3

Use this board as design direction for my project. Review the references below, identify useful layout, typography, color, and interaction patterns, then adapt them to my brief. Cite the original references you use.

Use these references for design principles. Follow the project brief and use original branding, content, and imagery. Captures document a particular date; they do not verify current product behavior.

## 1. Tabler — Kanban board

Source website: https://preview.tabler.io/tasks.html
Swipefile reference: https://swipefile.design/ref/tabler-kanban/
Screenshot: https://swipefile.design/_astro/full.BphykkYq.webp
Captured: 2026-09-05 | Scope: viewport | Type: app | Style: Project Management

A task board groups work by progress while keeping owners, dates, and checklists on each card.

Useful for: Compare work stages at a glance while keeping the details needed for the next action on each card.
- surface: Kanban board
- nav: Project-area tabs sit above the board beneath a shared app header.
- layout: Three work-in-progress columns contain cards of varying height, with optional previews and compact metadata.
- density: Primary content has the most space; repeated rows and secondary navigation use a compact, consistent rhythm.
- color: Pale gray workspace, white cards, blue actions, and restrained status accents.
- typography: Medium-weight card titles lead compact dates, avatars, and task counts.
- pattern: Compare work stages at a glance while keeping the details needed for the next action on each card.
- states: Public demo board with upcoming, in-progress, and completed sample tasks.
- dont: Adapt the interaction pattern to your own product. Do not copy brand assets, sample identities, proprietary text, or assume unseen states. Specify keyboard behavior, loading, empty, error, and narrow-screen layouts for your implementation.

### Design adaptation prompt

~~~text
# Design reference: Tabler — Kanban board
Source: https://preview.tabler.io/tasks.html
Swipefile reference: https://swipefile.design/ref/tabler-kanban/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- surface: Kanban board
- nav: Project-area tabs sit above the board beneath a shared app header.
- layout: Three work-in-progress columns contain cards of varying height, with optional previews and compact metadata.
- density: Primary content has the most space; repeated rows and secondary navigation use a compact, consistent rhythm.
- color: Pale gray workspace, white cards, blue actions, and restrained status accents.
- typography: Medium-weight card titles lead compact dates, avatars, and task counts.
- pattern: Compare work stages at a glance while keeping the details needed for the next action on each card.
- states: Public demo board with upcoming, in-progress, and completed sample tasks.
- dont: Adapt the interaction pattern to your own product. Do not copy brand assets, sample identities, proprietary text, or assume unseen states. Specify keyboard behavior, loading, empty, error, and narrow-screen layouts for your implementation.

Useful for: Compare work stages at a glance while keeping the details needed for the next action on each card.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.
~~~

## 2. Tabler — Task list

Source website: https://preview.tabler.io/tasks-list.html
Swipefile reference: https://swipefile.design/ref/tabler-task-list/
Screenshot: https://swipefile.design/_astro/full.BNQTFMcG.webp
Captured: 2026-09-05 | Scope: viewport | Type: app | Style: Project Management

A grouped task list exposes owner, due date, and priority in consistent columns.

Useful for: Offer a compact alternative to a board when users need to compare many tasks and deadlines.
- surface: Task list
- nav: The app header stays global; a new-task action belongs to each status section.
- layout: Status sections each contain a compact table with checkboxes and row actions.
- density: Primary content has the most space; repeated rows and secondary navigation use a compact, consistent rhythm.
- color: White rows on a pale background with small colored priority labels.
- typography: Short headings and aligned metadata create a steady scanning rhythm across rows.
- pattern: Offer a compact alternative to a board when users need to compare many tasks and deadlines.
- states: Populated demo tasks grouped by progress stage.
- dont: Adapt the interaction pattern to your own product. Do not copy brand assets, sample identities, proprietary text, or assume unseen states. Specify keyboard behavior, loading, empty, error, and narrow-screen layouts for your implementation.

### Design adaptation prompt

~~~text
# Design reference: Tabler — Task list
Source: https://preview.tabler.io/tasks-list.html
Swipefile reference: https://swipefile.design/ref/tabler-task-list/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- surface: Task list
- nav: The app header stays global; a new-task action belongs to each status section.
- layout: Status sections each contain a compact table with checkboxes and row actions.
- density: Primary content has the most space; repeated rows and secondary navigation use a compact, consistent rhythm.
- color: White rows on a pale background with small colored priority labels.
- typography: Short headings and aligned metadata create a steady scanning rhythm across rows.
- pattern: Offer a compact alternative to a board when users need to compare many tasks and deadlines.
- states: Populated demo tasks grouped by progress stage.
- dont: Adapt the interaction pattern to your own product. Do not copy brand assets, sample identities, proprietary text, or assume unseen states. Specify keyboard behavior, loading, empty, error, and narrow-screen layouts for your implementation.

Useful for: Offer a compact alternative to a board when users need to compare many tasks and deadlines.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.
~~~

## 3. Tabler — Activity timeline

Source website: https://preview.tabler.io/activity.html
Swipefile reference: https://swipefile.design/ref/tabler-activity/
Screenshot: https://swipefile.design/_astro/full.Dx00KQbT.webp
Captured: 2026-09-05 | Scope: viewport | Type: app | Style: Media & Social

An activity feed combines avatars, action summaries, and timestamps in a quiet vertical list.

Useful for: Make recent changes readable through consistent actor-action-time rows and subtle unread indicators.
- surface: Activity timeline
- nav: A common app header frames the feed without adding local navigation.
- layout: A constrained feed column leaves open space at right; each row pairs an identity with a short activity sentence.
- density: Primary content has the most space; repeated rows and secondary navigation use a compact, consistent rhythm.
- color: White rows, pale separators, muted timestamps, and small blue unread markers.
- typography: Regular-weight sentences use selective emphasis for identities and actions.
- pattern: Make recent changes readable through consistent actor-action-time rows and subtle unread indicators.
- states: Demo activity feed with varied sample actions and relative timestamps.
- dont: Adapt the interaction pattern to your own product. Do not copy brand assets, sample identities, proprietary text, or assume unseen states. Specify keyboard behavior, loading, empty, error, and narrow-screen layouts for your implementation.

### Design adaptation prompt

~~~text
# Design reference: Tabler — Activity timeline
Source: https://preview.tabler.io/activity.html
Swipefile reference: https://swipefile.design/ref/tabler-activity/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- surface: Activity timeline
- nav: A common app header frames the feed without adding local navigation.
- layout: A constrained feed column leaves open space at right; each row pairs an identity with a short activity sentence.
- density: Primary content has the most space; repeated rows and secondary navigation use a compact, consistent rhythm.
- color: White rows, pale separators, muted timestamps, and small blue unread markers.
- typography: Regular-weight sentences use selective emphasis for identities and actions.
- pattern: Make recent changes readable through consistent actor-action-time rows and subtle unread indicators.
- states: Demo activity feed with varied sample actions and relative timestamps.
- dont: Adapt the interaction pattern to your own product. Do not copy brand assets, sample identities, proprietary text, or assume unseen states. Specify keyboard behavior, loading, empty, error, and narrow-screen layouts for your implementation.

Useful for: Make recent changes readable through consistent actor-action-time rows and subtle unread indicators.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.
~~~

View board: https://swipefile.design/board/keep-work-moving/
Swipefile: https://swipefile.design/