@Torben_L, thanks a lot for your feedback.
First of all I don’t think we’ve said that we’re not going to add per-bullet sharing, it’s just really complicated and would take long, given the current code base, like @ruud said.
Another thing is that Dynalist is not just a developer’s side project, we also aim to make it a working business so it can develop better in the long run. With so many things to do, picking the priority has always been hard. If we pick the “wrong” priority and throw in months without much return, Dynalist could die or be on a pause like WorkFlowy. We don’t want that to happen, so we chose to implement Google Calendar sync before per-bullet sharing, for example.
Finally, I think it’s fine that you want to let us know you think per-bullet sharing is superior, but saying things like “redundant documents feature” is counter-productive. Saying that the current Dynalist is bad won’t help you get your point cross better; I think the key thing we’re discussing here is the need to have per-bullet sharing. If you absolutely cannot tolerate the existence of documents, you wouldn’t waste time discussing things here, as you probably know it’s impossible to remove the documents feature at this point. So the only practical alternative left is to help us understand your need for per-bullet sharing (which I think you explained well), if you still want to use Dynalist.
What if your users complain that your product misses a key feature they need which would require a large portion of the code? That’s always a possibility, right? Also people do things differently, it’s helpful to know how you personally work, but I don’t think it helps the argument (something like “I do things this way, so most people do things this way, so you should do things this way”).
This is a negative way of putting it, I think. For example, if someone says that Facebook should remove the Like button because it encourages a type of useless social interaction or that Reddit should not nest replies and use a flat format instead. I don’t believe they would say that’s possible. It’s not “deal with it and be quiet or go somewhere else”, but more like “we’re sorry but we’re like this and it seems impossible to change; I think product X would solve your needs”. I don’t understand why you need to interpret the fact that a product is hesitant (or simply won’t) change one of its key concepts like that, it’s nothing personal. We want more users as well, but there’s a limitation of what we can do.
That’s not true. Active development is the unique setting point in comparison to WorkFlowy, and that’s what most people would say. We don’t need a second one. We truly believe documents are needed.
Endlessly nesting list approach does not go against documents in my opinion. I don’t understand why WorkFlowy’s approach is the golden standard of outliners in your opinion, but outliners have long existed before WorkFlowy, and the first outliner can date back to 1968 in Engelbart’s NLS system. OmniOutliner, another popular outliner, supports documents too. It doesn’t conflict with the philosophy of nested list approach (aka outliner), as the inventor and pioneers of this philosophy already use documents.
I hope I’ve made myself clear. @Torben_L, thanks again for letting us know about your needs, we’ll keep them in mind. And thanks @ruud!