I really loved the discussion on my last post. Here’s another one for ya!
What are the considerations one should make when adding a button to an interface in terms of using a Button field vs an interface Action Button?
I actually already have some strong opinions on this, but want to hear from the community who likely have their own experiences/preferences.
A button field can only be used to open a URL. I like that a button field is smaller than an interface action button and has more choice of colors. My most common use case is to open a different interface page. Before we had side-sheets, I would use button fields to jump to the interface page with details for a linked record. Because building these urls requires a formula, I find it easier to put the formula for the url in a button field and then use the button field directly.
If you need a button in an interface to do anything other than open a URL, you must use an interface action button. My most common use cases for interface Action buttons are triggering automations and deleting records (usually from a side-sheet).
I rarely use an interface action button to update a record. Usually, I use a button that triggers an automation, and I have the automation check to see if updating the record is really a valid action to take before doing the update. (For example, is data entry really complete, or would the update represent going to an earlier stage in the the record’s lifecycle.)
On the other hand, if I need to know who pushed the button, I will use an Update action button that sets a hidden user field, and have the hidden user field trigger an automation that does the rest of the work, including resetting the hidden user field.
What are your opinions?
For me, the coolest thing about the interface buttons is that they can automatically change their color, their title, and their active state when performing an “update field” action.
So you can present some fantastic visual feedback to the user while simultaneously preventing the user from clicking the button more than once.
And an updated field can be used to trigger an automation. So an “update field” action can be used to do anything you want to do in Airtable without ever leaving the page you’re on.
Field buttons on interfaces can be dimmed too, but they can’t change colors and they can’t change their title… and they can only open a URL, so a new browser window will always be opened, no matter what you’re trying to do. Crazily enough, they can’t trigger automations natively.
The real problem here is the overarching problem with Airtable in general: inconsistency between different parts of the product. All the functionality of button fields and interface buttons should have been merged together into one unified button object.
I find this useful only when the field will be updated to a new value, and will retain the new value. However, it is less useful when a field will need to be promoted through a lifecycle, and the field will have a new value at some later point in time. When the field has the later value, the update button becomes re-enabled, which may not be the desired behavior.
For example, say a record goes through a lifecycle that is tracked by a {stage} field: stage1, stage2, stage3. The button is designed to promote the record to stage2. The button starts out enabled, because the record starts at stage1. In fact, the button is enabled, even if the requirements for being promoted to stage2 are not yet met. Thankfully users are trained to not push the button prematurely. When the user pushes the button, the stage changes to stage2, and the button becomes disabled. However, then later on, the record needs to enter stage3 (via some other mechanism). The button actually becomes re-enabled again, and pushing it would revert the record back to stage2, which may not make sense.
All this is to say that I personally find the enabling/disabling of update record buttons to be lacking. Instead, I just let the button be enabled all the time and have the automation check if it was really okay for the button to be pushed, and if the button should not have been pushed yet, to not update the record.
I really like how Coda lets me use a formula to determine if a button is enabled/disabled. That way the enabled/disabled state of the button reflects the proper logic and not simply whether or not the fields have the target values.
I don’t think that is possible given the current architecture.
Interface button elements can do things that button fields cannot, such as record navigation, copying urls, deleting records (without a script), or updating records (without a script).
Button fields can do things that interface button elements cannot, such as open extensions or run scripting extension. (Scripting automations have significant differences from scripting automation, including time limits, knowing who the user is, providing feedback to the user, and getting additional input from the user.)
Button fields that open urls can also be included in grids in interfaces, which interface button elements cannot.
The only native action that both button fields and interface button elements have in common is opening urls.
Yes, in those situations, I would typically have it update a hidden field (like a hidden checkbox) — which then runs an automation to do whatever I want it to do. So the hidden checkbox can update the real field to “stage 1”, for example.
That would be really nice to have in Airtable!
Airtable has already given us an idea of how this could be handled: For the button fields, they will actually remove the “Open Source Record” option if it doesn’t apply within the current context.
I actually find this very confusing & unintuitive — I wish that they would just DIM the invalid options if they don’t apply within the current context. Otherwise, people would never know to keep checking back to see if the button options have changed based on a brand new context. People expect menu options to remain static with the invalid ones dimmed.
Yeah. That would work. But it requires another helper field that exists only to say if the button was clicked. And it still needs an automation to to update the actual field. I guess it comes down to balancing the user experience with the complexity of the system.
Yeah, it would be nice to not have to jump through all those hoops. It sounds like Coda has got a pretty cool developer experience.
Yup. The Coda formula language is more extensive than the Airtable formula language, and it is used in a lot more places.
But there are other things that Airtable does better than Coda. So, it’s a trade-off. I like both platforms.
Are you talking generally or specifically in regards to formulas? What are the differences?
I’m talking about the two platforms (Airtable and Coda) in general. I really like both. But sometimes I get frustrated because something is easy on one platform, but I need to use the other platform where it is not easy.
When it comes to the formula language, the Coda formula language is more robust than the Airtable formula language. When it comes to the formula editor, I mostly prefer the Coda formula editor, except when it comes to using the keyboard to move around the editor.