[Closed] Beta opportunity: New in-doc search

[Piet_Strydom]

I would like to suggest that Coda implement some change management/ psychology in feature announcements/ enhancements.

An example of how not to do it, was the changes with the introduction of the AI and restrictions on page creation. That cause a huge amount of frustration in the community.

An example of how it is being done well, is the sync page implementation. We have been made aware of the journey, and the different steps in the journey. (Thanks @Ayuba_Audu !) We know where Coda is with sync Pages, and know where they are aiming.

I REALLY hope that this search announcement is a step in a process towards our request for access management, including in search. If it is, a high level roadmap like we have for sync pages would be great. I assume it would be freakishly difficult to implement, so a on-off switch for the search bars (including the new one) would be great workaround.

But it’s just a ramble,
Rambling Pete

[joost_mineur]

I am 100% with Max.

Quite a few of us in this community feel that we are not taken seriously. We have participated in beta testing, we have helped new users, we have given feedback to Coda - but what we mostly get is features we didn’t ask for. Getting new features is OK and they can be a nice surprise, but we really need a couple of things done/fixed, Most of these are probably not all that hard to implement.

And I don’t agree with @Piet_Strydom about the ‘almost perfect’ journey of the sync page implementation. Even though I understand that is a hard nut to crack, it is useless in a lot of scenarios until phase 4 is finished. I get excited about every update in the sync page project, spend time with it (again) - to find out it is not there yet. That is really a waste of (my) time.

PLEASE, Codans, give us a couple of things we really really really need. We want a couple of optional doc settings that, for anyone but makers,

1. hide the searchbar (we have written so many times why, but reach out for a full explanation)
2. make hidden pages really hidden
3. make the print & pdf functions (which less experienced users can’t find) accessible with a button
   
