Airtable's Community frontend and UX

Thank you @ScottWorld !
Pretty awesome as you wrote !
I will pay attention to it before opening a next-to-come Community Forum at my main job !
olπ

Indeed, it is a pretty good app and the dominant forum leader globally.

And while the UI/UX is good, the API and the data that can be harvested from it is even better. In my day job, we use the Discourse API to gather data and create deep analytics and predictions. Anyone can access this data - that’s right, all the little messages, comments, and emoticons that ya’ll write every day are flowing into systems and ultimately become data points. :winking_face:

For example, this thread is also openly represented as JSON data by simply adding “.json” to the end of the URL.

When I need to search for something I said in this (and about a dozen other Discourse forums) I use an ElasticSearch app that indexes all my activity. It’s a seriously powerful productivity and data science tool if the data is aggregated and transformed into a full-text search system.

Now that Airtable has taken a step toward data science with Vega-Lite, perhaps I should demonstrate how to analyze all this text to understand user sentiment about all the features requested but never delivered. Airtable, of course, could not begin to handle the data, but it could present aggregations from the community.

The backend isn’t Airtable. According to the Discourse website, “The server side of Discourse is Ruby on Rails backed by a Postgres database and Redis cache.”

Hi @Bill.French,

Before my favorite side-job became to try to understand and then replay the best of the Community’s javascript, even and especially the little Expert’s tricks that do not appear at the first glance of a written code to fulfill a specific role, I had started data via Python, as you often quote it.

Although I had spotted this API on the Discourse site, I hadn’t jumped on it yet, not for lack of curiosity, but because I had prioritized my latest topics of focus that I’ve shared here recently.

this thread is also openly represented as JSON data by simply adding “.json” to the end of the URL.

:star_struck: Why can I not do the same with each of my Table / View ?!? Metadata and Data ?!? :thinking:
The ever-present question since I’ve been on airtable !

This seems to me the best way to do it in the current state of my experience: Elastic, which you often talk about here, seems to be the best way to index my own tables mostly populated with text provided by my job as a “researcher”: not a scientific researcher, no, but a researcher anyway.
I’ll also have to learn how to do this but I’ll start when I will become fluent in the javascript needed for airtable scripting, because everything I’m talking about here is only my side-job.

:hugs: Oooohhh Yeah !

-to be continued- but I should go to my main job now.
But this subject is huge, exciting, and should not be closed now.

olπ

Thank you @Justin_Barrett for bringing this to my attention!
I only realized it after visiting discourse.org and I hadn’t re-edited my question.
Have a nice day,
olπ

There are many reasons…

1. Security
2. A conversation thread - even the long ones - are not that big and a GET request can handle the conveyance of the data easily in less than 30 seconds (the typical server requirement for an HTTP response). Remember, all content is stored as JSON so there’s no effort to transform so the rendering doesn’t need to be done.
3. Databases require pagination - there’s no assurance that any GET operation will be a small data set or a very large dataset.
4. Retrieving data based on a URL where there UI is controlling filters, sorting, etc., i a very different idea from retrieving the content on a page. If such an API based solely on GET were to function, it would have to apply all the filtering and sorting and field selection logic present in the Airtable rendering engine. This would require a lot of time to process.

Thank you @Bill.French, for this IT focus which is clear and instructive after my rather primitive enthusiasm for bed jumping!

However, I remain at the edge of my frustration when I can’t retrieve my Tables & Views Metadata up to my Views parameters and Formulas Text when I export my Table / View: either by means of the “CSV Export” accessible from the UI or by means of the Script-Block in its current version. (and even from a Custom-Block that I may reach after 10 july).

Elastic Search against my text populated tables still remains in my focus, but in the medium term. I didn’t prioritize this before I got a good set of Scripts-Blocks that I want to write nor a Document-as-an-App that would look like an ideal Page-Designer Block or SPA that is not the current Page-Designer Block.
So I have “all my time” to worry about learning how to index my text-populated Tables and then to get it started, without expecting that I will do it very quickly.
However, as you regularly refer to this subject in your replies to the Community, I think I would be unwise not to pre-consult you here or even consult you outside the Community if I could find a budget to do so.
I keep this idea in mind!

Best,
oLπ