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.
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.