This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
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.
