Currently you can execute a scripting app from the desktop version. Much of our data entry is done through the mobile app and many of them are complex and take many taps and entry into many fields. This can be steamlined quite a bit with scripting apps.
The ability to execute a scripting app from a button on a mobile device the way you can on the desktop version
+7
Much of the battle to create smart [mobil] solutions is design-related at the data model level and automation workflow. Eliminating taps and fields in processes that sometimes require interpolation and late-binding to save users time, is very difficult and especially so when using mobile forms that are incapable of smartly detecting how to present smart requests to users.
As I mentioned here, there are many reasons why scripts – at the edge – are unlikely to emerge in Airtable’s mobile client. In my view, Airtable should fear doing this.
And to be clear, asking edge users to run scripts, or burdening edge clients to smartly run automation processes that are based on scripts, doesn’t really make your solution better. In fact, it will likely make it worse.
Imagine you have an outside sales force of 20 people running the Airtable mobile app with a collection of scripts to aid their productivity. You discover a bug and need to make a change to the script. How will it get deployed instantly and ensure refresh across 20 mobile clients? This is just one of many issues that will bubble up when trying to enforce business logic in a distributed architecture at the edge.
On that axis alone, it probably makes sense for edge clients to be able to invoke scripts that are server-based using a means of indirection. But this is possible now if the solution is designed well.
+7Bill_French wrote:
Much of the battle to create smart [mobil] solutions is design-related at the data model level and automation workflow. Eliminating taps and fields in processes that sometimes require interpolation and late-binding to save users time, is very difficult and especially so when using mobile forms that are incapable of smartly detecting how to present smart requests to users.
As I mentioned here, there are many reasons why scripts – at the edge – are unlikely to emerge in Airtable’s mobile client. In my view, Airtable should fear doing this.
And to be clear, asking edge users to run scripts, or burdening edge clients to smartly run automation processes that are based on scripts, doesn’t really make your solution better. In fact, it will likely make it worse.
Imagine you have an outside sales force of 20 people running the Airtable mobile app with a collection of scripts to aid their productivity. You discover a bug and need to make a change to the script. How will it get deployed instantly and ensure refresh across 20 mobile clients? This is just one of many issues that will bubble up when trying to enforce business logic in a distributed architecture at the edge.
On that axis alone, it probably makes sense for edge clients to be able to invoke scripts that are server-based using a means of indirection. But this is possible now if the solution is designed well.
Hi Bill,
As always thank you for your insight. I agree with you on all these points. Mostly I don’t the time to develop a mobile app and am always looking for ways around it. I think in this case I may have found a hook that will work for this specific workflow. Using a button that will call my nodejs back end should work. I already have the code in place to work with airtable via the api. I can then use react to put up a very simple html page to capture the minimal data. This will put all the heavy lifting on my server and should do the trick. Time will tell.
Reply
Most helpful members this week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.