I’ve watched the “Taming Outlook” and feel like that should be required viewing for anyone in a corporate setting; it’s quite lovely.
I have a number of Projects, which I’ve filtered into AC.ID folders in Outlook. In addition to these, I also have a number of documents which are also associated with the project which are NOT in my mailbox. Should I be using the same AC.ID in my file system? If I used OneNote to track meeting notes, do those have the same AC.ID as well?
On one hand, it makes locating within the project easy. On the other hand, I’m now looking in 2-3 places to find the information I’m looking for at any given point, which seems to be counter to using a system such as this.
On the contrary, the scattering of information across all those application silos is the great shortcoming of the current Human Computer Interface paradigm, and the Johnny Decimal ID is a tool for (partially) overcoming that. Put another way, having to look in 2-3 places for related information is a sad but unavoidable reality, but by using a single AC.ID in all those places, at least you can search and retrieve with precision and confidence.
In an ideal computing world, ‘filesystems’ would retrieve this related information for us, but as it is, we humans have to do a painfully suprising amount of manual searching, formatting, and collating, before we can even make use of the advantages of automation in doing what we’re actually trying to do.
Taking email as an example: it frustrates me often that emails are not first-class files on my computer. That I can save wherever I want, i.e. with the related other files, and read without having to fire up a huge behemoth of a program. Of course, there are reasons to keep all emails together, because otherwise it becomes a nightmare to keep track of threads and history. But that’s partly because of how the underlying filesystem is designed.
As a an amendment to my comment on Taming Outlook, it’s great for Outlook Desktop. The experience on Outlook mobile is suboptimal. But hopefully you don’t have to use Outlook mobile as your primary, so it’s fine.
I agree that the structure and especially the focus on IDs (e.g. 34.10) help me find things much more quickly even if information is scattered between multiple places.
On my private machine I have most of it in one place but even there email is a bit separately. At work of course there are much more places.
However…
Taking email as an example: it frustrates me often that emails are not first-class files on my computer.
I tend to fetch emails onto my machines via isync/mbsync into a folder structure even though I use an email client. This serves as a kind of backup and also allows me to leverage tools like ripgrep or notmuch to quickly find things in emails. Although this workflow has been drastically reduced since I use JD!
On a more esoteric side note, Haiku (the spiritual successor of BeOS) is doing exactly that with email (integrating it into the file system): E-mail
Trying out notmuch as my primary interface is still on my todo list. Funnily enough, notmuch has already helped me find some emails that I needed while I was ‘between’ email clients. Sounds sort of like what you seem to do: using it as a specialized tool for special searches. In my first post on this forum, I was implying that notmuch would actually be a good combination with the JD philosophy, so I’m curious how JD has reduced your need for that type of tool? Just being more generally organised?
It’s interesting that notmuch’s docs say: “The mail directory … should primarily contain only files with individual email messages… If there are other, non-email files … then notmuch will do its best to detect those and ignore them.” Which implies it could handle mail mixed with other files … why the cautionary note?
Also, Notmuch uses Xapian, and Recoll uses Xapian, so … possibilities?? Recoll can index email files directly, but in my limited tests I remember there was some catch.
Thanks for the Haiku links!!! This is so inspiring. Have you used it at all? From the User Guide, it seems like all the glueing together of different programs (e.g. the notmuch-recoll combination suggested above) gets superseded by filesystem-level attributes with indexes. So cool to see examples of this kind of thing.
For some time now I dit not need to search via notmuch because I really find things very fast because of the JD structure and the ingenious idea to just remember things like 34.56 which is great.
In the other cases I usually can navigate near enough via folders and search in my email client (I use aerc and wrote a bit about it: aerc mail: Reflections after the first years. · jan0sch.de). Within the post I also link to Sylpheed which is an awesome mail client with a GUI.
Regarding mixing in folders: I prefer to have my mail folder separate from the rest. Although I can see the benefit of having it all in one structure. Having a tool that displays a virtual “single structure” out of multiple sources (maybe even remote ones) would be great.
Haiku I only use within VMs and play around although some people use it as daily driver (they have some firefox fork ported I think). It is fast as lightning and runs well on older hardware. For me there are too much things missing and I only have so much time on my hands, therefore I stick to FreeBSD if I can. However Haiku gives a great glimpse into what could have been regarding personal computing.
