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.
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.
Sure it would be frustrating to learn their use case would require some coding, but Airtable’s website and their app store descriptions don’t call their product “no code” anywhere on it that I could find. Now, everyone else under the sun calls Airtable “no code,” but Airtable actually markets itself as “flexible” and “for everyone.” People who capable of working in Javascript/REACT count in “everyone.” If Airtable really wants to be for everyone, it can leverage its general user friendliness as a place for people to 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.
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.
Yes, precisely. As I said, it’s an added conflicting element of [market] positioning. But, if the first thing you see in a support community is the idea of building custom blocks using React/Javascript, your general positioning is a bit off the rails.
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.
