Hey @Bill_French ,
I understand your thoughts and I agree: it really depends on the scenario what works best, that’s why it should be a makers option to turn this on or off.
Greetings, Joost
1 Like
In the late 90’s I was asked to determine how to take Microsoft Word and align a strategy so the NLP could be used to run all of the features. Luckily, we had lots of data to help guide this development strategy. There were 9,786 features in the product at the time. Vastly 90% of the features were used less than 1.7% of the time.
I believe this feature – the ability to make it possible to allow search to constrain hits based on existing arbitrary filters – is one of the capabilities that would be irrelevant except in a very small percentage of use cases.
My reaction -
- Don’t become Microsoft Word.
- Don’t create parts that are vastly unnecessary.
- Don’t create search complexities that would take users by surprise unless it’s a delightful surprise.
- Discovering there is in fact data in a table when a search feature concealed it would be the opposite of a delightful surprise regardless of the Maker’s intention.
1 Like
The way it currently works is that filters are respected by the new search box. If there is not going to be an optional setting, this is the way it should work. Some records are filtered for good reason!
1 Like
Totally agree with @joost_mineur.
A search box should be related to the data provided by the view of the table (filtered or unfiltered, corresponding to the intention of the table creator).
1 Like
Indeed, and we agree at a basic level, this is not always ideal. How often will it be ideal, remains to be seen. 
I believe that in the vast majority of cases, users will be surprised to learn that after using a search query that they know should have some hits, and they get no hits (because of a not-so-obvious filter override), they will not be happy with such outcomes. That said, I predict this default behavior will change at some point in the future.
This is a really good point to consider, but it assumes use cases where filters are established by Makers and not modifiable by users. While such use cases include filter assertions that are baked into a solution, I think this is vastly not the most common practice. It’s more likely that users are provided with ways to change filters. If I’m right about this, users will be frustrated when these two features collide in conflict.
I’m not certain which approach would appeal to most users but I might also toss in yet another monkey in the wrench - search in the context of a security constraint. Imagine a Maker who has established a filter to avoid showing certain records to certain classes of users. My belief that a table search feature should trump filters (by default) flies out the window. LOL Feel free to thank me for making your arguments.
I build docs/apps for my users and just about every table they actively use has filter(s) for very good reasons. Just imagine having a filtered contact list for a specific supplier and what would happen if users can start doing a search that bypasses the set filter? Say you have 20 contacts for one supplier and when you start (free) searching you get 40 hits? Or 5 hits, but not related to the active supplier?
Sorry, but that would kill just about everything I do in Coda.
I really think the best approach is to have a default way of how the search box works, with table options to overrule these defaults (or to turn the search box off altogether).
If we get options I really hope your prediction is not going to materialize (
That said, I predict this default behavior will change at some point in the future.
)
2 Likes
As you can see, I’m coming to see this in a very different light.
We should have the option in Table display to set the visibility for the search box;
Show search box: On/Off.
Wow! I’ve been loving this!
One quick bug that I noticed: try deleting a column while you’re searching a record, it will reset the search.
A nice step forward but not quite there yet.
My suggestion is that there is a “For your eyes only” switch for all interactive filters and that’s what has been suggested by the community since I first saw a filter in Coda. From that we can figure out when we need a search field or a filter and how to be used.
I can bet that a normal Coda user would find this extra field confusing because a) it’s not well visible and b) it’s the only element that works by user. So the general assumption would be that either all work by user (the most logical thing in 90% of the cases) OR neither works by user.
2 Likes
A toggle for “search all records” could flip it between filtered or all, and would be quite clear in what it does
Is there no way to force the search bar to be visible? It seems to only show up if the users’ cursor is horizontally in the same line as the title of the table.
I’m giving this doc to people who are not familiar with Coda, so they don’t have any idea that this search bar exists at all.
2 Likes
Yes, but it might expose a lot of records you filtered for a good reason. So for me, no user-toggle for this field
It would be nice if there are maker options to set this toggle, or to set to allow the user to toggle.
And I really would prefer that there would be a specific control to place this this search field wherever you want it - or not place it at all. Kind of like a specialized text box with at least the parameter table or table view which you can put on your page, not necessarily the same page as the page where the table resides.
2 Likes
What’s then current preferred technique of user filters? I have tables being filtered by many people at once
1 Like
love letter to coda
This is a great step forward to make Coda a true multi-user app without having to do filter/flow acrobatics with hidden tables. (While those are great to overcome this major shortcoming, it made Coda hard to approach or roll our widely.)
Next step: implement whatever you did here for the interactive filters that you allow editors to create so easily for a table view.
First discovering this feature was exciting, but was quickly followed by disappointment when I proudly invited my colleague to “our new CRM app that will replace Salesforce for a fraction of the cost”.
He loved it when I showed how it works on his machine: "This is GREAT and only $30 a month for all our users? Amazing ".
I went back to my office feeling pretty good about myself… went back to my Coda app and started entering some stuff. Shortly thereafter, my colleague sticks his head into my office and shouts: “Hey! I think we were hacked… stuff on my screen changes when I don’t even touch the computer? Is this Coda company legit???”.
That’s how I found out the hard way that input fields, and interactive filters on a page are (for reasons beyond my capacity to comprehend) not bound to users…
But I see light at the end of the tunnel… clearly with this new feature the Coda team has shown it CAN be done and I look forward to seeing this capability expanded in other areas of Coda.
4 Likes
Oh - and one issue I found with the search box…
When I do search with the non-disruptive search, which filters down my table. Then click away from that page. And come back to the page, the search field is empty again, and there’s no refresh or “x” to clear it… You’re kinda stuck unless you type in something new and then click the “x” to clear the search.
I agree with @joost_mineur the non-disruptive search should be on the “admin” filtered database. I’m all for empowering end-users with tools like Coda, but just like kids, they have to play within a fenced yard.
Sometimes I wonder what Coda is really used for in the wild… replacement of old-school enterprise systems, or single user apps for spreadsheet power users…
Maybe Coda’s competition for yet-another-todo app is a hint where the company’s head is at?
Which would be a missed opportunity… Coda is 80% there on the path to be a system powerhouse for the small and medium enterprise. Google tried this with their App Maker tool and failed because it was too complicated.
Coda
1 Like