Usefulness of folders and documents

[Torben_L]

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.

[Erica]

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

@Torben_L

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.

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

@Torben_L

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.

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.

@Torben_L

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

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.

@Torben_L

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.

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!

[Aldo_de_Moor]

Thanks for the explanation @ruud . Interesting follow-up discussion also. As to me bullet sharing is a primary need given how I use the lists-of-lists for project support, I will keep using WorkFlowy for that. Still, I see a great use case for using DynaList documents to build background documentation. So, I will experiment with using WorkFlowy as my primary outliner tool, Dynalist as the add-on for building project documentation. And I did cast my vote…

[ruud]

I had 3 bullets that I really needed to share, also project/work based.

In my case one bullet was a clear self-contained entity, it’s “own thing”. A sort of wiki. That was easy to move into its own document and share that.

I also have a list of ongoing work. I’ve made a list of 12 weeks/slots where work is outlined and commented – that’s it’s own document now. The doc contains links to client/project related info that’s just for me, so that info is in its own doc.

What does your setup look like @Aldo_de_Moor?

[Aldo_de_Moor]

Wouldn’t work for me, @ruud. As I mentioned, I use it in many different ways in very complex project settings, and often need to share something many levels deep in the tree. Moving these elements out into the folder hierarchy, would break the context. I will stick to WorkFlowy for that.

[ruud]

Ah, makes sense. If only Workflowy + Dynalist had IFTTT so we could just sync stuff

[Erica]

@Aldo_de_Moor

Wouldn’t work for me, @ruud. As I mentioned, I use it in many different ways in very complex project settings, and often need to share something many levels deep in the tree. Moving these elements out into the folder hierarchy, would break the context. I will stick to WorkFlowy for that.

Have you tried dragging it out to be a separate document and then insert an internal link to it in its original position? We could make this part easier if this can solve this problem for some people. Just a thought.

[Erica]

Just want to post a comment here to show that some people out there would prefer multiple documents, like this guy (and maybe the 4 other guys who upvoted it):

Link: https://www.reddit.com/r/productivity/comments/60irgr/top_10_notetaking_apps_for_2017/df79pki/

This isn’t for proving anyone wrong, just saying there exist people who prefer the multi-document way.

[butlermatt]

Personally I love the multiple documents as opposed to one giant one.

Particularly at the top level of my Workflowy list were general “house keeping” nodes anyways for Work or Home, and various house keeping nodes under those before getting into the actual lists I was keeping. Having them separate documents makes it clean and accessible.

More importantly it doesn’t clutter when I no longer need a document. I have a couple of “archive” folders that I use for projects I’ve long since completed or otherwise no longer need to reference. They’re out of the way and for instance if I just search a document those results don’t show up.

Something that is important to keep in mind when using Any tool, is you need to use it as it’s designed. While it’s nice to say “you should support this feature that I like from product X”, if a product tries to do everything it ends up becoming a mess of features which become unwieldy. Workflowy made certain design decisions, Dynalist others. You wouldn’t use Workflowy like you would use Evernote, just as you wouldn’t use Dynalist as you would Workflowy or Fargo.io. At some point you need to stop making a tool like the last one you used, and accept it for what it is and determine how you can best adapt your flow to the design decisions that app made instead. And in some cases, maybe it just doesn’t suit your needs. It’s unfortunately but sometimes a tool can’t be everything for everyone.

[Torben_L]

Maybe the real answer to my question is searching?

Until now I was wondering what the difference is between a document and a folder and a document and a bullet and a folder and a bullet. Don’t they all serve the same purpose? If I draw a tree structure of the contents in in Dynalist, they all are nodes with a name and sub-nodes.
When I add content, I never know where to draw the line. At which point does a folder become a document and a document a bullet? They all feel the same. No matter where I make the separation it feels wrong and dirty.
So when I work with Workflowy I don’t have this issue in my head. Everything is a bullet; just clean and simple. And it works.

Now @butlermatt says searching is limited to just this single document. This might be the actual reason to have documents. They give a clear indication to Dynalist where the boundary of a topic lies. I can use the same tags in different documents but still have them not get mixed.

I haven’t tried searching a lot, but if I recall correctly I can search a subtree in Workflowy, but it requires me to be in the topmost bullet that I want to get searched. If I can search a whole document in Dynalist no matter in which bullet I am currently (meaning it also shows results within the parents of my current node), then I can accept the documents as a “feature”.

[Erica]

@butlermatt

if a product tries to do everything it ends up becoming a mess of features which become unwieldy.

That’d be my Quote of the Day!

[Pierre_Faure]

Provided the main value of the document model actually is to help quick access to deeply nested items in this overall abstract tree structure, I think there is a way to retain that value while doing away with the cons of the document models which in my book are :

• mental and on-usage overhead which impact flow :

  • you essentially have to keep in mind two structures to find information
  • you probably spend time getting the structure of the folders and file right, which is kind of absurd since you already spend a lot of time getting the structure of your notes/journals/lists right

• nobody’s forced to use multiple documents, but let’s face it, users are nudged to. you have this big shiny document pane, and having only one file on it does not feel satisfying. This seems like a “don’t-push-the-big-red-button” (of course you will!) type of situation. Nothing wrong with the document model, but I think there’s a better way.

• The document sharing model (as @ruud mentioned) which forces you to adapt your thought to accommodate to Dynalist

---

On to the idea. It actually comes from the very-well done Bear app. In Bear, you have a document model, but the structure is not built, it actually emerges from tag usage.
It makes no sense for Dynalist to consider using this model as-is, since tags are per-node, and have a broader usage than just “simulating” documents.
But a few tweaks would allow to have a single structure for everything while gaining the clarity and quick access of a document model.

