I agree with @Paul_Danyliuk and @Leandro_Zubrezki that this moves the paradigm closer to one of a developer/app with the makers being the dev’s and the users being the editors.
However we still have a few gaping holes. Publishing seems to be the closest to the app experience - it removes the search, hidden pages - and gives the users a more familiar app experience. However editors still can find the ‘edit version’ of the doc in their coda.io workspace. Can you fix this so we can provide our users a cleaner, more secure experience ?
For anyone concerned about who can create pages, here’s my take on how you can make something like a wiki with far fewer pages and get your data in tables and canvas columns instead. This route is far more functional, scalable, and usable.
Check out the video as it explains all the benefits. I’m not suggesting a workaround by doing this, I go through how this brings a doc build to the next level.
I don’t need any of the advanced feature you mentioned in the video. I know my users will need to scan for pages in a hierarchy which naturally categorizes the pages anyway; a table cannot do this.
Coda’s original paged structure was perfect for Wikis. Why shoehorn it into tables?
I love how Coda 4.0 lets us move beyond the PROMPT as the only paradigm for harnessing AI.
Instead of being limited to long, complex, verbose prompts, we build AI functionality using Coda’s Formula Language (much more precise and reusable) referencing data in our Tables and content in document Pages.
This is a HUGE advance over the dark art of “prompt engineering” with all its secret incantations, obscure tricks, and long-winded hard-to-reproduce prose.
Now we can invest our ingenuity in building low-code FORMULAS that instruct the AI model with precision. And build up a reusable library of such formulas that have been properly tested.
Coda AI also allows the results from the AI model to be parsed, processed and stored in our Tables alongside all the regular calculations we are used to creating with formulas.
Prior to Coda 4.0, we had to rely on more advanced coding techniques using tools such as Langchain. Now our ordinary makers can exploit advanced AI techniques in their solutions using familiar formula methods.
Oh wow yes christmas has come early!! Been waiting for this since I started using Coda, and two-way sync now finally allows us to scale Coda’s use and get out of the one massive central doc issue.
Check out the video as it explains all the benefits. I’m not suggesting a workaround by doing this, I go through how this brings a doc build to the next level.
This almost highlights the problem here even more - why further un-empower pages through these pricing tier changes when inevitably Coda is flexible enough to have half a dozen ways to get around almost any roadblock imposed by a pricing model?
From a “Maker” perspective, pages are already not greatly utilized in Coda since anything that lives outside a table is losing out on a lot of the functionality that makes Coda great. If you’re a robot, having your wiki in a table makes sense. But pages are fundamentally intuitive to people and a great organizational tool for people who aren’t power users, and this pricing restructure takes it away from those people specifically. Just seems backwards to the stated intent of only charging for makers. I want pages to be better in Coda than they currently are, not something I need to avoid if I want to keep my costs down. Now they’re just canvases that you might have to pay extra to use.
The best thing about Coda is its flexibility. Although this change doesn’t completely invalidate any of my docs, it certainly has created a lot of work for me to make sure that all my docs will continue to thrive under this new imposition. I can also definitely see how someone who took a different tactic to building their docs out would suddenly now have to pay a much higher price just to keep their docs built out the way they prefer.
Coda is an insane bargain as-is, but only for a very specific use case. This change to page creation makes that use case even more narrow. It restricts approaches to how you can go about structuring your doc.
Love the app - you guys are absolute geniuses as far as I’m concerned and are way ahead of the competition on all fronts. Love the 4.0 release. Love the upcoming project management features. I am very much willing to pay you for the value you provide to me, I just don’t want to be slowly pushed into using Coda in an increasingly specific way as a consequence of optimizing for a more and more oppressively specific pricing structure.
re: 3: The new definition of Doc Maker makes sense based on all the new features that Coda has introduced. Coda docs are more and more like an app, and Doc Makers are responsible for building these apps as docs while editors just edit and use them.
I think that’s an interesting point. Though Coda made a lot of things easier to use in the last months, it is still complex due to its flexibility and powerful features. It makes sense to involve a doc maker to propose the best possible solution for a client.
It is on the roadmap, what you have today is a sync with equal permissions in source & target docs, not a sync without shared permissions, they work on it as we speak. They announced 4 steps and still two to go. Cheers, Christiaan
(That said, I hope Coda implements a feature where canvas columns can be displayed as pages on the left panel because for those wiki-ing use cases, of course seeing the pages on the left is much more convenient than in a table)
So much this! Adding this one feature would save the situation in my opinion. Theoretically, editors would still be able to produce pages provided that they are stemming from a doc architecture that a Doc Maker had to create, which I think is in keeping with the intent of Coda’s pay structure.
Yes, doc makers should be the only ones capable of building out new architecture for a document. Anyone who is using Coda understands this as the agreement they entered when they purchased a Doc Maker seat. Right now that’s too easy to bypass - the loop holes are obvious. OK fine, close the loop hole. If we have to paywall page creation to make that loop hole a little more inconvenient then I see the logic.
But you still need to meet the expectations of someone who is stumbling into Coda for the first time. Their touch points are Google Docs or Notion or even just pen and paper. They want to work in pages. If Coda signposted them towards this suggested feature where canvases are converted to pages, then the lightbulb would turn on for those people: “Coda likes tables - I guess I’ll use tables then!”. It would be a win-win.
Pages in Coda are weak functionally but strong intuitively, and making them a strictly paid component of Coda ensures that any intuitive functionality they could bring to your doc will die on the vine.
@Timothy_Choi You do not need to pay for all editors, you only pay for people that create new pages.
It is undoubtedly going to be more expensive, but it is still a very good value for money. With a little bit of planning, it is possible to ensure the cost remains manageable.
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.
team on this new milestone 
because for those wiki-ing use cases, of course seeing the pages on the left is much more convenient than in a table)