We're listening: what we're up to at Coda

@SALEM_MALIBARY and @Phil_Purdy1 , thanks for the feedback, we appreciate it! We’re actively discussing how we build a more regular cadence of sharing the roadmap with the community, including timing.

9 Likes

Although coda is a great product, my use case is presenting information with a clean layout, readability, search, and navigation. It is not focused on data and project management.

Coda is so heavily focused on data and tables that other improvements for building pages and navigation seem to be at the bottom of the list.

Examples off the top of my head are page option breadcrumbs display, modern expansion panels instead of collapsible, small buttons to include in text, create and display mechanism for popup displays (eg tips, navigate, etc) within a text body and via buttons, add subpages via link to page within current doc to create better navigation trees, sizable input, mobile, apple, etc.

Search is better but still a little slow and kludgy.

4 Likes

Really excited about the amazing announcements!

I see there’s been some discussion about localization here. To add a different perspective - I’m hoping the team could address IME (Input Method Editor) compatibility issues. As a non-English user, the text conversion process during input can be quite buggy, which affects the core writing experience.

Looking forward to native integrations with generative AI like Claude too!

5 Likes

Glad to understand that the sound of silence is broken as a VC has ordered the music, CodaHQ gets orchestrated, the dance can start.

What 1B can do overnight :woman_dancing::man_dancing:

“Hello darkness, my old friend
I’ve come to talk with you again
Because a vision softly creeping
Left its seeds while I was sleeping
And the vision that was planted in my brain
Still remains
Within the sound of silence” (Simon and Garfunkel)

3 Likes

Good to hear news!
Please consider mobile app that Is actually not a mobile app: very limited options for editing (like no attachments, no columns, limitated views..), no offline mode.
Is it an area of focusing as well?
Thanks

5 Likes

Epic update. We use Coda for all our internal processes. The main limitation continues to be table size and doc load.

Especially now that we’re entering the AI era, data is our most valuable asset and Coda isn’t handling it well.

We store almost everything in Supabase and then load in the data we need through n8n automations, but this is just clunky and brings in more points of failure than we’d like.

So my main questions:

  • Can we expect any drastic changes in table and calculation limits?
  • Is work being done on the API? Allowing for a more reliable experience? Right now, we don’t trust the API at all, it’s a major single point of failure when handling huge data imports.

Ideally, all our data lives in Coda natively and calculations can be done freely without jeopardising doc load.

Appreciate you all!

5 Likes

Hi @Ayuba_Audu

I can think that localization should depend on where the user is based. So if the user is let’ say in Argentina where they use comma and not dot, then the input checker should check for that format so that that specific user is using the correct format.

For example if the owner main account (team/enterprise) column/doc/workspace format for the number columns is of 123,456.78 and then the Argentinian user has for his account set 123.456,78 then Coda data checker should warn the Argentinian user if they input in the cell 123,456.78 as this would be the incorrect way for their account setup for these number columns. That is so that they keep inputting the numbers using the corretc format they prefer while Coda internally will do the transformation to the way the doc owner wants it in the doc settings. This can be done with dates & time also.

So if I set my user format to 123,456.78 and the doc owner to 123.456,78, Coda should warn me as it does now that I should input 123,456.78 and transform it behind the scenes to 123.456,78.

This is because users across the world have different way of inputting numbers and same for dates.

In the settings tab of each doc/table/view there can be a toggle that the user can use like “By toggling this on you will use the doc number/date & time settings or otherwise set or otherwise setup specific formats yourself as user if you leave the toggle off”.

3 Likes

Is this already working? I don’t see it! I need this so bad! Please let us change the formatting of currency numbers! :pray:

2 Likes

Thank you for the news. That’s a relief!

I think all those six updates are important, but at this point the one that it really seems to be overlooked is an app update. The app store says that Coda was last updated 11 months ago… 11 months without an update these days sounds like it has been discontinued already…

A lot of the work we do nowadays happens on the go. We need a faster, more responsive and more functional app experience, without those memory load errors that continue to happen (on the iPhone at least).

