Help

This Product Ideas board is currently undergoing updates, but please continue to submit your ideas.

URL--Text to Display Feature

cancel
Showing results forย 
Search instead forย 
Did you mean:ย 
Samantha_Allema
5 - Automation Enthusiast
5 - Automation Enthusiast

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.

163 Comments
Kamille_Parks
16 - Uranus
16 - Uranus

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.

Bill_French
17 - Neptune
17 - Neptune

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:

Kamille_Parks
16 - Uranus
16 - Uranus

(post withdrawn by author, will be automatically deleted in 1 hour unless flagged)

ScottWorld
18 - Pluto
18 - Pluto

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:

kuovonne
18 - Pluto
18 - Pluto

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.

Kamille_Parks
16 - Uranus
16 - Uranus

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.

kuovonne
18 - Pluto
18 - Pluto

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.

Kamille_Parks
16 - Uranus
16 - Uranus

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.

Bill_French
17 - Neptune
17 - Neptune

@ScottWorld raises a key point โ€ฆ

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.

Bill_French
17 - Neptune
17 - Neptune

As do I. That part I get and I agree with this observation. The implementation approach is what I think may be problematic.