4. give us a few (really, just a few) style options (font size of standard text and for H1, H2, H3), line height) in order to make our pages a bit more compact (in particular on mobile) - and don’t keep all that white space when it is not used for table titles (after all, we can hide them, then why occupy the space with…nothing. Same for page-subtitles and probably a few more.
5. allow for a default setting how tables are displayed on mobile (currently, it depends on the first column for a table to show up as a table or as a stack of cards. Maybe even better would be a extra setting for every view or table to tell Coda what it should look like on mobile.
6. allow editors to edit locked pages on mobile - locking is very necessary, but an editor should be able to edit text and formulas if they are not at the office.

If you care about your community users (and the thousands of users that do not participate in the community) communicate about these subjects. We care about Coda - and we want Coda to care about us.

I use Coda every day, my business runs on it and I like Coda more than any other software I have used to manage and organize my … just about anything. This is not a please do this or I will have to find something else message, this is from a fan who wants an even better Coda than it is today.

Greetings,
Joost

[joost_mineur]

And a small additional thing:
In modals we have the following (at the bottom):

It is a nuisance, it is confusing and it does not serve any good purpose for most users: it needs to be optional (or it needs to go).
Something similar can be seen when having a table in Display modus. Most of the time, we really don’t need it.

[Jean_Pierre_Traets]

Dear @Kathy_Pan,

Thank you for the reply, considering the constraints on the subject I am aware that from your position you can not do much more.

Hereby, even without being Codan, neither having the authority, I kindly want to request
@Ayuba_Audu to dedicate some time to to research the situation on both sides.

Ayuba has proven to Master linking the world’s of developers, engineering, Makers and users.

We need a constructive understandable reasoning for all stakeholders on what Coda is up to.

Dear @shishir kindly use you skills and influence to direct this in the interest of all parties involved

[Stefan_Stoyanov]

The community hasn’t been this lively in a long time.

Calling out the elephant in the room is what we need to be doing more often.

[Bill_French]

In 2019 I recall writing a negative scree concerning Coda search. It was shortly after a scathing review of Airtable search. I was in a bad mood and my AI team was just getting into Coda. Search. Of course, in 2019, it was pretty bad.

My commentary now a half-decade ago (which I cannot seem to put my fingers on because search is so shitty), underscored a basic idea - the security context of the user.

I spent a fair but of time a Verity (the 1990’s enterprise search engine company) and the one thing they were absolutely driven by is knowing that the discovery of a document titled “1998 Layoffs”, would be deemed a security breach even if no one could actually access the document. Ergo, the security context of each user must dictate information access.

Coda doesn’t seem to share this mantra, nor does it appear to have an architecture that makes this possible, else, it would exist. As such, I believe the problem is much bigger than we are able to realize, and Coda is simply too fearful to reveal the underlying technical challenges. But one must ask …

If you’re building the all-in-one app that supports a variety of variant object types and objects within other objects, why was this development effort not buttressed with a vast collection of security-related requirements?

While I agree that disabling search altogether may eliminate problems for certain customers, the underlying porous architecture remains. The only reasonable security model from my experience is to assert accessibility at the document level, and even that still has some risks.

I’m also dismayed that most of the vendors continue to come at this challenge without a unified mapping of information objects in the context of each user. If they were, the very idea of a hidden page would be unnecessary. In my view, the bigger mistake was thinking that hidden pages were a good idea. We’ve all come to learn that this was a really bad idea. And now we think it’s a feature that encourage Coda to lean into; also another bad idea.

Hiding objects and pages should be reserved to satisfy requirements of visibility and UI simplicity. Not access control. That’s the mistake.

[Bell_Arden]

Strong upvote for this - It is probably the biggest issue preventing Coda from being taken seriously be my team as a platform they can trust with our data, because it is effectively either everyone on the org has access or no one, and Coda of course knows that this is not how organizations work.
And as someone who has put a huge amount of time into Coda development, this is a huge frustration for me

[Marko_Petrovic]

I have to agree with Max and others here, search and ability to see hidden tables and other stuff mentioned here (and one thing that pains me personally is Coda changing column types automatically, just to add to the list) are really becoming pain for most serious use cases.

And I find it a bit frustrating that we had same feedback and frustration when search was “improved” first time some time ago, and now in this second “improvement” ever single feedback was just ignored…

[Phil_Purdy1]

I can’t use the mobile app anymore. It keeps crashing and forcing itself into low memory mode. I deleted the app and tried to run it through the browser in desktop mode. Doesn’t work much better.

I don’t know if it’s ios related, or coda related but mobile is broken beyond being usable for me.

[joost_mineur]

We have that problem for all our users that have an iPhone. As far as I know, there is no workaround.

[Niko_Nyman]

As a feedback to the new search UX: the UI is slightly better, but the search results are not. After joining the beta, not once has the first result been what I was looking for, while in the old search the first result was most of the time the thing I needed. In this regard, the New Search success rate for me is 0%.

---

Regarding other topics in this conversation…

@Marko_Petrovic

one thing that pains me personally is Coda changing column types automatically, just to add to the list

Cannot agree more. It results in unexpected behaviour and feels more like a bug than a feature.

@Bill_French

Hiding objects and pages should be reserved to satisfy requirements of visibility and UI simplicity. Not access control.

I fully agree, this is the way Coda is built – even if we would like the hidden pages to work differently. Access control is only available at the Doc level.

In my experience the hidden pages make Coda useful for many uses cases that I believe are common with doc makers: like building tools where employees or clients should see only their own data. But using hidden pages requires you to accept there’s no real data security.

If you need proper access control, as far as I understand the only way is to create a separate doc for every and each employee or client, and use cross-doc to sync data from master docs. And cross-doc comes with its own limitations. This quickly becomes so cumbersome it no longer feels like a viable solution.

In my work I struggle with this pain point every day, but I accept that companies like Coda pursue their own vision. I’m guessing here, but the vision might include a platform for super-charged internal docs and knowledge sharing. The vision might not include building a platform for creating client-facing tools.

I’m really happy that I can use Coda to quickly test and prototype tools for employees and clients, but at the same time I realize I will outgrow Coda at some point and these tools need to be re-created with another, more robust system.

[Marko_Petrovic]

So any updates about excluding stuff from search that shouldn’t be shown there ? (as pointed out by many people in this topic and other topics before)
Or it will go same like automatically changing column types, doc makers point it out as a bad practice, years pass - nothing changes.
I have a feel this will have same outcome…

[Brian_Klein]

Thanks for everyone’s feedback in this thread. We’ve launched the new search experience to all users and we think you’ll be particularly interested in the feature details Ben mentions here.

For issues, bugs, and suggestions, we always recommend using the Suggestion Box category or contacting support in-app. That way, those requests and concerns can be routed to the Product team directly. I’m going to close this thread since we’re out of beta now. Thanks again!