If you start editing a text field in a table and then click on another input form, such as a checkbox or a button, it won’t unfocus the text field (which is probably a bug in coda).
And any changes to the text field are only saved when you unfocus it.
Why is it a problem?
Let’s say you have a text field as an input and a “confirmation button”. (The simplest example of this is interface for creating new rows)
In order for this button to work correctly, you would need to click somewhere else on the document before clicking it. Not only is this rather annoying, but it’s very likely that in a hurry you forget to do that and inputted data will be parsed incorrectly.
Solution
There is a pretty simple solution to this which uses hidden formulas.
The idea is to open url of the currently displayed table/view and then adding a small delay with the _Delay() function before launching the actual action on the button. The delay is required in order for the value of the text field to be updated when the actual action is being executed.
The minimal delay that I found working was 9ms, however I recommend setting it to 50ms just to be safe, since the difference is completely unnoticeable. This delay works even if there are slow calculation formulas using the input cel.
So if the button had previously this formula:
The updated formula would look like this:
Sandbox
You can play around with this hack in the document below.
I’m an engineer at Coda, and the bug you’re reporting was actually a poor decision on my part. I was trying to tackle a problem where clicking on a button or checkbox would cause your selection to move to that cell, and if that cell was driving which group or sort position that row was in, your screen would suddenly jump and scroll away. This is particularly frustrating if you’re trying to click a few buttons in a row, as your screen jumps on every button click.
My initial naive solution, which you were running up against, was to leave the selection where it used to be, and avoid transferring focus. This clearly caused issues.
Because of your post, I spent some time rethinking the approach, and it occurred to me that the root issue was less that the focus was transferring to the button or checkbox, and more that the row was moving so suddenly.
To resolve this issue, we now “pin” your row as long as you have focus on it. So, if you click a button, we will still select the cell, but we will not immediately update the group or sort order of the row. Instead, we will give a visual indicator that it will go away, and when your selection moves away from the row, it will indeed go away to its correct location.
I hope you find this experience a bit more reasonable, and thanks for sharing your thoughts about the product here.
I agree this transitioning stage is a nice touch. But I have a case where I’d rather have the info change immediately:
I have a kanban view and each card has a button that moves the card over to the next column (and logs this update to another table). In some conditions*, when the user clicks the button, the card doesn’t immediately jump to the next column, but actually enters this transitioning stage. Some of my users don’t get it and click the button twice. That’s frustrating and leads to errors.
Why I said some conditions: It seems this transitioning stage only happens if the card is focused when the user clicks it.
It happens, for example, if the user clicks the card to open detail view then closes it.
Also, that same button appears in the detail view. When the user clicks the button inside detail view, the closes it, the transition stage is triggered as well.
A workaround is to add to your button another action to move away the focus from the current row.
In this example I created a table with a single row simulating a callout, and everytime a button is pushed to move up or down a row, the information callout is selected, allowing the change to be visualized almost instantly.
