Searching in base/main view, doesn't include results from searching in table view

[Lauz_Dix]

Because this is so simple to include, we are not sure if this is a bug or just a very surprising oversight.

When you click on the search button within a table, you can search for any data, in any field, in any record, instantly.

When you click on the search button within the base/main view, it only appears to search the titles of the bases and doesn’t include the search results that you would see when searching in the table view.

From our limited coding experience, this would likely take a couple of hours fix as all that would need to be done is, when a user uses the base view search, just also search each of the users tables (as is done in the table view search) and include those results alongside the standard base name results. This is a common feature in almost every other similar online service and so has become an expected, mandatory requirement from any user.

We have found several alternatives that do the same thing or very similar to Airtable but their universal search also includes all records as expected. We would like to test out Airtable before considering promoting it to our sizeable audiences. This would result in substantial additional revenue for Airtable at any conversion rate.

Not sure how long something so simple like this would take to fix but we would really appreciate any time scales as that will allow us to plan when determining whether to promote Airtable or one of the alternatives that already has the universal search that all users expect.

Thank you.

[Bill_French]

Lauz_Dix:

… also search each of the users tables (as is done in the table view search) and include those results alongside the standard base name results.

To do search well, I think there are many other requirements (ranking results for example) and I also cannot understand why deep search - indeed, a universal search across all bases - isn’t a fundamental aspect of Airtable.

I think we want something like this, because that’s what my clients were asking for - a single [relevance-ranked] search result list in an Airtable, with immutable links to all bases, tables, records, and attachments where valid hits have been located.

[Claudio]

Searching all tables is available as a Block, a Pro Plan feature.

[Bill_French]

Claudio:

all tables is available as a Block

Yep - it’s not bad either. But if you consider search as a strategic asset to avoid wasteful energy, it gets a bit more complex. Here are the key points that a few of my clients suggested for the system I crafted.

Ranked Results

A key requirement - perhaps the most important - in search is relevance. Users have demonstrated little tolerance for search results that fail to be organized and ranked by degrees of importance. To be effective, search outcomes must be ordered using a ranking algorithm of some sort, otherwise, you’re still just groping for information and flat lists are especially useless when the number of hits is significant.

Consider a search query for “sales projections”. If these keywords appear in the name of an Airtable base, it’s probably far more relevant than when it appears in a field, a comment, or an attached document. Likewise, an attached document containing this search phrase would probably be more helpful than when it appears in a note field. And lastly, even subtle nuances like this phrase in proper-case elevate the index to a higher value.

Ideally, the ranking algorithm should be configurable because we all build tables and data models differently and for different purposes.

No Silos

For search solutions to be effective, they must span Workspaces, Bases, and Tables in the context of each user’s security envelope.

Information Accessibility

When a search reveals specific records with fields that contain collections of items (such as attachments), each of the attached documents should be treated as individual artifacts. This is to say that …

• They should be presented as discrete hits if (and only if) the file name or content they posses match the query.
• They should be individually ranked. A document whose title is “Sales Projections” should rank well above a document whose text only includes this query phrase.
• They should each be discretely accessible. You don’t want to click one link to open the record and then have to search further for the document attachment that is of greatest interest. Instead, the search results should present direct links to the most relevant documents however deeply they may exist in the record structure.

Index Management

A key requirement for indexing solutions is the agility to create and manage multiple indexes. While the idea of an all-knowing unified search solution is certainly appealing, the realities of search in organizations are more stringent. There are security and accessibility concerns that must be considered. Index management must be agile; the indices must be easily shaped and shared to meet each organization’s needs.

Results as Data

Search results should be delivered in a format where they can be manipulated. If each “hit” is served up as a native Airtable record complete with links to bases, tables, records, and attachments – users are more able to use the results in other processes and analyses. They can use the features of Airtable to sort, organize, filter, and share the results as new data sets.

I like the simplicity of the Search Block, but it fails to meet some of the most important aspects of search and misses the mark on many innovative possibilities.

[Lauz_Dix]

Thank you Claudio.

We did look at the search block but from our perception, it appears to be something different to what we are talking about. It looks like it allows an advanced search to be added to a base. That is obviously a useful feature for those that require it but what we are referring to is much more general and a standard feature seen on all/most other similar services. In that, the main view search box should include the results from all of the search box results within each base/table view, one level down.

So basically, if a user is looking at the top level where they can see the icons for each of their bases and a search box that allows them to search for the name of a base, if they click on a base, the search box within allows them to search for all records within that base. It is these search results from within each base that should be included in the top level search box. Hope that makes sense.

If a user cannot carry out a simple search to find a record and are instead are forced to open up every single base to repeat the same search, then it renders the entire service useless as is such a fundamental feature that almost every user would require. Probably why all other similar services have included it.

Would you happen to know if the Airtable staff monitor these threads as we envision a monumental number of new users coming to test the service and not continuing due to lack of this basic everyday feature.

[Claudio]

I’m curious: Which other similar services offer this basic everyday feature?

I don’t know to what extent the Airtable staff monitor these threads but, given that you envision a monumental number of new users, I suggest you contact sales.

[Bill_French]

Lauz_Dix:

from our perception, [Search Block] appears to be something different to what we are talking about.

Yep, this is precisely my point above; the Search Block sees only a silo of data. For search to be effective, it must not be bound by arbitrary [logical] collections of information. Instead, it’s only bounds should be based on the security context of each searcher.

I don’t agree that it’s “something different” than what you are discussing.

The Search Block is a window into data and it supports keyword queries that does provide a useful findability feature, despite the fact that the “window” is tiny in scope. It doesn’t allow a lot of light to come through, but it is the right idea.

Lauz_Dix:

the main view search box should include the results from all of the search box results within each base/table view, one level down.

Indeed, a broad search capability should exist at the Workspace level. However, [in practice] search activities often occur when users are creating new data. For example, before making a comment or adding a note to a record, they might want to review other dependent or related conversations to this new data item. Allowing search (across all other bases) in the context of creating a new record, has a place in Airtable; it is a use case that I see often.

As such, the notion that a broad and basic search feature should begin and end at the Workspace level is flawed. It would be better, but it would not address the broad and pervasive need for findability.

Lauz_Dix:

the main view search box should include the results from all of the search box results within each base/table view, one level down.

Agree. I think this is a reasonable expectation of any feature labeled “search”.

Lauz_Dix:

[users]… are forced to open up every single base to repeat the same search

Indeed, this is the primary complaint I’ve heard from my Airtable clients concerning the Search Block. It has significant friction. Yes, it “works” to some degree, but it is far too tedious as a way to find data.

Lauz_Dix:

Would you happen to know if the Airtable staff monitor these threads

Yes, I see them in this forum all the time. I’m sure search is on their radar and they’re carefully assessing ideas for improvement.

Lauz_Dix:

… then it renders the entire service useless as is such a fundamental feature that almost every user would require. Probably why all other similar services have included it.

By “entire service” do you mean Airtable itself, or just the Search Block service?