What is the best way to design a task management system in Coda with a single table “Tasks” (where tasks can belong to various projects or workstreams) that apply various work-in-progress limits for tasks in different statuses (In Progress, In Review, etc)?
I think it should be possible if tasks are browsed in a bunch of filtered table views where moving tasks between statuses is always done via a button. This approach is described in this video. However, this approach couldn’t be combined with Card view, I think. And the status of a task can always be changed directly, bypassing the button.
In general, it seems it would be useful to be able to specify invariants for a table which don’t allow a table to be changed so that the invariants are violated. These invariants can have associated messages which pop-up if a user tries to change the table so that invariants are violated.
Can you say a bit more about what the limits should be?
Is it like, if a project is in stage 1, you can’t change it to stage 4, but instead have to set to stage 2, then stage 3, and then you can set to 4?
I’m not sure how to prevent a determined user from modifying the data, but if you just want to prevent accidental disobeying (and force people to use the buttons), you need to make it so that the “status” you show them is not editable. How? Make a hidden status column that you change via buttons, and then make a display status column with formula =HiddenStatus
(Note that I have checked the video you linked yet, maybe this is already what they recommend haha)
Oh and when you say card view, do you mean like a Kanban layout (grouped by statuses) where people can drag between statuses, and you want them to use buttons instead?
If so, the same 2-column solution for status will work here too. Group based on the display status column, and they won’t be able to drag.
Work-in-progress limit = no more than 5 tasks can be in the “In Progress” status at any given time. Sixth task cannot become “In Progress” before one of the existing tasks is moved to “Done”.
Have a look at this demo (easiest is to open it up and hit “Copy Doc”). I’ve sketched out how you might handle table-based views (like in the video you showed), as well as Card-based views that are grouped by status.
I would note, however, that I don’t generally recommend being so absolute in enforcing rules like this. In this version of the doc, users are truly never allowed to overload a category (let’s call this the “Prohibition” design approach). But in my experience there are always edge cases that creep in where it’s helpful for your users to be able to disobey the rules for just a minute (“relax, I’ll move another task out of that status in a sec, just let me finish with this one”), or in a special circumstance (“I know it’s maximum 3, but these tasks are smaller than we ever planned for so I know an extra one is fine”).
With this kind of real-world messiness in mind, I lean more toward warning messages that appear when users break the rules - let’s call it “Allow-But-Warn”. In this design approach, you would let them overload the statuses, but you’d have a canvas formula along the lines of:
IF(
thingsInProgress > 3,
"CAREFUL! You shouldn't have more than 3 things in progress at once.",
""
)
Which means if they’ve overloaded the category, show the warning message, otherwise show nothing.