Usefulness of folders and documents

đź’¬General
#1

I’ve been using Workflowy for a long time now and appreciated the choice of having a single endlessly nesting list for all your notes. It just makes total sense. All the knowledge is in a tree structure, where each node is in itself a tree and thus categorization and organization is automatically established.

Now I want to move over to Dynalist because of all the features it has that Workflowy is lacking like Markdown and images.

I already love Dynalist. However, I have a hard time understanding the choice of adding folders and documents on top of the tree structure paradigm. I mean, literally folders and documents are trees themselves. Trees on top of trees.

If I have a folder A and a document B and inside the list C, then it is identical to having a top-node A with a sub-node B with a sub-node C. It is exactly the same. Why have such a redundancy? I do not understand what benefits it has, I only see the added complexity and burden of managing a tree on top of trees.

Instead of documents, just have the bookmarks feature. It’s all you need. And if you really desperately need a tree on top of a tree, then let us put the bookmarks into folders. But why split the notes into half here half there?

I am heavily tempted to fully ignore the folders and documents, but oh well, I can only share a whole document with someone else. Bummer. Now I am forced to rip apart my structure and move half my nodes from feature-set A (the note tree) to feature-set B (the folder tree) to elevate my document to the boundary level between those two in order to have it shared. Wow.

I only hear positive statements about the folders and documents feature. This baffles me, I surely cannot be the only one having a very hard time with this.

What are your thoughts? Is anyone thinking the same way I do?

10 Likes
#2

I thought the same way you did – and then made a switch and now am thinking in the documents way :slight_smile:

Outliners go back a long way and from the start there have be one-pane outliners (think: WorkFlowy, Buzz) and two-pane outliners (think: DynaList, Bonsai, TreePad).

As for sharing – I’d love to be able to share at the bullet level. But that’s fundamentally another discussion.

What I like from the folder/document features is that it reflects how I think. As you say, it’s just another type of “outline” … and I think in outlines. So when I have a list that grows substantially, up to the point where it becomes it’s own “thing”, I move it into its own document.

So, yes, I have a Work folder with all my work related documents in them. My SEO Wiki in it is its own document because it clearly is its own thing. My project notes are another document; it wouldn’t make sense in SEO Wiki.

And I have an Information folder where I have a How-to document, a Research document, and a Recipes document. Each of these is a clear standalone unit.

As a result I find the separation of my lists clearer, more organized, and navigating between the many lists that i use tremendously easier than in WorkFlowy.

2 Likes
#3

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.

4 Likes
#4

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”.

1 Like
#5

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.

2 Likes
#6

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> :wink:

I think the real issue is the sharing.

I tend to agree with you on that one.

2 Likes
#7

Sorry, this was not supposed to go against you. It was regarding the Dynalist team strongly believing in their folder structure.

#8

So I hear you say 2 things:

  1. I don’t like the document level sharing model
  2. 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.

4 Likes
#9

Cool man, no worries. :slight_smile:

#10

I think I’ve decided that I will keep using WF for those times that I want to share only one node.

1 Like
#11

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 :slight_smile:

2 Likes
#12

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 :wink:

#13

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.

2 Likes
#14

@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.

2 Likes
#15

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”? :slight_smile: 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.

2 Likes
#16

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

1 Like
#17

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.

1 Like
#18

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?

#19

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.

2 Likes
#20

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 :slight_smile:

2 Likes