Double Click on Field Name - Restore Customize Field Functionality!

[Paul_Warren1]

Hello Airtable, Please, please please reverse this change!

Double-clicking on the field name now only modifies the name of the field. It is a pain to have to right-click to access this menu. I don’t want to be overdramatic and claim this will totally ruin Airtable, but it’s much less efficient than the old method.

I also noticed that when creating a new field, the field type is now the first dialog. Then we are prompted to put in a name. This is fine and I can get used to the new workflow. I understand that this reduces the number of times I use “Tab” to move between dialog boxes.

I love Airtable and hope it continues to make progress! Just not the progress I don’t like :stuck_out_tongue_winking_eye:

[Bill_French]

Here are just a few more comments to balance the discussion. :winking_face:

ScottWorld:

I don’t know the inner workings of Airtable as a company, but it seems like each engineer is independently working on their own “pet projects”.

I have no inside track at all with Airtable but this is clearly not the case. It may seem that it is, but I’m almost certain it’s not and you’re getting these sensations from anecdotal experiences at best.

Airtable could not achieve the level of platform work associated with a specific individual or even a small team. Read this documentation and just imagine the coordinated effort that their entire company had to engage in to make this stuff work. Furthermore, it works well, and it’s highly performant. And, for the most part, there are no disconnects with the product features. This is not easy to achieve.

ScottWorld:

I’ve never heard anyone complain about confusion in creating/customizing fields

This is an absolute fact if we can consider the community as a deep representation of customer sentiment. In fact, I searched my ElasticSearch index of the entire community for the past five years and only 6 instances where UI issues concerning field creation popped up and they were unrelated and/or user errors.

If we can use the community data as evidence, the user base seems to have had zero issues with the way it previously worked. I get it - sometimes changes are required in advance of new features, but if that’s at the root of this change, it should be clearly communicated and rolled out in concert with some clear roadmap content explaining why this was necessary (e.g. Apple Lightning Cable - people wanted thinner phones; lightning made this possible).

ScottWorld:

There are TONS of things — both small & large — that people HAVE been complaining about for years, and they continue to go ignored by Airtable.

This is undeniable as well and the data in the community messages prove it. What’s the status of my pet peeve Split()? :slightly_smiling_face: Been asking for it for three years. Needed by almost every user for 7 years. It’s a weekend task for a junior-level engineer. [sigh]

ScottWorld:

There doesn’t seem to be someone who is acting as a product visionary or a product leader or a community engagement person.

@ScottWorld is right again and I rarely agree 80% of the time with him about anything.

Airtable needs a face of technical leadership; one mind, one face, one presence that is fully apprised of all things product management. A liaison who works tirelessly to triage issues and convey them to development while carrying back knowledge from the dev team to the community. There are people in this community who try to help Airtable do this - some are at it 7 days a week without any compensation. Where’s the equivalent Airtable resource that can engage at this level of technical competence while getting a fat paycheck and working as hard as some of your aftermarket developers?

[ScottWorld]

Bill.French:

I have no inside track at all with Airtable but this is clearly not the case. It may seem that it is, but I’m almost certain it’s not and you’re getting these sensations from anecdotal experiences at best.

I should have said “each engineering team”. I was told by an Airtable employee that each engineering team has autonomy to work on their own projects, and there is very little communication between teams. I was also told that there is no overall “product manager” overseeing Airtable. Each team has a product manager, but there is nobody overseeing the entire product. The CEO has always acted as the “product manager” up until now, but I suppose that he’s primarily busy trying to raise more VC funds.

All of this would perfectly explain why Airtable is such a dysfunctional product. For example, it would explain why button fields can’t trigger automations, or why Page Designer can’t be automated from anywhere. I mean, there are hundreds of example, but these are just 2 that popped into my head. It would also explain why features get released ONCE and then are left to sit idly & gather dust forever after that. (It might even explain why we unpaid volunteers who are here 7 days per week helping people for free know more about the product than many of their paid support agents do. It seems like each support agent is on their own to learn the product.)

Bill.French:

Read this documentation and just imagine the coordinated effort that their entire company had to engage in to make this stuff work. This is not easy to achieve.

I disagree. For example, Filemaker is a multi-billion dollar company owned by Apple, and their excellent database product is an enterprise-class product that helps run some of the world’s largest companies. Yet their documentation is written by a tiny team of people. I don’t know the exact number, but I’ve heard that it’s less than 5 people handling all of the documentation. In other words, the documentation people at a company are required to engage with all the engineering teams, but that doesn’t mean that teams are engaging with each other.

