I suspect implementing such a beast would fly in the face of a number of principles underlying design of the Airtable platform.¹ Like lawn darts, bigotry, and Sansabelt slacks, In 2019 full-container (screen or iframe) refresh is considered démodé. (Even at the height of its popularity, it was only slightly better-received than the <blink> tag: an improvement over mindless pounding away at the ‘reload’ button only in that it kept others from seeing you do so.) Today, there are far more acceptable methods for updating the screen, designed to transfer only those data that have changed since the previous update. Most involve some sort of subscription to or registration of elements of which one wishes to be notified of changes. (Unfortunately, that suggests information is contained in a sequence of element states that can’t be discerned from a single state in isolation, which flies in the face of other generally accepted principles of application design…)
The problem is that not only are element-level notification schemes far more difficult to design than is a brute force refresh of the entire container, their successful implementation assumes deep familiarity with how the product is used — familiarity that may be a little difficult to acquire if one is busily assembling the initial release.
Consider your use case: When a task’s execution time expires, if the task record is contained in the currently active view, you want it to reflect this state change. For that to work, here are a few of the issues that need to be addressed:
- How to indicate which fields trigger updates? (‘Indicate’ here has two possible meanings: How the user informs the client, and how the client informs the server. Unless otherwise noted, moving forward it’s safe to assume there are at least two components to each issue raised.)
- At what granularity should the system check for updates? Presumably some sort of sweet spot exists that balances responsiveness and overhead: How is it to be determined? Validated? Re-evaluated?²
- What throttling or clamping mechanism is needed to protect Airtable servers and bases?
- How does one determine which is the current app and view?
- Equally importantly, if the record exists in the current view, how does one determine if it is part of the current viewframe?
- If the record is not visible in the current viewframe, what behaviors should be exhibited upon record update? Record updated by not displayed? Record updated and viewframe shifted so that record is center-most within the frame? Top-most? Bottom-most?
And those are off the top of my head; undoubtedly several times as many would emerge from any serious design brainstorming session. Furthermore, these are issues that arose in isolation; no doubt additional concerns will emerge when element updates are considered in conjunction with other existing or desired functionality.
It should come as no surprise, then, that Airtable’s first incarnations chose simply to ignore most instances of element update: To do otherwise would have required a depth of information on user requirements, methods, and practices that simply doesn’t exist for a product in initial deployment. Unfortunately, acquiring the data and experience necessary to address such concerns only makes it possible to address them; it doesn’t make them any easier to address.
Ultimately, I am of two minds when it comes to the possibility of Airtable implementing a built-in container refresh function. On one hand, it would allow a more smoothly integrated refresh mechanism than is possible through a browser plugin. (Simply being able to refresh only the innermost relevant container would greatly improve the overall user experience.) If nothing else, javascript-based refresh would be cleaner, more easily configured, and provide more options than meta refresh.
At the same time, though, resources directed towards screen- or container-based refresh are resources not brought to bear on the actual endgame: element-based refresh. At best, they represent wasted cycles; at worst, by implementing methods or functionality that conflict actively with their element-based equivalents, they could end up delaying the final product by more than merely the amount of effort diverted.
Finally, there are reasons to establish and adhere to overarching principles of architecture and design that go beyond simple gains in efficiency. It’s one thing, as creator and architect, to convey its intended design to the engineers and developers tasked with building it; do a good-enough job communicating the detail, and the final product could end up a lot as you had imagined and perform to the full extent of your ability. Manage to inculcate a vision of the product, on the other hand, and you may find your grasp can exceed your reach. With a shared understanding of not just the goal but the reasons and methodology underlying it, you can unlock the potential for synergy, the team’s capabilities as a whole outstripping that of their combined strengths. Start tossing in caveats and exceptions, though, and it becomes much harder to sustain such a common vision.
That said, though, I’m with you on this request: Seemingly, everything needed to implement a safe and streamlined container refresh function already exists in the Airtable libraries; all that are missing are table- or view-level configuration options to enable refresh and specify the interval between refreshes. This strikes me as low-hanging fruit unlikely to cause a tummy-ache, and I hope Airtable seriously considers its implementation.
Vann
- This assumption is not based on my having hacked into Howie’s laptop, surreptitiously photographed whiteboards after hours, or dumpster-dived in the alley behind 799 Market. Instead, it comes primarily from my understanding of best practices in application architecture and design at the time Airtable was developed and how the current product behaves, secondarily from occasional dives into the application’s javascript library.
- It’s essential, with such an app as Airtable, regularly to revisit one’s initial metrics and assumptions, as users are a notoriously unruly bunch with the exasperating tendency to use a product as they see fit, rather than as one intended. Even minor changes to the predicted use case can result in significant increases in resources and bandwidth required. For instance, I’ve wondered for a while whether Airtable’s data forwarding parameters may need fine tuning, as they appear to fire too easily. This can most easily be seen while entering data into a field referenced by a calculation also visible in the current view. Often, the formula recalculates after every keystroke, generating unnecessary traffic and degrading performance.
