URL--Text to Display Feature

Not entirely true. Various APIs are able to access schema information but for true fields, not hybrid fields. Ergo, hybrid fields bad; actual fields (with attributes) good. :slight_smile:

Sorry - UPDATE…

My original commentary was intended to question the higher-level aspects of this latest implementation approach by pointing out the many issues with this pattern, not this single feature. It’s a pattern that Airtable has followed before and is simply continuing with the advent of the new Button field which I think comes with some risks as noted.

You may be thinking of only the Standard REST API, which does not have access to any field definition data.

The Scripting API provides quite a bit of metadata, and even read-only access to some field definition data. For example, you can see the colors associated with select fields and the symbol for currency fields. It does not tell you the actual formula in a formula field, but it does tell you if the formula is valid.

The custom blocks beta looks like it offers even more access to metadata. However, I need to finish a few projects before I’ll have the time to take the deep dive into custom blocks.

FileMaker has always had a formula field, and it has been working amazingly well for them for 35+ years. What is the problem you see with formula fields?

And this is good progress. It suggests that more is likely coming and with that, some of the downsides of hybrid fields may diminish, but probably not all of them.

Can Airtable transform hybrid fields such as button and formula into a schema framework that is consistent and accessible?

Perhaps, and I certainly hope so, but I think it requires them to embrace fields with discrete actions and events.

Microsoft Access has also always had a formula field and it has also always had the ability to create a button with record scope. Many of the online databases that I looked into before settling on Airtable also had the equivalent of formula fields, although most are not as robust. Some of those other online databases also had the equivalent of a button field. The nomenclature might have been different, but the idea was the same–an action button with record level scope.

2 Likes

It’s really quite simple - formulas can only live in a field dedicated to the formula. As such, to have any formula logic, you must create another field that really isn’t a field at all. It seems to me that if you need a field based on a formula, create the field and APPLY a formula. That seems logical, intuitive, and embraces all that fields are designed for - storing values - whether computed or otherwise.

This gives you the latitude of creating fields that may conditionally utilize the APPLIED formula, or in some case – bend to API processes or human modifications that can override the formula contingent on the data values, etc.

Presently none of these behaviours is possible with formula fields; they are rigid little clumps of business logic that cannot fathom the idea that something other than their own logic may have something to contribute to that [faux] field’s ultimate value. This is a one-way street that railroads users into creating vastly more fields than typically needed.

If this alternate architecture were supported, it’s a pretty easy leap for a formula in field (a) to update a value in field (b) based on values in (a) or (b) and/or (n…).

There are ways to overcome some of these limitations in Airtable but they require around-the-barn travels and some of the barns are the size of Liechtenstein. You don’t have to search very far in the forum to see some wild workarounds and the vast majority of them seem to stem from formula fields as islands of logic that have no other place to write their results except on top of themselves.

In FileMaker, the formula field is actually called a “calculation field”, and they refer to its logic as the “calculation engine”.

At the beginning — for the first 19 years of FileMaker Pro, this “calculation engine” (“formula engine” in Airtable’s terms) was restricted to ONLY the “calculation field” (“formula field”).

So, for 19 years, we only had one field type (“formula field”) that could perform formulas with the “formula engine”.

But then, they start rolling out the “formula engine” out to many other parts of the product — and it even evolved alongside a “scripting engine” (FileMaker’s version of a scripting language). So now, the “formula engine” and the “scripting engine” power all sorts of amazing things in FileMaker. You can do nearly anything in the product with both the “formula engine” and the “scripting engine”.

But keep in mind that FileMaker is a product with a 35-year history — it came out in 1985. So it took a while to get there.

So I think that in due time, we will see Airtable’s “formula engine” get rolled out to other parts of the product. We’re already seeing this now! :slight_smile:

How exciting that we now have a brand new part of the system — the button field — that taps into this “formula engine”! :slight_smile:

And soon, we wil probably see this “formula engine” rolled out to other parts of the product as well! And I’m even hoping that they introduce a simple “Airtable scripting language” that doesn’t require learning JavaScript, which is daunting to many.

So, in my opinion, rolling out the formula field to other parts of the system is just the beginning of great new things that are in store for Airtable! :slight_smile:

But these things happen slowly over time.

Yep, I recall this vividly. I was at the 2012 FileMaker DevCon in Miami when they finally understood and announced that formulas should not be tightly bound to a special type of field. It took them until 2012 to fully unwind this design choice.

At best, I only have two decades left on this planet; they need to step it up. :wink:

Yeah, but no company should feel like they have 35 years to figure out anything and despite it’s long and storied heritage, FileMaker has and continues to struggle. Apple is likely part of the problem. I have a good friend - employee #5 at Claris so the memories, while distant, underscore why it’s good to learn from history.

What would be less daunting?