Bill.French:

@ScottWorld is right again and I rarely agree 80% of the time with him about anything.

Lol!! :joy: I agree with everything else you’ve written above!! You totally nailed everything else.

[andywingrave]

Could not agree more with the comments here! Especially @kuovonne’s ideas around categories.

I’m kind of at a loss for words as to why we are still talking about this nearly a month later.

[ScottWorld]

andywingrave:

I’m kind of at a loss for words as to why we are still talking about this nearly a month later.

Because this bad change is still in the product.

[andywingrave]

Haha! Absolutely - I mean…Why is it still in the product :rofl: :grinning_face_with_sweat: :joy: :joy: :cold_sweat: :disappointed_relieved: :cry: :sob: :sob: :sob: :sob:

[kuovonne]

andywingrave:

Why is it still in the product

I hope it is still this way because there is a better solution that is still in development.

[Bill_French]

ScottWorld:

Yet their documentation is written by a tiny team of people.

I know - I worked with that tiny team in the late 90s; and it was just two people then. (yes, I’m that old)

But I’m not referring to the documentation. I’m referring to the underlying platform - a complexity so vast (as exhibited by the Blocks SDK documentation) that your initial assertion was likely in error. The platform is demonstrably far more complex than a group of freewheeling engineers or a collection of unguided engineering teams could create.

I understand you put a finer point on the “individual developer” nuance. Bottom line - you cannot paint their teams or their underlying accomplishments with a broad brush stroke; they are communicating [with each other] in many ways and the evidence clearly shows this.

As to the other calamities, you are quite right about all your assertions. I’m anxious to learn about what @kuovonne is alluding to.

[ScottWorld]

Bill.French:

In fact, I searched my ElasticSearch index of the entire community for the past five years and only 6 instances where UI issues concerning field creation popped up and they were unrelated and/or user errors.

This is brilliant to be able to look at this sort of data, and know that almost NOBODY has ever had a problem with the field customization process. ALMOST ZERO.

Yet, we’ve had hundreds of people — perhaps thousands of people —perhaps MILLIONS of people :winking_face: — who have had problems with using curly quotation marks in the formula field! And Airtable can’t make their formula engine accept curly quotes?? Or, at the very least, Airtable can’t give users an error message that says “Sorry, the formula engine only accepts straight quotes.”??

This is a great example of the mis-prioritization that is happening with Airtable. So frustrating.

@Zoe_Bridges

[kuovonne]

Bill.French:

I’m anxious to learn about what @kuovonne is alluding to

I wasn’t alluding to anything. I was merely honestly stating that I really hope that they are developing something better. Many people complained about the view sidebar testing and there seemed to be little progress until suddenly the current sidebar design appeared, a new design that actually incorporated features suggested by this community.

I think that there is room for improvement in how to create and customize fields, although I won’t attempt to say how it should be prioritized. Anecdotally, I have seen new users intimidated by the array of field types.

I also think that there have been more than 6 instances where field creation and configuration issues have cropped up on this forum. For example, I have seen several issues relating to the fact that formula fields that show numbers default to displaying integers, but actually retain the decimal behind the scenes. Percent field types display as percents by are stored as decimals, which also causes unexpected results when they are used in formula fields. There are numerous issues that crop up related to time zones and local vs. gmt time for date/time fields. People, especially those with database experience, continue to be confused by how linked records work. Issues with lookup fields continue to plague people, and sometimes the solution is to use a rollup field instead. Are url and email fields actually different from single line text fields? I find myself often converting single line text fields to long text fields, not because the data is long but because I prefer the user interface for single line text fields There isn’t a json data type field, but using a long text field works just fine. Should there be a dedicated json field type anyway? There is no location field type, but people have been storing location data and have to decide what field type to use.

Of course, none of these issues relate to the order in which the field name and field type are chosen, which seemed to be the focus of the current testing.

Oh, and to throw out another suggestion @Zoe_Bridges, please think about putting the field description and field-level permissions on the field customization screen, perhaps on different tabs?

[Bill_French]

kuovonne:

For example, I have seen several issues relating to the fact that formula fields that show numbers default to displaying integers, but actually retain the decimal behind the scenes.

It’s difficult to write a query in ElasticSearch that will expose these nuances. My search focused on the key topic of creating fields looking for the keywords that @ScottWorld described in his initial comment.