# Every database view type _Table, list, board, gallery, calendar, timeline, and chart views, including their required fields and saved settings._ Canonical: https://snoze.dev/help/view-types/ A database owns records and fields. A view is a saved presentation of those same records with its own kind, filters, sorts, group, field visibility, manual order, and display settings. Changing a view does not copy or move its records. Canonical contract values: - `table` - `list` - `board` - `kanban` - `gallery` - `calendar` - `timeline` - `gantt` - `chart` `kanban` and `gantt` are readable legacy aliases. `kanban` renders through the Board implementation and `gantt` through Timeline. New choices and documentation use `board` and `timeline`, so the aliases do not have separate entries below. ## Shared settings Every view can save filters, an ordered list of sorts, one group configuration, visible field keys, conditional formatting, and whether the record title is shown. A view may be shared or personal. Standalone views have their own sidebar item but still point to a view row whose data source is exactly one database. Changing layout preserves shared settings where they remain meaningful. A layout-specific setting, such as a Timeline end date or Chart axis, stays in the view manifest but other layouts ignore it. ## Layouts ### Table `table` Renders records as rows and fields as columns. Its manifest stores the visible column allowlist and order, per-column widths, pinned columns, manual record order, title label/icon, and title visibility. It is the layout for editing many values in place and for adding or rearranging fields from headers. Grouping draws collapsible row sections. Filters run before the rows are grouped and sorts order records within each group. Empty values sort after non-empty values. ### List `list` Renders one compact row per record, with the title and the fields enabled in the view's Properties setting. It supports the same filtering, sorting, and grouping engine as Table but does not expose a grid of editable columns. Use it when the record title is the main thing people scan. ### Board `board` Renders cards in columns. Its group field must be Select or Status; each option becomes a column and dragging a card writes that option back to the record. Status columns keep their configured manual option order. Empty columns can be kept visible so they remain valid drop targets. Board also uses the view's visible-property list to decide which fields appear on each card. It cannot make columns from arbitrary text, relation, or date values even though those kinds can be grouped in non-board layouts. ### Gallery `gallery` Renders a larger card for every record, using the record title and the properties enabled for the view. It supports shared filters, sorts, and grouped sections. The current view contract has no dedicated gallery-cover field or card-size setting, so do not rely on either as saved configuration. ### Calendar `calendar` Places each record on a calendar using `dateFieldKey`; when that setting is absent it uses the first Date field. The database therefore needs a Date field to place records. Dragging or resizing calendar events updates that date value. The saved display mode is month, week, day, or agenda. The view can hide weekends, choose which weekday starts the week, and configure weekend days. Filters and sorts still run before calendar events are built. A record with no value in the chosen date field is not placed on a day. ### Timeline `timeline` Draws records as bars from `dateFieldKey` to an optional `endDateFieldKey`. Without an end field, each record becomes a single-day bar. The axis scale can be day, week, month, quarter, or year, and the view persists its zoom and manual row order. Optional channels bind real fields to progress (Number or Checkbox), milestone (Checkbox), baseline start/end (Date), and assignees (User). Display switches show or hide owner, tags, days, dependency lines, and critical-path highlighting. The timeline renderer supports dependencies, but those links are separate from the start and end date fields. ### Chart `chart` Aggregates the records that survive the view's filters. Chart types are vertical column, horizontal bar, line, donut (`pie` in the manifest), and a single number. An X-axis field creates categories; the Y axis either counts records or uses a numeric field, and an optional second field segments a series. Chart settings include manual/ascending/descending category order, omitting zero values, automatic or fixed range, reference lines, colour, labels, smooth line, stacking, title, and small through extra-large height. Stacking only applies to bar and column charts. A chart is a view over current records, not a stored snapshot, and it does not write values back. ## Per-view and per-database changes Filters, sorts, grouping, field visibility, layout, and layout-specific settings belong to one view. Field definitions, option lists, record values, formulas, and relations belong to the database and affect every view. Hiding a property in one view does not delete it; deleting a field does. Next: [Filtering records](https://snoze.dev/help/filtering-records/), [Sorting records](https://snoze.dev/help/sorting-records/), and [Grouping records](https://snoze.dev/help/grouping-records/).