11/14 UPDATE: We’ve reached capacity for now and are moving to a waitlist. Thank you for the interest!
We are introducing an opportunity to provide feedback on a new in-doc search experience. We’ve focused on improving the ranking of search results and the UX. Changes include: improved matching and ranking, a default search state that allows you to navigate to recents before typing anything, an expanded search modal to make it easier to parse through results, and a more prominent search placement. Watch the gif below to see it in action.
We’re excited to hear your feedback and see how this new search experience boosts your efficiency!
If you’re interested in joining beta, please sign up here.
We will enable the new in-doc search for your individual Coda account in the coming week and notify you via email.
THIS! PLEASE CODA! It is the very reason why it is not possible to use and promote Coda Docs as apps! Such a missed opportunity for you! Either that, or for published docs also allow edits through buttons and controls without login. PLEASE! Do yourselves and us this favor! Hidden pages should not appear in search and should not show filtered results!
When I look at the new search function, the problem becomes even bigger. Until now, I could at least set a “public” layout for all base/sources tables with which only the search term appears in the expanded sidebar for search results, but all columns are hidden. With the new search function, it is possible to open the search in a separate window, which shows me an overview of all the search terms.
The enhancement of Coda’s search capabilities is undoubtedly a very useful and excellent update! At the same time, I would like to draw the developers’ attention to a longstanding request for the ability to enable/disable the search feature or to exclude certain pages from indexing. I believe many experienced Coda users would agree on the need for this function to better control access levels within a single doc.
Having the possibility to disable the arrows to navigate between rows in the detail view would help with this, but I guess a bit off-topic in this thread
@Pablo_DV It doesn’t feel like many are interested in this new doc search feature because what Coda built here is not among the pain points. I, personally, would prefer if this is NOT released at this stage, because it exposes even more the data beyond the doc going further into the workspace and other docs. This would make coda a data privacy killer.
That’s why I am OK to flood the thread with a reply to you here, despite not being on the topic
If that helps, when the layout is not of base table, you can apply the following setup:
a) change the table view to Details
b) set a filter which gives no entry (I use .isnotblank() as the most universal)
When user opens this view, there is navigation at the bottom but it’s “1 of 1”. Also, added bonus is that my most hated “featured” of having a hyperlink to the table is not visible. So this is how it looks for the user opening this table view:
Unfortunately, this trick doesn’t work for the main table and we all know that any reference column would lead to it, so… this is solving just part of the issue. I use it mostly to minimise the cases when person just swipe with the finger and changes data to another row by mistake (happens unexpectedly a lot).
Thank you all for the feedback! We read all your replies and understand how important discoverability and security of data is across a variety of scenarios.
There are important details we want to make sure to nail in excluding hidden pages in search. For example, when to allow access to specific data on hidden pages (like letting users search for specific tasks on a hidden page) and how to prevent access to hidden pages across all areas in the product (e.g. the page list, search, notifications, etc.).
While we don’t have a timeline to share right now, we’ll keep your feedback in mind and appreciate the thoughtful responses in this thread.
Sorry, but frankly I don’t care about any of these search “improvements” - literally zero value add for me and everyone is my workspace. I just want to Doc Locking options to include toggling search off for an entire doc, and toggling AI off.
Thank you for your attention to the feedback in this thread.
Here are a few thoughts on improving access control through search:
Enable or disable the search bar entirely within a document.
While this option could help, it may not fully solve the problem if the workspace is designed across multiple linked documents. In this case, search within a document where the bar is enabled might still theoretically show data from a document where the search bar is hidden or disabled. Therefore, it would be logical for any document with search disabled to be fully excluded from search results across other documents.
Assign a “quarantine” attribute to hidden pages.
All data placed on hidden pages would be fully excluded from search, including the hidden pages themselves. However, it’s essential to control data visibility so that excluding data from search does not impact its visibility through designated links or relationships on other pages or databases outside the hidden page.
Issue of accessing parent databases located on hidden pages.
This issue also exists with locked pages containing parent databases. In these cases, when a user accesses data from search results that lead to a locked page, they should not be able to edit the data if they don’t have the required access permissions. Therefore, it would make sense to exclude such scenarios and redirect the user only to the linked views.
It’s a bit strange. There are many posts on the forum about the “search” issue, but so far, not a single response from Coda (as far as I know). The more people suggest a way to hide the search bar or remove the visibility of hidden pages, the more effort seems to be going into advanced search features instead. Both are useful. But sometimes search is a real pain.
If so many people are requesting a way to hide or disable search, perhaps there’s a reason for that. After repeatedly ignoring these requests, maybe it’s time to consider the feedback behind them. Adding a “hide search” option could be a helpful solution. This is a partial solution to the problem, but arguably it is not so complex to implement.
Both having a search feature and being able to hide it could be useful. After all, Coda already allows buttons to hide many interface elements—like the “+” button or the “new” button, or many features to have 1, 2 or 3 lines in the title of tables. So why not consider (at least) adding an option to hide the “search” feature as well?
We are introducing an opportunity to provide feedback on a new in-doc search experience. We’ve focused on improving the ranking of search results and the UX. Changes include: improved matching and ranking, a default search state that allows you to navigate to recents before typing anything, an expanded search modal to make it easier to parse through results, and a more prominent search placement. Watch the gif below to see it in action.
