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.
I do not at all agree. I don’t want to tiptoe around every field in a database to not accidentally click a link to somewhere or start some process. What other database program works like that, where literally every possible field might also be a “button” of some sort? That sounds like an absolute nightmare UI/UX experience to me.
I’m not suggesting every field be a button; nor am I suggesting that click actions override every (or any) field cell. I’m suggesting that there are use cases and situations where a button action would be useful in the context of field data and in most cases in a contextual menu option.
As it stands, a button field that impacts a specific existing field must be a separate field in Airtable. I believe there are many cases where the action of any given field should not require the addition of yet another field. This is no different than how formulas work in Airtable – for every field that is dependent on a formula, another field must be created. This leads to complex data schemas and confusion. How much simpler would most Airtable apps be if formulas for any field could be joined to the fields they actually impact?
Qckbase, Misoft A*ess (may it rest in peace), rhymes with SmileBaker Pro, … etc. :winking_face:
FileMaker is a good example of a program that allows you to turn any field — or any other element on your entire screen — into a button. And you can draw your own graphical buttons completely freeform anywhere you want on the screen.
But — here’s the thing — FileMaker gives full 100% design control to the user, which Airtable doesn’t allow. So I think it kind of makes sense for Airtable to have a “button field”. Even though a button is technically NOT a field, it sort of makes sense within the “design constraints” of what we’re allowed to do in Airtable.
You are right, Bill — a button is technically “added functionality”, not an “additional field”. But I think it’s okay within the design constraints of Airtable.
It’s kind of their own unique twist on things, actually. Airtable does get a little “flexible” with their terminology & functionality from time-to-time, but I’m okay with it because they’ve got their own way of doing things that make sense once we get used to it. They’re sort of reinventing things with their own unique spin.
With the new button field, I don’t really see this as a downside. It fits nicely into what we’re already allowed to customize in Airtable. I bet at some point in the future, they’ll give us new “interface layers” & “design layers” that we can work with, but for now, adding buttons into fields seems to work quite nicely.
I’m really super-excited to see how the button field evolves in the future, and I don’t really see any downsides here.
But sometimes, Airtable’s little unique twists DO come with a few downsides. For example, Airtable Support told me that they consider “creating new fields” and “deleting fields” as part of “data entry”, which of course is not technically correct. Creating new fields & deleting fields is part of the structure of a database… that’s not part of the data entry of a database.
So this is why even after you “lock” a view in Airtable, any collaborator can continue adding brand new fields onto your “locked” view. (Similarly, editors can completely delete fields from your entire base — right from a locked view!)
So locked views are not truly “locked”.
To me, this is a downside, because any collaborator can completely modify the “locked” view by creating new fields right on the locked view itself. (And any editor can also remove fields from the “locked” view by deleting fields — directly from the locked view itself.)
But overall, I’m just thrilled to see so many improvements & new features & new functionality in Airtable! Especially all the major improvements in just the last few months! :slightly_smiling_face: I’m also thrilled that Airtable employees are engaging with us so much here in the community forums.
Overall, I’m just so thrilled about Airtable as a platform for the future. I love the direction that the platform is moving in! :slightly_smiling_face:
I personally have no problem calling this new feature a “button field”. Right now, we have a “run” button in Scripting block, but its scope is the entire base. I really like the idea of a button a the record level, because then its scope is just that record. So many times someone wants to take an action at the record level. Given the current user interface, I don’t see anywhere else to put a button in the record scope other than in a field.
As for turning other fields into buttons, all fields are interactive at some level, but that doesn’t make them buttons. However I think developers need to tread carefully when overloading fields with too much functionality–it gets too confusing. Even having only two features per field (a stored value and formatting options) things can get confusing. While I would like a lot more robust formatting options, I am leery of adding a actions to existing data fields in the grid view. Save that for other things, like custom blocks.
The most direct comparison to be made with the beta is still Cda’s button columns. FileM is really different from AT, I don’t see that its possible to implement what you’re saying the way they do it, same with Qbase.
In Microsoft Access, a user can create a view in which every single thing (field, background, plain text, images, etc.) can trigger actions. In fact, they could trigger different actions for a click, double-click, right-click, keypresses, etc. This can lead to some very sophisticated user interfaces that resemble full fledged programs. But just because someone can attach actions to multiple events for multiple objects doesn’t mean that they will. It is up to the developer to create a reasonable user interface, just as it is with any other app developer.
I get the examples now, what I was trying to get at was reconciling that functionality with AT’s design without breaking it. Access, FileM, etc. have very different user interfaces in order to accomplish things like that. It just doesn’t seem compatible to me.
Indeed, and Airtable can never really truly lock the view from data schema changes because the definition of “fields” is so ambiguous that it includes controls and actions. Locking the schema means locking many of these cherished and necessary features which - as designed - will be difficult if at all possible to separate.
I’m not so concerned that fields of type:action are mixed in with fields of type:data. My concern is the path that this sets the entire future of Airtable on. Imagine how complex the underlying code will become as enterprises insist on schema management features and other mature data management requirements which must also deal with tightly dependent UI bindings.
This is a feature implementation pathway that tightly binds UX with schema and I think it may paint us all into a corner as Airtable matures.
Even the founder of Cda and other Cdans have openly admitted the button field is a risky solution to overcome a key architectural shortfall.
In my old-person (deep legacy) view, fields are all about data, and actions are attributes of fields. A good example - a field of type:selector has a built-in action that is separate and apart from the field’s data. Underneath the action, there is data. It can be filtered, locked, sorted, etc. A button is an action without data which makes me ask - why would it qualify as a field?
To all who have shared great insights concerning my observation, I thank you for pushing back because — at worst — this dialog may inspire some thought about better ways to enhance the already delightful UI/UX of Airtable.
