Checkbox alternative in Coda
Replace a checkbox with counted values via a lookup
Many Coda makers direct the buttons behavior with a checkbox. You click on the button and via ModifyRows(), the checkbox is (un)checked. Once (un)checked other actions are permitted or blocked.
When you look into a table you have to look into the buttons to understand when and how they modify these checkboxes. Certainly in larger documents or in docs you do not open often, it becomes hard. Documentation — as I tried — is not a good enough solution. The writing mainly helps to avoid mistakes, but does not help a lot in understanding afterwards the choices made a while ago. You need diagrams, living code snippets, etc, all of which are not yet available in Coda.
In this blog I present an alternative using a lookup. In my example it is about the status of time off due to vacation or sick leave. Both relate to a probationary period, a well known system in the USA.
The Problem I try to solve
In a permission system you ask users to push a button to make a choice. One this choice is made, you archive it and you relate it to other possible choices. In my approach is about giving the permission for time off. The decision of the Manager and the HRM department are needed.
In my initial set up I had a checkbox for the manager (checked means it is ago) and one for the HR manager. As long as either of them remains unchecked there is no permission for time off.
This approach created all sorts of complications. I first created extra check boxes like below to solve these issus. I did so to make choices explicit and as a result I needed code to check all theses boxes. That gets messy easily.
The alternatieve for a checkbox
Instead of using a checkbox per button and thus per user, I propose a lookup field that permits for multiple options, like below.
On a side note, previously I had two buttons. The same button could create Approved (one click) and a Rejected (next click) and so on. That worked for me as maker, not for the users. They wanted one button per action.
We have thus 4 buttons and two result fields. In the lookup column we have the main status or max two status types. Once you click twice on approved, you only see approved only once. A lookup shows unique values. In the statusArchive we keep track of the individual choices and in the doc I apply this, I added a time stamp as well, as you see e bit further down.
In my scenarios we work with a simple logic. All people need to approve, one rejection is enough to block the process.
Instead of checking 4 columns with checkboxes, I check two columns to define what our next step is:
- Two times approved is approved, email goes out.
- No or one vote — we count via statusArchive — means we wait
- One rejection results in a ‘sorry we cannot honor your request’ email
The 4 main benefits
First we have less columns, that always helps to keep the tables understandable. Second we can read the choices made, as opposed to the scenario we have to deduct meaning based on columnName and status. Third the calculations we need to define next steps are easier to set up. In our scenario we only have two people, but would it be that we have a team of 7 people, the logic would be very much alike, we would count the statusArchive input and compare the count with the team count (7 in our example) to check for a go if there is no Rejected. The last benefit you see below. We disable the button based on the content of the statusArchive instead of relating to a checked box or a resultColumn. The code snippits are concrete and tell us a story. This helps to create and maintain docs.
I hope you enjoyed this article. If you have questions feel free to reach out. Though this article is for free, my work (including advice) won’t be, but there is always room for a chat to see what can be done. Besides you find my (for free) contributions to the Coda Community and on Twitter.
My name is Christiaan and I support SMB with calculations (budgets and — Human Resource — planning) and I prefer using Coda to get the job done.
Coda comes with a set of building blocks ー like pages for infinite depth, tables that talk to each other, and buttons that take action inside or outside your doc ーso anyone can make a doc as powerful as an app (source).
Not to forget: the Coda Community provides great insights for free once you add a sample doc.
