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.)
My index might then look like this:
- 10-19 Properties
- 10 Property 1
- 10.01 Property 1 Lease
- GDrive: 2021-0114-2209-21 — Property 1 Lease
- Physical: 2021-0102-1005-34 — Property 1 Lease
- 10.01 Property 1 Lease
- 11 Property 2
- 11.01 Property 2 Lease
- GDrive: 2021-1214-1904-03 — Property 2 Lease
- Garage: Box beside the workbench labelled “Property 2 Lease Doc Stuff”
- 11.01 Property 2 Lease
- 10 Property 1
Or it can just as easily look like this:
- 10-19 Business
- 10 Properties
- 10.01 Property 1 Lease
- GDrive: 2021-0114-2209-21 — Property 1 Lease
- Physical: 2021-0102-1005-34 — Property 1 Lease
- 10.02 Property 2 Lease
- GDrive: 2021-1214-1904-03 — Property 2 Lease
- Garage: Box beside the workbench labelled “Property 2 Lease Doc Stuff”
- 10.01 Property 1 Lease
- 10 Properties
The Pros
- “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!