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.
Can you explain your idea a bit more? A custom block can already re-render itself whenever a new record is added (in general, or added to a particular view). I assume you’re asking for something else, can you expand on it?
Sure thing. There’s a good chance I’m missing a longer roadmap, but at the moment I’m asking myself, to a new user, what’s the difference between a Block and an Automation? It seems like a bit of a fuzzy line at the moment. Could Automations just be a Block? Or should the Scripting Block be integrated into ‘Automations’ and the two sections remain separate? Guessing most new users will just want to know where to look for the stuff that isn’t a part of the obvious interface (the grid). Does that help?
I agree; @Zollie makes a good point and there is already a collection of nuances that are undeniably confusing to new and even long-time users.
Currently there are three types of script blocks:
- Script Block
- Custom Block
- Action Script
Wait a second - what? Script Actions cannot call Script Blocks?
Ideally, action scripts would have simply been Script Blocks with event and time-trigger functionality. Airtable should seek to merge these (#1 and #3) and I realize the technical implications, but it is a complexity that should not be in the users windscreen at all.
Custom Blocks should not be discussed openly with general users; rather, this should be part of a developer partner relationship and possibly in the same context as the REST API. Any blending of commentary - even subtle mention of custom blocks - with the general user base is ill-advised. Why? Because they came here for a no-code experience and while Script Blocks and Script Actions are the opposite of no-code features, Custom Block development is in the stratosphere of software engineering.
Ironically, as a leader in the codeless revolution, Airtable now has a positioning challenge; how do you make all this scripting crap (said lovingly) fit together like a nice puzzle that even non-technical people can understand.
Yes, that too is exactly as you say @Bill.French !
I could see the value of having the Script Action beta folded into the Scripting Block. One possible means would be to add the “trigger” selector to the Scripting Block’s settings. An issue which may arise is handling the script being triggered while its already running; if the Script Block is able to have a queue that may alleviate the problem.
Another potential issue would be if the script in question requires user input and it is triggered automatically when no one is around to provide it. In that case, perhaps the block would disable the
input.x components if a trigger is defined, and there’d be a way to define a fallback/default value for those inputs to use when run by a trigger.
As a side note: I believe the “don’t even mention custom blocks near a general user, that’s for ~developer~ eyes only” ship sailed when Airtable announced its very public contest for the feature right here in the exact place general users go looking for help lol
Yeah, there are probably a whole host of issues that might make a product team groan at an idea like this. But inevitably I think there will come a point when some of these similar ideas should be consolidated and simplified.
that’s for ~developer~ eyes only” ship sailed
Agreed. Not sure if that’s for the best or not. It certainly would be frustrating for a “no code” user to find a feature then realize it requires a bit too much from them. Then again, maybe that makes for an important moment where no code users take the leap towards coding. I definitely think of them as separate buckets - development over here, super users over there. But maybe that’s an overly traditional mindset.
I personally see the most value for Airtable to be a really good “low code” solution. It does what most general users want it to without custom blocks, scripting, or the API. Seeing as how both the Scripting Block and Custom Blocks will probably eventually be “pro” features anyway, I think most people are understanding that you pay for the more advanced features for any app.
That’s a marketing issue. And there may well be plenty of users who come to Airtable for other reasons that are not the no-code experience. Some people may now choose Airtable because the ability to have a custom block or run a custom script now exists. Those features might close the gap that was previously preventing them from using Airtable.
I also think that the general public should know that custom blocks exists. How else will people decide if they want to take advantage of it? If a company needs a custom solution, it might very well be more affordable to pay for a custom Airtable solution than to build something from the ground uo.
To be clear, I’m not advocating an “eyes only” suggestion; simply saying that most vendors of consumable software products tend to corral such capabilities around a developer relationship so that developers feel welcome and new users aren’t overwhelmed with techno-speak.
Then again I must point out that, from what I’ve seen, Airtable does not actually market itself as either a “no code” or “low code” solution. Like, TechCrunch is going to call it that, and again it is very clearly in that sector of the market, but Airtable breaks no promises to anyone by having a prominently featured coding component.
If your concern is that we here will start to recommend a custom block or a script for every or even most use cases we come across where they are not necessary, I am not as concerned about that possibility. 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, and its certainly not going to help all the developers here who get paid to provide those solutions.
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.
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 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
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.
psssst. @Jason, that might be a good way to get feedback about beta features
Welcome to the community, @Ng_c_Han_YouTube_ok! 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?