I also have this slight feeling of anxiety. I hope it’s just a side effect of some uncertainty about what’s happening right now.
1 Like
Hey @AJM
You could sync this hidden page to a new doc. Give (edit) access to this new doc only to these two editors and they can edit all they want on this page(s).
If you want to elaborate on this, please start a new topic.
Greetings,
Joost
Hats off to you, Max! As always, your approach to real-life scenarios from the user’s perspective is spot on. This is exactly how I’d like search within most products/doc to work.
If the ideal solution can’t be achieved, it should at least be broken down into something more meaningful. For example, if I’m already in a doc, I want to search only within that doc. It’s frustrating to see “renovate the kids’ room” appear 7 times from all my yearly planners every time I start typing in the search 
Someone mentioned Fibery.io and looks quite good and covers some of the flows of Coda. Haven’t tested it yet because I got sick but soon will. Also started this topic because we are not alone in looking for a safety net and potential post-Coda era. Please keep sharing your findings there.
that makes a lot of sense. Now I’m wondering why the person who set it up this way didn’t realize this! thanks
1 Like
I do use it for a wiki and honestly, this search (and the search in general) only make my wikis worse.
1 Like
It’s a shame that this is happening. The search function itself shouldn’t be seen as something bad. With the update, the search has indeed become more convenient. Perhaps I would only make the top menu bar collapsible. The key issue is that the improvement of the global search, which performs its function well on its own, fails to consider the unique context of using Coda as a platform for creating doc-as-apps. This creates a conflict of context.
Coda positions itself as a platform for building document-based applications. This inherently involves a deep consideration of interaction scenarios, including access control, data visibility management, and creating a personalized user experience. (My goodness, this has been discussed dozens of times before.) The global search, by ignoring these aspects and not providing users with a way to control its impact on the system they’ve built, undermines the logic that creators have carefully designed.
Still, I believe this problem is solvable, and it can be addressed harmoniously for all user groups. Yet, for some reason, it’s stubbornly overlooked by the developers. I will never believe that the creators of a platform literally designed for building applications fail to understand the impact that search has on what can be created in Coda.
Imagine an office building with different access levels: regular employees have passes for their own floor, managers have passes for multiple floors, and executives can access them all. But instead of each person having an individual key, everyone is given a master key that opens every door without any restrictions. As a result, the “building” becomes a public thoroughfare where a regular employee can easily enter the security office and cause trouble—or even walk into a bathroom stall where someone else was hoping for privacy.
It feels like we’re just parroting the same thing over and over in different words, trying to find the key to the developers’ hearts.
7 Likes
Could you elaborate in which ways things are worse?
Users who primarely create ‘app-like’ documents in Coda may prefer the old, less intrusive search function—or even no search at all—over the new, prominently displayed one. Personally, I fall into this group. I can already search within Coda using ‘@’ on canvas and lock this for user of the documents to limit access. However, the new search highlights pages, tables and data some users shouldn’t interact with, disrupting the navigation and interface a doc maker carefully created and, in the worst cases, allowing unintended insight and changes to data. Previously most users of my “apps” didn’t even know that there is a search function - let alone one that shows data that is not on the “UI”. I know with “publish” and Top Navigation it’s possible to circumvent it - but this comes at the cost of no comment funcionality and no editability when using custom domains.
2 Likes
That’s not correct. Hidden Pages are still fully searchable - be it titles of hidden pages or canvas content. In inkognito modes without any hidden pages visible. This is very misleading!
1/27 update: The new search experience is now applied to anonymous doc scenarios, so you should no longer see hidden page titles & canvas content in search by default!
[Original message] Hi @Stefan_Huber, thanks for flagging! It looks like you’re searching in a doc where you are an anonymous viewer. We haven’t fully ported the new search experience to anonymous doc scenarios - it’s coming soon! As you pointed out, what you’re seeing is the same behavior as before i.e. hidden pages are still discoverable.
We’ll update this thread once it’s live, at which point hidden page titles & canvas content should not be discoverable by default, with the same caveat that hidden pages should not be used as a substitute for real access control.
2 Likes
@Kathy_Pan Can you in the meantime respect the wish of 85% of the Coda community which voted that they would rather have the search disabled or not there at all, until you allow to enable it on demand?
1 Like
The poll you conducted has several fatal flaws. Most importantly, 31 voters is nowhere near large enough to be representative, nor has there been any stratification done. You will find that several orders of magnitude more than 26 people will be extremely upset if searching is now to suddenly be removed. In any case, 23% of the people said they “don’t find it necessary”. That does NOT mean that they want it suppressed.
The poll also has severe participant selection problems - first, it only includes Coda users who make use of the community, further only community users who recently visited the forum, and third, only users reviewing this specific thread, and has done so in enough detail to see your poll, and then decided to vote. EXTREMELY unscientific.
Do not assume that your poll indicates that you speak for 85% of the Coda community, and moreover that you speak on behalf of even a meaningful portion of Coda users.
This is not a ramble!
Rambling Pete
1 Like
Hi Piet,
I know where you come from and don’t disagree. I wish there was more transperancy and better data. However for the lack of better data and absolutely no visibility on how Coda makes decisions to release features, I prefer to lean on what actual people who care enough to express opinion about a new feature have taken the time to vote for.
The fact that millions of people don’t vote doesn’t justify to ignore the votes for those who did, right?
If Coda decides to ignore expressed opinion (being statistically insignificant or imperfect) would mean something to those who did vote. I want to know whether Codans believe that this opinion matters or they have no intention of considering (which is likely because Coda doesn’t give a penny about it’s community and we are already know that; the question is more whether they have intention to change that opinion or not).
hi @Stefan_Stoyanov1 ,
I understand why all of this upsets you and many of us. The main reason hidden pages got introduced was to move stuff out of sight and this is often necessary for reasons like:
- cross docs coming in do not improve the user experience
- you want to show views of tables and not the source table itself
- and likely more reasons
Hidden pages would not have become a big thing, when Coda would have solved the data exchange between documents as of day one natively. Imagine a native solution that permits the maker on workspace level to reference (filtered) data from other docs without using the cross doc pack (although Coda, it is not native). I believe such an approach would take away a lot of the pain, but maybe not all. Hidden pages are also relevant from a UX perspective.
What I don’t understand so much in the Coda approach is that we did not receive rather simple options to configure the search bar for example based on maker and editor profiles. Only the Coda folks know why they did what they did, but I don’t think they understood the damage the inflicted upon makers that really tried hard to keep data out of sight.
Cheers, Christiaan
7 Likes
Every day, I grow more convinced that the doc-as-apps ideology will gradually be replaced by AI-driven productivity, potentially simplifying the platform’s functional depth. I fear we are entering a new era where the concept of doc-as-apps will no longer be central, and we will have to adapt to this shift.
I’m confident that the core functionality of the platform will remain intact, but AI automation will likely take precedence over customization—the very aspect many experts are eager to see developed further. Whether this approach will succeed is still a big question. From this perspective, it becomes clear why many creator requests are being ignored: they simply don’t align with the company’s new strategy.
From a business standpoint, there’s logic in this. In light of current trends, a focus on AI is undoubtedly more appealing to investors. However, the risk is that Coda might become just another AI platform, losing its uniqueness and identity.
I hope these changes can strike a balance between AI and customization, but for now, the future remains uncertain.
2 Likes
which is likely because Coda doesn’t give a penny about it’s community and we are already know that
The fact that millions of people don’t vote doesn’t justify to ignore the votes for those who did, right?
I’m not sure it’s accurate to say Coda does not care about the community or that we ignore votes or feedback.
We’re building a lasting business for teams and enterprises, and sometimes that means making some difficult choices regarding prioritizing features and their release. The community’s input is shared with the relevant product teams and used during our planning cycles.
We acknowledge that our communication with you all has had challenges recently, and we’re committed to improving it with the community. And while we can’t always share every detail, we hope to keep you informed as much as possible.
We encourage everyone in this thread to attend our (2024 Year in Review with Coda + Grammarly | Coda) on January 28th with Shishir for a peek at what’s coming in 2025. We’ll share more about the combined product vision for Coda and Grammarly.
7 Likes
Ditto what @Agile_Dynamics Max said! This new search bar is HORRIBLE. I can’t find anything with it and I know what I’m looking for. It pulls up way too much stuff, exposes more hidden table data we don’t want clients seeing and not it’s RIGHT THERE ON TOP IN THE MIDDLE and screaming at clients to use it. NO, NO, NO, NO. I’ve had to totally rebuild client docs now using crossdocs because too much data is getting exposed via search. And unfortunately crossdoc is still NOT RELIABLE. How it could get worse, I do not know, but I have tables that won’t sync for an hour. I can sit there and refresh 10 times and it says it refreshed but it doesn’t. I’ve submitted multiple tickets but by the time someone works them, the sync finally syncs sometime over night. So my clients are about to be really unhappy and they’ve paid for 3 years of building in Coda and if these sync and search issues aren’t resolved, I’ll be looking to move them off Coda. 
I don’t know what else to do for them. Legally, they can’t allow their data to be visible and syncs that take 2 or more hours to finally sync is not conducive to business. If you’d remove this search bar, I wouldn’t be facing this situation and Max is right. All the power builders have complained about this search feature and yet, the new search is 100x worse than what we were complaining about.
2 Likes
Susan I share your feelings but “they can’t allow their data to be visible”: It was always visible, now it’s just easier to find it… If they can’t allow it, you should always use cross doc - or a webhook-table version of it (which is a bit complex to set up, but allows 2-way instant synch).
3 Likes