One table, many views of the same rows
Every team ends up with copies. The planner wants a calendar, the delivery lead wants a board, the manager wants a timeline, and the person doing the work wants a plain list sorted by due date. In a spreadsheet each of those becomes a separate tab or file, filled by hand, and within a month they disagree about what is actually late.
In Appdor there is one table. The layouts are views over it. A view never holds its own copy of the rows, so a change made in one place is the change you see in all of them.
What a view is
A view is a saved way of looking at a table: which layout, which filter, which sort, how the rows are grouped, and which fields are visible. The same rows can appear in as many views as you like. Appdor ships 12 built-in view types:
- Grid and List, for rows and columns or a simpler list of records.
- Kanban and Gallery, for cards. Kanban groups the cards into columns by a field; Gallery shows them as tiles and can group them too.
- Calendar and Timeline, for records that have dates. Calendar places each record on the day it falls on. Timeline draws a bar for each record along a shared date axis.
- Chart and Pivot, for summaries of the rows rather than the rows themselves.
- Map, for records with a location.
- Workload, for how assigned work is spread across people.
- Tree, for records that have a parent, and Graph, for records that are linked to one another.
Each layout asks for something in the table
A layout only makes sense if the table has the right kind of field, and Appdor tells you what is missing instead of hiding the layout. A view that cannot work is listed in the switcher with its reason beside it. Kanban needs a select or text field to group by. Calendar and Timeline each need a date field. Map needs a Location field. Workload needs an assignee and a date. Tree needs a self-relation, a field that points to a parent record in the same table. Graph needs a link field. Chart and Pivot need a field to group by.
This is useful when you are planning a table. If your team wants a board, the table needs a status field. If it wants a calendar, it needs a date. The layouts are a checklist for the fields.
Changing a card changes the record
The layouts are not read-only pictures. Dragging a card in a Kanban view to another column changes the value of the field the board is grouped by on that record. The code that plans the move validates the target against the field's allowed options and honours any status workflow attached to the column, so a move the workflow does not permit is refused. Gallery grouping follows the same rules. In a Calendar view, records without a date collect in an "unscheduled" tray, and the interface says to drag one onto a date to schedule it.
Because every view reads the same stored rows, the result is immediate and consistent: move the card, and the grid shows the new status.
A worked example
The project tracker template builds one tasks table and four views of it. All tasks is a grid sorted by due date, with summaries for estimate and progress. Board is a Kanban view grouped by status. Timeline places each task by its start date. Calendar places each task by its due date. A separate view on the projects table groups the portfolio by status. The same template also has a formula that flags a task as overdue, so the warning appears in whichever view you are looking at.
Nothing about the tasks was entered twice. A task added once appears on the board, in the calendar and in the grid.
Who sees which view
Saved views have three scopes. A shared view, which is the default, is visible to anyone who can read the table, and anyone who can edit the table can adjust it. A personal view is visible only to its author. A locked view is shared but frozen: only its author may change it, which stops an agreed view from drifting under the team.
The interface warns you before a change in scope has side effects. Making a personal view shared tells you that everyone who can read the table will see it. Making a shared view personal warns that your teammates will no longer see it and that any share link for the view will stop working. If someone else changes a view while you are editing it, you are told to reload before saving rather than overwriting their change. You can also copy a link straight to a view.
The same layouts can sit on an app page as page elements, so a Kanban board or a calendar can be part of a page next to charts and text.
Where to start
Pick the one audience that complains most, find out which field their layout needs, and add the view before you build anything else. If the field is missing, the switcher will say which one.