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.
But which field name would you right-click? {fieldName1}, {fieldName2}, or something else?
I can see how this would be useful and would reduce the number of fields in a table. However, I’m not sure that I would like this in the basic grid view. It could easily cause user confusion.
The array formulas in the spreadsheets you linked to are intriguing. I’m not sure how that translates to a relational database model, though. I need to take a look at Hoda, but I just don’t have nearly enough time right now.
I think that the lines between data and business logic are getting very blurry.
In the recent examples presented, field1 and field2 are not the fields where the formula exists; rather, they are fields referenced BY the formula.
Wherever there is a field, I think it makes sense to have the ability to apply attributes, and attributes should include many things that fields are capable of including but not limited to:
Field name
Description
Data type
Conditional and default formatting
Grid validation rules
Form validation rules
Security rules
Formula
Formulas - like all field attributes - should affect the field whose attributes they are defined in. Ergo, while you might use a syntax such as:
thisRow.thisCell = [expression]
You might also want a shorthand version of the syntax:
= [expression]
Ha ha - yes, given the current limitations of field formulas, it is very different. But I think you’re getting hamstrung by my lack of expressing this idea more simply.
Let’s try these words to express my idea …
Imagine everything that Formula Fields do now - but in the context of actual fields. Why is that confusing to users? They write a formula that populates every cell in the column. It’s a real field with a real value whose value is [OPTIONLLY or CONDITIONALLY] determined by an expression. What is so difficult to understand about this concept?
In the case of this example where the user simply wants to construct a cell value containing a fabricated URL - AND HAVE THAT VALUE WORK IN A PDF EXPORT - (and ALL OTHER CONTEXTS where fields now work) the solution would be this simple:
= {DomainName} & "/" & {docPath}
And to be thorough, the user did exactly this and expected the formula field to participate in the exported PDF document just as all other fields can participate and function as intended. Instead, he must go around the barn to effectuate a solution - he has to become a script author. That’s just dumb.
My observation is that hybrid fields (such as formula fields) are discriminated against by the underlying platform for reasons that we don’t understand nor should we care. That discrimination seems to occur because they aren’t really fields; they’re something other than a field in the truest definition. And because of this, they are barred from enjoying the first-class citizenry of actual fields. This - to me - is far more confusing for new Airtable users than the idea that actual fields could be influenced by a formula.
And this is typically one of the first stunning revelations for new users who come to Airtable from a spreadsheet background because it requires - wait for it - more fields than have ever been required in any other data-centric solution. It prohibits users from taking an existing column (i.e., field) and embellishing it with data through expressions.
This is about freeing formulas to exist in any field context. Button fields – I assert – are simply an extended pattern of this architectural discrimination. :winking_face:
[LAST POST: Thanks to all who have endured this narrative. Will someone in power, please - for the love of humanity - close this thread!] :upside_down_face:
Thank you for the detailed explanation. I think that I finally understand. Thanks for holding out until I could reach this point A text field could have an underlying formula. A url field could have an underlying formula. A number field could have an underlying formula. Thus, there would not need to be a separate formula field (at least in theory). I don’t completely agree with you, but at least I think I understand now.
