Hunting for Fields is my #1 time waster in Airtable. I spend lots of time scrolling horizontally through column headings, or vertically through the Fields Pane. I have 5x more fields than I do Views in most Tables and I interact with them (i.e. need to find them) more often too.
Why not add the “Sections” functionality for Fields, like the one that Views have?
Too bad custom apps cannot create, modify, or delete views. It would be really nice if they could. If and when custom apps gain these abilities, I will want to create such an app.
On the other hand, why should such a tool be a command-line interface? Command line interfaces require users to recall the commands they want; point-and-click interfaces only require users to recognize the commands they want. That makes them much easier to use.
It’s a good question. Speed is the short answer. Why are Slack and Coda so inclined to integrated CLIs? Speed. Simplicity. Productivity. These tool designers know that features like this are typically attractive to power users and power users are very comfortable with command lines and less thrilled with pointing and clicking.
This is untrue. AI is both practical and performant; it allows humans to ask for the same thing in a variety of ways with great precision.
I predict there is an untapped market of users who would love a CLI that allows them to locate information, change views, and access data more quickly.
Yep. If you think of a pivot table on a spreadsheet with 500 fields, now you have 500 rows and no human wants to look through that much crap. Unfortunately, Airtable (and many other tools) fail to understand that the definition of data and meta-data is too rigid. You need to treat all data - even field names - as first-class searchable citizens.
I didn’t easily find a lot of Forum discussion about this topic, so created this new one. Maybe its a matter of the words I am using to describe the need. I like ‘filter/search/sort’ - that’s probably both more specific and more encompassing than how I described it.
There’s something interesting about the notion of creating views programmatically, especially with ML predictions: here’s the data you’re looking for and some fields that you’ll probably want to use next.
While I agree that a CLI can be faster for someone who is proficient with it. It takes time to become proficient with the grammar and vocabulary of a CLI. I think that creating/changing views isn’t needed often enough to make it worthwhile for users to learn a cli.
I do not understand why you say that this is untrue. To use a CLI, you must recall and type the command you want. If the CLI grammar and vocabulary is similar enough to another language (such as English) the learning curve is easier, but the user still has to recall and type the command. However, with a point-and-click interface, the user only needs to recognize the desired commands.
People’s expressive language skills tend to be smaller than their receptive language.
Perhaps I don’t have enough experience with natural language querying, but I think the technology for using natural language to interact with computers in everyday apps isn’t there yet. It is getting better and people should certainly work on it, but the preponderance of mouse-driven interfaces is winning now. For now, mouse-driven interfaces are much easier to create and to learn.
Ya’ know how I often say something and three years later it becomes a reality? This is one of those somethings. In less than three years, someone will become wealthy for building a high-productive command-line interface to Airtable that uses no more than your voice or a few keystrokes to do magical things in Airtable that would otherwise take forever with a pointing device.
To all you aspiring developers out there - if you are looking for a partner to act as the chief architect for this idea, give me a shout - email@example.com.
After thinking about this, it occurs to me that Airtable folks might not want to prioritize features that encourage users to add lots of fields to an existing table, rather than linking records to a new one. It could facilitate poor data design.
However, I think this could represent on opportunity: make it easy to convert a field group into a linked table either when creating the grouping, or later. This being a natural path for new users to understand and create linked tables.