It would be interesting for the file pane to be automatically populated through specific markers set by the user.

Say I have only one big outline with all my things in it. Say there’s not a lot going on in my life right now so I only have this :

• Home
  • is
    • where
      • the
        • heart
          • is
    • a
      • state
        • of
          • mind

Now I can bookmark each of these nodes for quick reference. That’s great. Say I bookmarked the outlines in bold. Now I got three bookmarks called “hear” “is” and “mind”, in whatever order and no structure on the bookmark pane.

What I propose instead of having a document pane you fill manually is for the pane to automatically populate with the path from the root node to your bookmarks. In my example we would see

• Home
  • heart
    • is
  • mind

This obviously has a huge impact. Because that would involve switching to the one-big-document model à la workflowy.

What I think is interesting about this approach :

• for people who think in folders : they can have their folders and files.
• for people who think in. outlines : they can have quicker access to deep parts of their structure that matches the way it is set up

I think by doing that, not only will Dynalist get an advantage over Workflowy, but on other two-panes outliners as well, such as Outlinely.

[Torben_L]

I like it. The idea sounds like an evolution of my “allow custom structure for bookmarks instead of documents” suggestion I made a few times throughout the thread.

[Pierre_Faure]

Thanks
Would love to know the feasibility of such a thing, but I’m not getting my hopes up.

[butlermatt]

@Pierre_Faure

What I think is interesting about this approach : * for people who think in folders : they can have their folders and files. * for people who think in. outlines : they can have quicker access to deep parts of their structure that matches the way it is set up

So… what you’re saying is that your proposal changes everything they have at the moment to provide the exact same functionality they have now, but also the fact that every user then needs to re-learn and restructure everything based on this new format?

I have 50+ documents in various folders/sub-folders. I have 4 bookmarks which I’m surprised by because I use 0. Never.

Plus there are significant performance penalties in the workflowy “all one document” structure. Specifically since Dynalist wasn’t designed from the get-go to be used in that manner. It would require an additional database restructuring and massive front-end re-writes too if I’m not mistaken.

With all due respect, I don’t see dynalist wanting to rewrite the majority of their app to provide the same functionality they already provide because you feel bookmarks make a better document structure than folders and documents.

[Torben_L]

It’s technically possible to automatically and reliably convert one format to the other, but yes, it’s highly unlikely that Dynalist will change anything because it basically “works” the way it is.

[Pierre_Faure]

@butlermatt

your proposal changes everything they have at the moment to provide the exact same functionality they have now

Well, it’s not exactly the same if it leads to organizing your content differently, is it ?

@butlermatt

I don’t see dynalist wanting to rewrite the majority of their app

True, me neither.
However, if we’re talking panes, would automatically hierarchical bookmarks such as those that describes be such a massive undertaking ?

I get you’re not using bookmarks. I tried using Dynalist with the multiple documents, and didn’t really need bookmarks then.
Since I didn’t want to bother with managing multiple documents (and all the other reasons I listed above) I went back to the single doc model, with which I’m fairly happy, if not for the quick access you guys can have.

[Erica]

If we were to design Dynalist again, we could consider it, maybe. But not really at this point, 2.5 years after the prototype. There are too much to be changed, both technical and product wise (current users are already so familiar with how things work currently), and although it might improve Dynalist for some people, unfortunately I don’t think it’s worth the time and effort. Soon we even want to avoid loading documents which are not being used into memory… that would make the “everything in one list” proposal less feasible.

The idea is more interesting than useful, and I think you can tell that we’re practicalists, not purists. Documents, or rather individual files, are familiar concepts since the beginning of GUI, and we find it useful to mark boundaries.

It’s interesting that people either love or hate having the document model. Some say it’s artificial or it’s redundant, and others say they finally found the solution to “not being able to create a new page on WorkFlowy”. So I understand where you’re coming from and some will agree with you.

We created Dynalist not hoping to convert all of our competitors’ users; we hope to convert those who think like us. Hopefully we’ll understand each other on an abstract level.

[dave3456]

document switching was one of the things that actually sold me on dynalist

i always found switching to a different location in workflowy to be a real pain in most cases. having to zoom out to the start and then navigate back in each time was too much of a time sink and if it was just to add a quick note somewhere then it was even worse since you have to navigate all the way back to where you were

with dynalist its as simple clicking on a document in the sidebar (or using the cltr + o hotkey and typing the first two letters of the document) and then youre roughly at the spot you want

of course this could be easily solved in a 1-document-only type setup by using bookmarks… but the last time i was using workflowy you could only see around 4 or 5 bookmarks at a time because the devs in all their infinite wisdom thought a horizontal list of bookmarks was a good idea. maybe they had their reasons

anyway, i dont think you could make bookmarks work the same way as documents since selecting a bookmark would bring you to the exact location each time, whereas switching to a document remembers the sub-item you were previously zoomed into which is a useful feature to have when youre switching back and forth a lot

another minor plus for separate documents: ive never shared anything in dynalist or workflowy, but the thoughts of sharing a sub-item thats in the same document as a lot of other private stuff just makes me feel uneasy, even though theres probably not much difference between the two methods, security wise.

[Daryl_Mander]

@Torben_L

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.

Yes. I think this really is your only issue. If you don’t like the folder/document system then for the most part it’s simple: don’t use it. But, for you I think the only issue with that is you are forced to use it if you want to share stuff. Bummer.

How about logging a feature request for “be able to share at the node level?” As @Nick_Spreitzer pointed out, the cool thing about Dynalist over WorkFlowy is that Dynalist is actually being developed and improved. If you log that feature request and enough other people share your pain, you may get what you want in a future update