I think it would be nice to have the option to hyperlink with different text showing, like any basic HTML hyperlinking. Like I can even do in this forum if I needed to.
Visually, having the url just there isn’t appealing.
Let me know what you think of maybe this compromise?
So AT fields already have the Configure Field dialog, and depending on the type of field that dialog has one or two tabs (see Date fields for example). What if there were a third dialog that is basically a recreation Button field’s config options, thus giving any field type the opportunity to tie an action to it.
Now when you focus a field value in AT you get the Expand Record icon as well as the “add” button if its an Attachment or Link field. What if there would also be another button which matches AT’s vision as shown by the Button Field which becomes visible in the left or right corner of the field when the field is focussed (or maybe its visible by default?). Clicking that button runs the action as configured in the field settings. This method would probably have to do away with the button label capability lest we have columns much wider than we’d otherwise desire. If a user wants more flexibility then they’ll use a Button field.
Does that sound like it gets at what @Bill.French and @ScottWorld envision? My brain absolutely only ever works if I can talk out how something looks, not how it behaves so forgive me belaboring a point
You bring up a great point here! I totally agree with you that they could be treading down a slippery slope by mixing data with schema, and by misunderstanding the difference between data and structure.
Especially in light of setting field permissions or future product upgrades.
For the time being, it looks like the screenshot below is how they have solved the field permissions issue for button fields.
Oh, I wasn’t envisioning anything — I am totally fine with how the button field is currently implemented. I was just partaking in the conversation. I don’t think we need buttons attached to other fields, as I rarely use that feature in FileMaker. My buttons are usually standalone buttons in FileMaker, so I like buttons being separate entities.
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. :winking_face:
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(). :slightly_smiling_face:
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.
I’m a bit late to this fascinating conversation, and at first I was totally on board with the points you’re making, @Bill.French. However, I saw this:
…and then later this:
Aren’t both formulas and buttons in this same vein as Oracle’s stored procedures? A formula outputs data at run-time. Change the data in the fields used by the formula, and the formula outputs new data. The URL tied to a button is driven by a formula, so it’s in the same category as I see it.
I get what you’re saying re: adding the ability to tie actions to other field types, rather than making a field type that appears on the surface to be all action. However, the way I look at it, buttons do contain both data and action. Without the data—the URL created by the button’s formula—the action can’t act.
It’s a good question, but I think the implementation may actually be quite different. Unfortunately, I cannot perform any tests because I have not been given access to the beta.
One test that would be interesting and quite telling about the underlying implementation – can we filter based on the action content of a button? If yes, then your assertion is a good one, and I would be a little calmer about this hybrid field direction. This of course is notwithstanding the idea that – unlike stored procedures - there is an overt UI component coupled with the action “data” and I’m guessing you can’t not have a UI control appear in a button field.
Another test that would useful is to understand how buttons are exposed (if at all) in API results? If they are hidden, they’re not likely data fields.
To be clear - my suggestion that button fields are “akin” to stored procedures was the closest parallel I could think of in a true database environment. They are certainly similar because each approach creates the ability for late binding logic. But given the test I outlined above, that should tell us if your proven hypothesis would have a calming affect on old developers like me. :winking_face:
Ooops! I forgot to address this observation.
Indeed, and I have no beef per-se with formulas except that they are “fields”. :slightly_smiling_face:
As implemented, each formula can generate field data, but an existing field can’t use a formula. That’s my long-standing complaint about this design and I believe it’s all related to these hybrid fields. If you need a field that is based on a formula, why not make it an attribute of a real field? This exposes the field to the schema, allows you to manage it like any other field within the schema, and provides an opportunity to create very succinct database structures.
@Bill.French, for me personally, I just don’t see most of the things that you mentioned as a problem. I’m really sorry, but I don’t.
Why? Because these seem like tiny issues that are subjective, whereas I feel like we have MUCH bigger objective fish to fry, such as this GLARING & GIGANTIC security hole in Airtable, which allows ANY COLLABORATOR (including read-only collaborators) to steal 100% of a company’s proprietary data with one click of a button:
I mean, now this is a REAL issue that we have right now, and it’s a major SECURITY issue. If you could chime in on that other thread about that other issue, I would greatly appreciate it! :blush:
LOL! I agree 100%. We often get into the weeds about [seemingly] obscure and meaningless debates. Security is a big fat Grouper in fry pan. In that sense, you are clearly a voice of reason - the adult in the room. I promise to spend a few cycles pushing that requirement.
However… like security - certain design choices can impact the ability of a platform to achieve the security required. Just sayin’ … I think you actually caused me to think about security in the context of hybrid field types.
This is such a good point. Design choices do affect security, and I do believe that we will be seeing future security issues based on today’s poor design choices.
Absolutely, I can envision a user interface where developers can attach any action to any field/control. However, I feel that this sort of functionality needs to be implemented carefully.
Have a special view for fields/controls with these actions. Do not implement these customized actions in the grid view.
Make sure that editing of these actions is limited to people with creator permissions (not just editor permissions).
This beta for the button field is very new and subject to change. I don’t think that we can tell much based on how buttons interact with filtering or the API at this point. Maybe the implementation is incomplete or maybe there is functionality there that will be removed or changed.
Also, the support page with info on the beta only shows one action type–open url. Currently this action doesn’t really add new functionality–it just makes it prettier. One can already open urls by clicking on them.
