The concepts might be vastly different to Airtable staff, but to users they’re both just ways to extend Airtable functionality. It’d also be an opportunity to rethink the right side-panel design.
Fair point. I agree that this is a delicate line to walk. However, the home page mentions nothing about script, script blocks, or anything remotely programming-related. Instead - and I think this is why it has been so successful - it’s a very kind and gentle intro that leads any viewer to conclude - I can use this. As such, it’s likely appealing to the code-free customers, and that’s fine; that’s why we’re all huddled around this community. :winking_face:
The first glance at the community page, however, is a bit different - Custom Blocks development is prominently featured. It feels like a little windshear at play and could be confusing to some.
Please don’t misinterpret the spirit of my comments; I have been pushing for ways to overcome code-free weaknesses for years and now they’ve put out a really good pathway for deep integration, automation, and very flavorful customizations. Plenty to celebrate.
@Zollie made a good observation that I agree with; the nomenclature and organization of code-related features is still rough on the edges.
learn new skills (like coding) *instead of saying “whoops you gotta now pay someone else to do it for you!” everytime a use case gets a little spicy. @Kamille_Parks
But if the answer to “can I do this in Airtable” genuinely is “not without some code” then dancing around the issue isn’t going to help the people who need that solution @Kamille_Parks
Dang on point. You make a great case for an intertwined coding skill-level experience.
I think most people are understanding that you pay for the more advanced features for any app. @Kamille_Parks
Some people may now choose Airtable because the ability to have a custom block or run a custom script now exists. @kuovonne
These quotes ring especially true for engaged users or those that make purchase decisions. But fringe users, that are disengaged, confused, or reluctant to use the platform can drive retention issues.
This also might be a bit of a conversation about breaking through anchored UX expectations. “Where are the add-ons? What’s a block?”, “Where’s the development environment?”
Anyway, given the mixed thoughts here, maybe Airtable should continue going wild but keep reigning it in on the back of the mind?
A loose product roadmap would make the discussion here more fruitful. For all I know, next month there’ll be another beta for some other "Script-"something. As it stands, I think exploring a consolidation of the Scripting Block and the Script Action Beta would help alleviate some confusion around similarly named product features.
Also if anyone’s interested, I just found this recent podcast episode with Howie Liu describing Airtable and their kind of position in the no-code/low-code/some-code market. Worth a listen:
This has been a fantastic conversation to observe :slightly_smiling_face: The battle airtable legends (or rather healthy and respectful discussion). I am grateful for all of your active contributions to this community!
+1 for integrating “add-ons” in the same space :slightly_smiling_face:
Ha ha - indeed. This is a perfect example of discourse to advance the science and understanding of Airtable.
I think @Katherine_Duh and Airtable should host a webinar once a month called Point-Counterpoint (a throwback to the SNL segment of the 70’s, but with kindness and respect, of course). Feature two Airtable users with differing viewpoints. It would be fun, a good conversation, and a little side vote widget to gauge audience sentiment on each topic.
Welcome to the community, @Ng_c_Han_YouTube_ok! :grinning_face_with_big_eyes: You didn’t leave any comments with your base link, namely how this may relate to the topic of this thread. Would you mind sharing further details?
