Hi all! I’ve searched around the forum and I can’t seem to find a post addressing this directly. If there is one, please feel free to point me to it!
What do you all do when you need to combine categories or otherwise change them? Do you go to every place using JD and make the update at the same time? For example, I have the same JD structure in my Google Docs and my physical file cabinet. If I merge categories in Google, do I need to immediately go and merge them in my physical cabinet?
Here’s an example, to demonstrate my question. Say I have files both in Google Drive and in my physical file cabinet with the following structure:
10-19 Properties
10 Property 1
10.01 Property 1 Lease
11 Property 2
11.01 Property 1 Lease
Imagine I decide I want to change this structure to:
10-19 Business
10 Properties
10.01 Property 1 Lease
10.02 Property 2 Lease
In order to change this, I’ll need to update both my physical file cabinet and my Google Drive. Additionally, any emails I tagged with 11.01 will no longer be correct.
Is there a good way to go about this, or is this friction just something that needs to be accepted when using this system?
Thanks for your reply! I actually have a solution I’ve been trying out, but I didn’t want to clutter the main post. I’m hoping someone out there has a better idea—or can improve on this one… it has some drawbacks I will detail below.
A Possible Solution
The short of it is: I give folders unique names that don’t change, then refer to those names in the index. This way, I can rearrange my index to my hearts content. To easily produce unique file names, I simply use the date and time, like so: 2021-1214-2209-21 --- Property 1 Lease.
(That’s YYYY-MMDD-HHMM-SS, meaning I can create a new folder every second without overlap. Probably overkill, but I like the precision.)
“Future Proofing” the index by making refactoring instantaneous. This allowed me to start using JD immediately, without the recommended week to “let it simmer”, because I know I can change the index at any time.
A record of exactly which storage medium each folder exists in. This makes it easy to spot places where duplication might be reduced (by scanning some papers into Google Drive and eliminating the physical folder, for example}. It also makes it easier to include unusual storage locations more easily into the index (see the example above with “Garage”).
The Cons
File systems are now entirely “flat”. My GDrive looks something like:
2021.1010.1445.02 — Foo
2021.1014.2040.01 — Bar
2021.1014.2053.01 — Baz
2021.1017.1913.01 — Bingo
“Muscle Memory” advantages are decreased, but not eliminated. My “Foo” folder will have a different timestamp in my Google Drive than in my physical file container. However, I find I still have muscle memory for my most-used folders in any given file container, that muscle memory is just container-specific.
Lookup is now more reliant on the index (or search, if digital and quick). Each file container does not replicate the index hierarchy, so I have to actually get out my index if I want to take advantage of its structure
This structure still breaks if I try to point to it from the outside, like labelling an email with [11.01] per the example documents. This can be addressed by again using unique labels and another table, as described in “Remediation” below. However, it’s just more stuff to maintain so
Remediation
To address the problem of labelling an email with 11.01 and then changing the index and breaking that link, I might try implementing another table that serves as an intermediary. So this table might have:
0001 => 10.01
0002 => 11.01
etc…
This could then be changed to:
0001 => 10.01
0002 => 10.02
If I label my emails with “0002”, that label wouldn’t need to change even if the index is rearranged.
In order to alleviate some of the overhead this method adds, I’m considering “setting in stone” certain categories that are very unlikely to change. These categories would be set up the “normal” way inside their file containers. For example, if I’m very confident I’m not ever going to change 10.01 Property 1, I might create that folder inside my file container in the usual JD way with nested folders.
Conclusion
Anyway, I’ve been wrestling with this for a while now, so I’d like to throw it out there and see if anyone has any thoughts on improvements or alternatives. Thanks for reading!
Very clever solutions … but after using this thing for years, the number of times I’ve actually had to re-arrange is few. I think you’re better off just ‘thinking on it’ for a while before you start!
Having the files in the JD structure in your file system is so nice. I think you’re planning for an event that rarely happens and in doing so you’re negating many of the benefits of the system.
But it depends what your goals are. If guaranteed immutability of an ID is one of them, I see where you’re going and, like I say, it’s clever.
Agreed, the overhead cost is high. I think I may go with the plan to “set in stone” certain categories that I am very confident in (by implementing the standard nested folder approach), while maintaining this alternate implementation for things I’m not sure about yet.
Unfortunately, because I’ve got a lot going on, I need my files to be at least semi-organized while I mull over my index structure. This way I’ll be able to take advantage of JD benefits while still maintaining flexibility to consider the unclear bits.
