Lots to unpack here, but the one topic that I am overjoyed with is the unlimited free use. I have a doc that I have built for other people to use, but the “infrastructure” was three time the free limit size. I shoehorned a version into the space limits, but it did away with a lot of the functionality.
Now I can share that doc freely, without worrying that people can only use it for 14 days.
Hi Mitchell, thanks for your feedback. I would love to hear more about why you think Coda works best for specific use cases, and not others for you. I will follow up via DM.
On Editors losing flexibility, I think Scott said it best in another reply: “But Coda still maintains the idea of an editor as an architect. Yes, no net-new pages can be added, but any pages that are existing can be architected. New tables made, relationships established, formulas written, buttons configured, automations set, etc. In my mind editors are still far more than editors. And editors are still free!”
We shared a bit more on this in this post, but we debated this change heavily internally (as you might guess), and it was important to us and the team that we maintain the collaborative feel of the product with any changes we make. This felt like the right compromise across the wide range of use cases we’ve seen people use Coda for.
As a non-profit ourselves, Coda is very generous with their non-profit discount and given the power and breadth of Coda that $18/month for each Doc maker is a steal.
Considering what we have to pay for the likes of Mailchimp and others, Coda feels like a massive bargain considering we run our all org using it.
I don’t really understand why you would expect it for free, there are literally millions of non-profits so it’s hardly like it’s niche.
when I mentioned use case I meant specifically the pricing structure. To be fair, it’s a mischaracterization to call it a “very specific use case” since it works for me and many other small to large companies. I was really just thinking how Coda is either an insanely good bargain or more expensive than Notion if you have a case where everyone needs to be doc makers.
But that’s the thing: with this page-making restriction, that worst-case scenario becomes a little bit more possible. Putting page making on the paid seat does not align with my understanding of “Charge for makers, not collaborators”.
Makers are power users and wire up buttons and formulas and tables to make the app. Collaborators use the app. I would prefer that the app-constructing tools were restricted, not the basic building blocks that any layperson would expect to find in any application of this type. That to me aligns better with “Charge for makers, not collaborators”.
Restrict features that decisively separate makers from collaborators. As I mentioned in reply to Scott’s post, my preference would be that you take away button configs or formulas or table relationships from the editor role before you take way the ability to make a page.
I can completely understand that internally at Coda it would be a ludicrous thing for team members to lose these abilities, but at my small company it’s going to be probably a few years before anyone on my team feels comfortable enough to develop their own Coda “app” that suits them specifically. In that event, we would happily buy them a Maker seat.
We would prefer an approach where doc maker seats are properly representative of power users rather than throwing this curveball of restricting page making to the role, which targets the ground level of users rather than the top-end. Even if the end result is that the editor has less capabilities its worth it for the clear delineation between the types of user the two roles target.
Everything looks very good, except the page changes. This seems like it will divide the community, especially one that has a flow focused on Wikis.
It might be possible to get around the problem with pages by creating a duplication button with a field to change the page name, so editors would be able to create their pages and rename them independently.
It’s not as flexible as before, but it might get the job done. Here is a very basic example of what I mean.
Not to be the conspiratorial weirdo, but this page-limit change pushes most workflows into tables. Along with this, AI is being given away for free, almost as an incentive to use.
So basically, they seem to encourage users to use more AI and structured data, I imagine this has to do with training Coda’s own language models.
In summary, we’re introducing sync pages — formerly known as Coda full-page embeds. Sync pages let you have the content you need, everywhere at once, by allowing you add a page—and all it’s sub-pages—into multiple docs.
We just shared a community post with more details about sync pages, you can read it here.
With today’s release, two-way sync tables do not allow adding or removing rows; we do hope to add that functionality in the near future. For the time being, you can continue to use action buttons to add/remove rows.
One more question, given the roadmap: will we see the ability to sync views (rather than full tables) and maintain relationships with related records? If not, will there be another method to accommodate this sort of work (syncing a partial, filtered table to another doc for security purposes, while maintaining all the relationships to other synced tables) that will be forthcoming?
I just don’t want to hack my way to a solution only to find that the work to get there might have been avoided if I just waited a week or a month.
Synced Pages are nice addition, but requirement that you have to have access to source dock kinda limits its functionality drastically at the moment. I guess when we reach step 3 where we don’t need access to source it will become much more useful and I see some use cases where it will land nicely, still inability to reference that table in rest of the doc where its embedded limits its uses cases - but thats what cross-doc should do I guess
Cross doc (probably most painful Coda feature to work with), step in right direction BUT, I didn’t have much time to do some detailed testing and its late over here, nevertheless as far as I saw there is option for instant “pushing” of changes from “synced” doc to source one, but sync from source is still limited by old restrains (manually, daily, hourly)?
I mean that kinda vastly reduces functionality of this feature and also leaves A LOT of space for corrupting and overwriting data and ending up with bad results. I really don’t see how that can work in real world unless you are just using it for backup feature or you force people to constantly manually sync everything before any change which is impossible to actually do in practice
I don’t want to sound overly negative, this new updates are definitely step into right direction, but somehow at the moment they feel like they are half way through
Hopefully with future updates (and I hope those are bee soon ) those features will get to the level we really need them to be!
If I understand your question / case, this should work properly today if you have a filtered table synced in with cell lookup values pointing to a base table you sync in; this is the common case we see.
What doesn’t work today is when you have a table synced in with cell lookup values that you want to point to a filtered table you sync in. Fixing that latter case is on our roadmap, but not slated for immediate work.
There is still a way to add pages through Coda API, which will (as far as I know) remain functional for makers. It’s not a full replacement — there’s no way to delete or reorder these pages, and definitely it’s not as convenient as just adding them in the editor. Yet still it’s a valid way. The “add page” button can be implemented as a pack; the doc maker would then make a shared connection for it in their name. There’s plenty of generic Coda API packs already, but I went ahead and created a specialized one with hopefully a better UX and some specific design choices (e.g. only a doc owner can install it, and each installation is limited to only that doc) that’s also more secure than just allowing all API calls on the maker’s account:
Before making it, I ran this by Coda and they were okay with it. To me this is but another proof that this change is not about paywalling but about making a right design change that in the long term will promote better practices. I’ve been around long enough to live through the whole 2.0 Pricing thing, and I can say for sure that the way they handled it really shows that Coda cares and listens.
I got that, but sync from source to the cross-doc’ed table is still good old hourly/daily? That was my main complaint You can instant sync TO the source but sending data FROM the source is still on old “system” which is kinda strange decision (I guess it can be useful in some cases, but push sync in both directions would be huge improvement )