Finding information easily is a cornerstone for any good team tool, but how does that translate to tables that are as collaborative as Coda’s? Using table filters to search for information can be disruptive when working with others, which is why we created a more collaborative option for finding information. Now, you can search for information in a table without updating the view for other collaborators.
For your eyes only.
Forgot something important in a meeting? We’ve all been there. Just use the Search icon in the right-hand corner of your table to find the information you need without disrupting your teammate’s work.
Get the information you need, faster.
This one’s for our OKR planners. Need to update the status of a specific OKR? Quickly jump to an OKR without adding a table filter.
Tips:
Before you get started, here are some tips to help you be the most successful with your table searches.
When searching a table or table display, such as cards, the search navigation will search all visible column types.
When searching a table with a canvas column, the search navigation will search for text, but not any tables inside the canvas column.
If you wish to create a more permanent personal view of a table, you can opt for creating a table view.
Whether it’s using a filter formula or the Search icon, how you choose to find information in your tables is now in your control.
I love this! I hate to even suggest changes this early, but I’d love to eventually see the ability to restrict which fields this searches, and in some cases I’m sure it would be nice to adjust “how” it searches (maybe case-senstive or not, etc.)
For anyone curious, it seems this searches the visible columns, in the rendered-visualization of the data. i.e. if you search for 6, it will find rows that contain 6.00, but if you search for 6.000, it won’t find them. This can be useful in some situations. I also wonder if it could prevent some real-values from being displayed, i.e. a formula rounds a value to the nearest whole number (4.0) but internally it is represented as the actual number (3.99981)
Indeed, but this is indicative of a full-text search feature which requires an inverted index.
So here’s an idea - it’s really simply to build a full-text search index from a table using a custom Pack. How might we interface the search events in this new UI with a custom pack?
Imagine an arbitrary mechanism to provide a search UI that calls upon an index that was created and maintained in a custom pack. I think this is doable [already].
Great work, team. Similar results were possible before of course with relatively complex rigs, but this is a very good step for lowering the floor and making Coda “just work” out of the box.
Edited some wording to be a bit more precise about my comments. No substantial changes
Hey Coda team,
Very nice, but also (potentially) killing some carefully crafted designs. I have some tables with to many columns to show - and also with to many rows to show. But I might want the search to extend to those columns of rows (sometimes).
Can we please get the following table options:
to set search-box on/off
to search only in visible or in all columns
to respect or overrule current filters
programmatic access to the contents of this new search box (i.e. to clear it with a button)
(custom) background colors for search box with or without content to make the box standout better
option to clear or keep search box contents upon leaving a page
It is wonderful that this new search box is local to the user, but some of suggestions above will make it miraculous.
Excellent thank you !
But in table display, would it be possible to “highlight” the search ?
Default, you need to hover to see the search, it’s great, it prevents seeing too many things all the time in the doc,
But for some tables, we spend our day searching them, and also they are used by non-tech-savvy people, so it would be nice to be able to pin them so that it always stays visible, and maybe that it appears a little bigger, so that everybody see it easily when they need to.
Thank you
Hmmm, I’m conflicted about this one (love the others).
The core requirement of a search feature is [generally] expected to ferret out the incidents of the query irrespective of other influences. Typically, search experiences achieve this with “advanced search”. I consider myself an advanced user and from time-to-time I forget there is a filter enabled and become frustrated until I realize I have this hidden constraint enabled. This frustration will likely be more common if the search experience honors the existing filter state.
Tips:
pin them so that it always stays visible, and maybe that it appears a little bigger, so that everybody see it easily when they need to.