I really hope you have a team focusing on the app right now :folded_hands:

6 Likes

Agreed. I’m currently moving off coda because as my doc size reached 125 mb it essentially broke down. This seems like a rather arbitrary and low limit, especially since so many in this community insist one should put as much as possible in a single doc.

Thanks for all the updates Codans! Lots of exciting stuff in there. I’m particularly interested in the doc performance improvements and size limit increases. Should unlock workflows that weren’t possible at scale before, and hopefully solve some of the challenges with the mobile app interacting with large docs.

2 Likes

hi @AJM , Coda will solve speed and performance in the months to come as @fortes pointed out. Although it is not yet available it will come. The screenshots we see are real.

The other comment that came to mind is that I am not a favor to put as much as you can in a single doc or even a single table. When I work with clients I tell them (until they get bored) one doc, one task and one table one task. Keep focus, start with your data architecture on workspace level, define your folders, how you set the sharing options and then define the docs you need to execute the tasks relevant for your project. In general tables are small and deep. Coda tables are row based as you know and as such opposing the spreadsheet logic that favors wide tables with fewer rows. Anyway, may you be able to break down some docs and tables, you may enjoy the speed that comes with it.

I hope it helps, cheers, christiaan

4 Likes

125 MB is really not big. My daily use doc hovers around 750mb.

It takes a few seconds to load, after that response is fine. I infrequently have minor issues, but not sure whether it is because of sheer size, or because I excessively recursively use canvas columns.

Maybe check with the support team whether they can see any problems.

Piet

1 Like

It would be good if part of that roadmap could also include topics that have many votes in the community, but which Coda is not intending to work on for the foreseeable future.

4 Likes

Thank you so much for the lengthier insight! We all appreciate the communication immensely.

Incredibly bullish on Coda as always. And grammarly!

7 Likes

These updates are much appreciated. Thank you!

However, everything in this world is bound by time, so if you place these on a timeline, I’ll actually believe that Coda is truly worth building with

3 Likes

Fantastic ! Well done Codans ! :clap:

@Lane-Shackleton
@fortes
@Harshita_Yerramreddy1
@Glenn_Jaume1
@Ayuba_Audu
@Shelley_Garg
@Nathan_Penner

I am so delighted to see the lights are on again.

This is the kind of communication that we value from Coda.
Of course it cannot contain all the details we would like.
And it cannot cover all the topics, issues, feature-requests, etc we would like.

But it shows the depth of the committment and the direction of the intent from within the Grammarly/Coda engineering teams.

This not only gives us the new direction, but also provides reassurance.
And this was gretly lacking in recent times.

I suspect an internal ‘moritorium’ has now been lifted with the announcement of the $1B investment. I assume it was not possible for Codans and Grammarlians to communicate on these topics while the acquisition, integration, and investor due diligence activities were ongoing.

I am heartly grateful for these frank and open updates, and I wish we can see this continue.

PS: a billion dollars is a lot of wood behind the arrow-head for sure;
but it still needs to be aimed carefully :bow_and_arrow:

  • thank you for listening to our feedback and inputs :ear:
  • we want to help you hit that bulls-eye. :bullseye:

Respect
Max

15 Likes

The coda website clearly states the following:

Are there any doc size limitations when using the Coda API?

On all plan types, docs with a size of 125MB or more will no longer be accessible via the Coda API. This limitation is set to preserve the performance of our API, and we have observed it to affect only a very small percentage of API users.

Note that both Cross-doc and Coda’s Zapier integration use the API, so docs using those features will also need to be within this size limit.

If your doc has reached this size limit, we recommend you to remove unnecessary or unused content from the doc or otherwise reduce doc size via the steps outlined in this article.

One of my tables has reached 125 mb. My engineering team has spoken to coda about it and the only solution was to move our data to another platform.

Unfortunately I have one table that has about 50,000 rows and is 125 mb, meaning I cannot add rows to it using the coda api or zapier api.

I almost cried with emotion when I saw the screenshot :face_holding_back_tears: Could you please tell us when it’s expected to be implemented? :face_holding_back_tears:

1 Like