True, I was referring to that REST API. I seldom see the Scripting block’s API referred to as “the API” or with any “API” reference at all, so I typically interpret any reference to Airtable’s “API” to mean the REST version.

I don’t think that they are — or ever have been — struggling. FileMaker is perhaps the most powerful cross-platform desktop & mobile database at its price point — with an almost unlimited ability to do nearly anything you want within its programming language. FileMaker’s sales grow every year. And they keep expanding its capabilities every year. And they continue to add tools to make it easy to communicate with other platforms as well. It’s insanely powerful.

Anything easier than writing lines of code from scratch! Airtable knows how to make things easy — they’ll figure it out. FileMaker has a beautifully simple & easy scripting language — yet its power can be unleashed if you want to unleash it.

We’re probably boring these poor forum readers to death by now, so I’ll move this to a message.:wink:

Shucks. I never find your posts boring.

But, it would be nice if someone with moderator privileges could spilt this thread in two as the discussion has taken quite a shift from the original intent.

1 Like

I think that learning any computer language can be daunting for someone who has never coded before.

Airtable already has one computer language that it has to support–formula functions. Even though formula fields have a small vocabulary and simple grammar, you feel that the documentation is inadequate. A another full blown scripting language would require even more documentation and training material.

I think that sticking with an existing computer language, such as JavaScript is a smart thing to do. There are tons of free resources for learning JavaScript. There are also tons of resources for coding in JavaScript, such as editors that already know the JavaScript grammar. Plus lots of people already know JavaScript.

If Airtable wants a model for how to bridge the gap between no code and code, I would rather see different tools instead of a new language. For example, a tool could ask a few questions about what the user wants to do, then spit out code that performs that function. Another tool could record a user’s actions and then translate those actions into code. Then the user could run, examine, and adapt the resulting code.

I would be highly surprised if Airtable wasn’t working on their own scripting/automation processes for their platform — at least for some of the most common use-cases. This seems like what the “button field” is leading towards in the future — building automations into the platform in a very user-friendly manner. I’m super-excited about this new button field, and what it means for the future.

The Airtable people are smart enough to realize that 99% of their users don’t know how to write JavaScripts & don’t want to learn JavaScript. Their users are not coders, which is why the entire Airtable platform is based on simplicity & ease-of-use. Airtable’s user-friendliness is why so many people love Airtable so much, and what makes Airtable so much fun to use!

Airtable is a joy and a delight!

1 Like

@kuovonne, @ScottWorld - I’ve tried to respond to your comments but apparently I’ve been banned from the community - everything I send is rejected as inappropriate, even direct messages.

I think that posts getting hidden or “waiting for moderator review” is an automated thing that happens occasionally… not sure why… maybe some keywords or external URLs that trigger it. Those posts almost always seem to get approved by a moderator later.

I’ve seen those - this one seems different:

Your post was flagged as inappropriate : the community feels it is offensive, abusive, or a violation of our community guidelines.

Sorry to beat this dead horse, but… @ScottWorld asked for examples and yet another - one that I did not anticipate - has emerged in the past 24 hours. :wink:

Throughout this thread, many have questioned my disdain concerning the nature of formula fields (and now button fields). Here’s another example of dysfunction where a user who is blocked from a natural and intuitive approach for placing a link into a PDF document that is actually clickable.

If formulas could be expressed as attributes of [real] fields, this challenging issue would not exist and the user would not be forced to write script to achieve his objectives.

There are many examples in the forum where roadblocks like this one have been documented and in almost every case, they stem from the underlying design choice concerning hybrid fields.

The pattern we see in forum threads like this one is common and almost always related to the unanticipated constraints of formula fields. Soon we may see a similar pattern emerge with button fields as we encounter the unpredictable roadblocks that hybrid fields make possible.

Where would you put formulas that rely on the values of multiple fields?
Such formulas need record level scope, and cannot be stored in the field definition of one of its underlying fields.

I would like to see more robust formatting options, which might be similar to want you want, but from a different perspective. For example, URL fields could have two values: a label and a url, then it could have formatting options to display the label, the url, both (in markdown format), clickable button, or any combination of the above.

You sort’a answered your own question. :wink:

A field with a formula [attribute] is architecturally no different than a field with a formatting attribute. The formula would have the ability to reference other fields and in the context of the current record - i.e.,

thisRow.Value = thisRow.{fieldName1} + thisRow.{fieldName2}

With that, you should also be able to envision …

thisRow.Value = getRecord(<recordID>).{fieldName1} * thisRow.{fieldName2}

And by logical extension …

thisRow.Value = getTable(<tablelName>).lookupRecord(<fieldName>, thisRow.{fieldName1}) * thisRow.{fieldName2}

Formulas applied to any given scope – column or record should be possible.

Indeed, and that’s why any formula defined at the field level must also have dynamic access to record-level data.