I love Coda so far, it’s more advanced than Notion and makes me want to switch. However, the lack of infinite page nesting is a core problem and makes it too complex to bring over my current setup.
So for the time being, I wanted to cancel my Pro plan only to find out I need to email sales. The context matters very much here. The fact I can autonomously sign up and setup my billing but not manage or cancel it is a disappointing practice to say the least. As a product designer who has designed high retention SaaS products, this is a very cheap, annoying and unnecessary retention tactic.
What could be done in a few clicks and less than 10 seconds, turns into a multi-interaction drawn-out sequence that requires me to open my email, write something to sales, wait for a reply and leaving me wondering what information I need to provide, whether or not the downgrade process will only be intelligently applied before the next charge or will they downgrade now, how long will they take to reply, etc.
Hi @John, thanks so much for sharing your experience and frustration. I’m sorry about that experience and I understand why it felt frustrating.
I’m on the pricing team and the intention was definitely not to use this as a retention mechanism. It was an unfortunate scoping tradeoff that we shipped without automatic downgrading but this is an active project that is being built as we speak and should ship shortly.
Thanks for the reply and the added context jerols. Happy that this is something that’s being worked on, as it is more in line with what the brand seems to be about in terms of promoting user flexibility and autonomy.
For what it’s worth, the lack of infinite page nesting is a core problem that I’m running into too. Perhaps I’m primed to see the threads because it’s a feature I need, but it does seem like there are many people who are requesting it.
It would be wonderful to hear something from coda on this as a feature/what they are thinking in terms of implementation timeline.
Just to make sure we’re talking about the same thing, what I mean by ‘infinite page nesting’ is essentially the ability to put a block of text inside another block of text. They could be used to build Wikis or, in my case, build a scope of work that can be sent to customers.
One thing that always troubled me about folder hierachies - especially deeply nested ones - was that they ultimately not only failed their objective, but that they also made the problem worse. Navigating and finding information degrades as nesting depth increases.
In my view, there are very few problem domains that can benefit from infinite page nesting and I’m just curious about your use case. Can you share just a few sentences why this is the show-stopper for you?
Multiple key features (search, @-referencing, easy-editing) require a single-doc workflow for single domains.
A single layer folder hierarchy is severely limiting overview if you use your document as a design document or wiki in which you have a significant number of sections.
Severely limiting to the point where the sidebar becomes useless, and a special manually updated index page is required. (Which can’t be kept open in a side-window as Coda acts as a singleton Chrome process)
Most often sections are edited within context and the hierarchy provides a filtered view on relevant context through inheritance.
I get it, it is indeed limiting. I’m wondering if that limitation is an intentional design choice whose benefits far exceed the drawbacks.
My sense is the Coda designers are skilled-enough and the architecture is well-positioned to enabled deep folder structures. But I also sense that building document-centric solutions that address requirements with simple elegance may not be best served with deep folder hierarchies.
One must ask -
… is it possible that in our enthusiastic desire to put everything into a single document misdirected? Are we expecting too much and thus trying to put a square peg in a round hole?
Surely there are practical limits and bounds that while very easy to breach (technically) may not make sense (experientially). Perhaps I’m being a bit too Zen for this topic, but I think there are times when the spirit of the app needs a voice.
As I’ve stated in other threads I suspect the single-document approach goes against Coda’s current commercialization goals and therefore will be pushed to back.
The problem is that the product itself is schizofrenic in its voice. What is presented as possible, stimulated as possible as natural through product interaction, and commercial goals of Coda as a company seem to be in conflict.
Either we’ll see a refocus of target audience, with accompanying changes in feature sets or a split/tiering of the product at some point.
P.s. I would prefer it that when you quote a sentence you don’t leave out the conditional on the sentence, as with the rephrasing you attribute a view to me that I don’t have.
Being forced to expand data horizontally instead of vertically simply means you end up putting things in places that don’t line up with how you think. For an application that focuses on promoting flexibility through modularization, it should be up to the user to choose how they want to nest their content because it best fits their way of working.
To come back to my case, my current system is already setup. Although Coda offers more control through formulas, the overall benefits don’t surpass the cost of rearchitecturing everything to fit their model.
