Certainly, mixing data with schema is a really bad idea, but button fields are about mixing actions (and business logic) with schema, not quite as onerous an idea as mixing data and schema. This is akin to stored procedures (in Oracle for example), the difference being that stored procedures are actually data values in fields that are interpreted at run-time. This makes it very easy to treat stored procedures like any other field and like any other data and thus, it doesn’t require complex recognition in the security model or any other aspect of handling schema operations.
And I don’t want anyone to get the sense that we [collectively] have a basis for second-guessing the Airtable team; they’re under a lot of pressure to make it different, make it competitive, and all while not breaking it.
However… this is a topic that is certainly worth considering and being aware of because I’m pretty sure the team is fully aware of the nature of data, structure, and actions. But they may be forced to make some difficult choices and as users, we have to be careful about that which we politely “force” them to do, right?
Recall that for many years, the team has been pressured across many dozens of feature suggestions to add various types of string parsers that were all fundamentally based on the inability to split strings into arrays. I don’t think they caved to all these self-interests and I applaud them for that. I cannot be as kind to them for not implementing Split().
To be a bit more precise about my assertions …
More clarity is needed concerning the vernacular (which is where my commentary began). This is not about “buttons”; it’s about actions. A button is simply (in my view) a poor implementation strategy for field and record-level actions. @kuovonne made this distinction earlier as well.
And yet, we already have many “buttons” (i.e., actions) attached to many of the fields - select lists, dates, links, long text fields, etc. Actions exist everywhere - why not make arbitrary “actions” possible as well?
Can you imagine an action configured for a specific field that would do things like this?
- Right-click, search the web for the value in the field.
- Right-click, search the current table for the value in the field.
- Right-click, search the base for the value in the field.
- Right-click, replace the value in the field with the title-case version of the string.
- Right-click, take the value in the field and pass it to an external web service returning a more complete value for that field.
- Right-click, transform the value of a long text field to summarize the content.
- Click and pass the value of the field to a function or a script block.
This approach would probably achieve all that you’d ever want a “button field” to do without conflating the fundamental aspect of your schema design with hybrid “field” elements.
With this commentary [nudge], I am simply suggesting that Airtable resist adding hybrid field elements and instead follow a consistent and platform-wide approach that expands the opportunity to add new actions and event handlers for all objects starting at the most granular levels (a word in a text field), the field value itself, the record, etc.