I had the same mental struggle. I was so excited when I found a viable Workflowy alternative that’s actually being actively developed, instead of sitting idly in maintenance mode. But I still had one foot in both Dynalist and Workflowy because I had a hard time accepting the seemingly needless complexity of Dynalist’s documents and folder structure. Then I read this post by one of the developers where she emphatically states that they philosophically believe in their folder/document structure and that it was a deliberate deviation from how Workflowy is organized. That helped me simply accept that if I want all the yummy goodness that Dynalist has to offer, I have to accept that model. Once I did that, I have to say, it hasn’t been so bad. I can’t say I’m convinced that’s The Best Way, but I don’t struggle with it like I did at first.
I understand that there are one-pane and two-pane outliners, but Dynalist is trying to do both at the same time and this makes it fail for me.
If I treat every node in a tree as a separate tree (i.e. “zooming” into it) then there is no need for an additional somewhat differently working tree put on top of that. Likewise, if I have a folder/document structure, then that this is my tree and each node doesn’t need to be further broken down into a zoomable tree. Dynalist mixed these two together and it becomes weird and confusing to work with it.
As for documents becoming “their own thing”, this is automatically covered by having a tree. It’s another node on the same level as the other nodes who are “their own thing”.
Believing in something does not really make me be convinced in the usefulness of it.
The problem I see is that the folders/documents is just an artifical cut made straight through the tree of notes. Everything below that cut is a Workflowy-ish tree, everything above is the same, but just displayed differently and given different names.
I cannot understand how this can make anything more structured and organized. It’s just a source for confusion and obstacles I have to overcome when I want to collaborate.
One could easily mimic that feature by specifying a depth limit for the outline on the left. E.g. I could specify a depth of 1 and all first-level nodes of my single tree are being shown on the left as a persistent outline. I specify 2 and all top-level and second-level nodes are being displayed on the left, and so on.
I think the real issue is the sharing. Dynalist is trying to do both paradigms at the same time (see my other reply) but then gives you practically no freedom in choosing your way, because as soon as you want to collaborate, you are forced to mess things up and go into the splits.
Believing in something does not really make me be convinced in the usefulness of it.
<shrug> Hey man, I’m just relaying my personal experience with the app. Take or leave it.
I cannot understand how this can make anything more structured and organized
<CrystalBall>I see Workflowy in your future…</CrystalBall> 
I think the real issue is the sharing.
I tend to agree with you on that one.
Sorry, this was not supposed to go against you. It was regarding the Dynalist team strongly believing in their folder structure.
So I hear you say 2 things:
- I don’t like the document level sharing model
- I don’t want to work with documents and folders
I think the latter is easy to solve: don’t. With Dynalist you have virtually everything WorkFlowy offers – plus a bunch of features on top of that. But you don’t have to use any of those features. Don’t like documents? Don’t use them. Collapse the file pane. Solved.
The former is harder to solve because sharing on the bullet level isn’t in the near or maybe even distant future. Dynalist believes strongly in sharing on the document level. If I’ve learned anything from software, it is that you best learn to work with what is. In your case I would simply develop workarounds.
As for the design paradigm behind this, and whether a 2 pane outliner could also be done by showing certain levels of one large document, like Noteliner used to do, is a bit of a moot point. Dynalist works with as many, or as few, documents and folders as you want – and that is Dynalist. To argue it should be different is arguing the product itself should be different. Like going to the Evernote forum and saying that it makes no sense how their notes don’t behave like a mindmap.
How long have you been giving this a try? My first run at Dynalist was…unpleasant. I lived in WorkFlowy before and everything you mention, I did too. But giving it another run, just working with it instead of against it, I really have grown to like it the way it is (minus the sharing; I would love bullet sharing!).
Just give it a go, maybe do drag out 1 or 2 major bullets from your main flow into their own documents, and see if it really sucks. If so – then WorkFlowy might be your better bet.
Cool man, no worries. 
I think I’ve decided that I will keep using WF for those times that I want to share only one node.
I started using it today by importing from Workflowy and trying to re-share what I had shared before, which right away posed an issue.
I will keep using Dynalist and hopefully come to peace with it. The feature set is just too attractive to not try
Yeah…that hurts.
You’ll find your way around. Might take a test run or 2 but then it’s all Hotel California for you
100% agreed on this. I also really like the “when it becomes its own thing” expression; I’ve never thought of expressing it like so.
@ruud, that’s exactly how I would reply as well!
@Torben_L, thanks for trying out Dynalist! If this method doesn’t work for you, no pressure!
Nothing is designed to satisfy everyone’s needs. As you said, we’ve heard from some people that they really like this method, and I can definitely imagine people thinking the opposite of that, especially those who have been doing it the other way for so long.
I very much agree with you. I think it’s an unnecessary limitation. Why not have it both ways? To me, one of the super-powers of WorkFlowy is the fact that you can share a sub-sub-sub-list with a team, in view or edit mode. I have been using that in many very complex projects, to, for instance, share instructions, or get inputs from a larger, even anonymous group, while myself remaining in control of the embedding list context. Not to include this “because we believe in the folder/document structure” to me seems like tunnel, or should I say, “bullet vision”? Anyway, since faith cannot be changed by reason, I guess we will have to live with it.
Having said that, I, of course, very much like the great additional feature set (which, in turn, the WorkFlowy developers don’t seem to want to add out of faith in simplicity). So, I guess, we will - for now?- need both tools: using WorkFlowy for project management and sharing purposes, and at the leaves of those WorkFlowy lists, include links to DynaList docs, providing all the extra goodies.
It’s not just that.
Because at the base of Dynalist is a Documents-with-bullet-lists structure, sharing Documents is easy: share → done.
Sharing bullets requires the whole code logic to change.
Why?
Because bullets “live” in Documents, when I open a bullet list, I also open a document. Where is the bullet? In this document.
Now when I share my bullet with you – where is the bullet, where does it live? In a Document with my Document name except everything else in that doc is hidden? In a new doc of your choosing? How to keep the relationships between your doc, my doc, and our bulletlist in tact?
While there are a good number of solution scenarios, each requires more or less rebuilding the code base and database structure.
That said, best way to get things done with Dynalist is to vote for this feature
That is kind of backwards, isn’t it?
I usually decide on a set of features for my product before I design and code it. So “this feature is was not included because the code base would have to change” doesn’t make sense.
I believe that this redundant documents feature was added because someone wanted to have a unique selling point in comparison to Workflowy and chose something he knew from other services but didn’t consider that it would actually go against the philosophy behind the endlessly nesting list approach and take features away instead of adding.
Exactly. And that’s how Dynalist started too. Just because the features the developers decided upon aren’t the ones you would have, doesn’t mean they didn’t start out like this.
True in the sense that Dynalist doesn’t have a WorkFlowy philosophy but a Dynalist one.
I too, still, would love to have bullet level sharing – but I understand 1) that it’s not really in the DNA of Dynalist’s philosophy, 2) that adding it anyway just isn’t so simple as flipping a switch “sharing of bullets → on”.
As for features; like the flavor of ice cream, it’s a preference. For me, Documents add a very good feature. I love the two pane Folders + Documents model. For you it doesn’t. Who’s right?
The Dynalist philosophy is neither here nor there. It couldn’t decide what it really wants to achieve so it is trying to do both.
What Dynalist does is it takes a single-rooted tree structure and chops each branch off at a certain point. Then it displays one half on the left panel and the rest on the right. Then it complicates the separation by allowing feature set A only on the left, feature set B only on the right and feature set C only exactly at the point of separation.
I can think of two alternative designs that would allow for a similar behavior without forcefully limiting the user.
(1) Allow creating bookmarks for arbitrary bullets. Then allow the user to organize those bookmarks in a folder structure.
(2) Use the left panel as an alternative way of displaying the tree from the root up to a certain (configurable) depth. It would basically just be a visual addition to display the first N levels of the tree.
Both ways (a) neatly stack on top of a clear single-rooted tree design, (b) allow having an extra “folder” structure for those who want it without messing with other users, and © don’t interfere with a possible per-bullet sharing.
I hear what you’re saying and feel your frustration. You would want to have WorkFlowy with some of the features of Dynalist. Or you could have WorkFlowy but without any of the features of Dynalist.
Given what I’ve read so far, I think it’s still at this point.
Besides that the only thing I can do to offer at least some help is to share my philosophy/experience that in general one does best by assuming the feature set of a software is what it is. Compare: people on the Evernote forums asking for a better editor since years; or for tags in notes; or for clickable searches in notes. If it’s not there, either see if you can work with/around it – or pick something else. There will always be something not to like. Maybe it’s kinda like marriage; you pick the defaults you can live with
I understand that, I’m a developer myself and I know that it is hard if not impossible to satisfy all your potential customers’ expectations.
But still I think feedback from your customers is extremely important, and that’s why I want to show my view on things. I am afraid that the product has a design flaw, which is a bit different from “just” a missing feature like in your Evernote example.
Of course it’s up to the Dynalist team how they build their product, but at least I raised my hand. Attitudes like “this is how the product works, deal with it and be quiet or go somewhere else” are not healthy in the long run.
@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! 