I’ve been wondering about how to retain flexibility w/ regards the folder structure after implementing the JD system. I’m just building my index at the moment before putting it into practice, and I imagine things might need to be rearranged at some point. Merging or splitting areas/categories, discarding an area and moving any remaining contents to different areas, etc. For example, what if 20-29 Area X becomes redundant at some point, do the areas behind it shift up (30-39 now becomes 20-29)?
Also, design software that relies on linking to files in specific locations (After Effects, Indesign, etc) might have a bad time keeping up with folder name changes.
I’m just starting out with the system, so this is very much the voice of inexperience, but a big part of the appeal for me is the constraints. I’ve had file systems that I can use freely for years, and it has not gone very well!
At the moment I’m planning out what areas and categories I want to use and the constraints are making me ask useful questions.
I’m a software developer, and the thing that will keep needing to grow in the system is the number of projects I work on. At first I thought I’d need to introduce dates into the folder structure, but I’m trying to constrain myself to categorise things more by topic. Gathering similar pieces of work together, even if they were done years apart, could have other benefits.
I still haven’t settled on my categories yet, but I’m enjoying the exercise.
Also, on the subject of files required to keep unchanged paths, maybe that could inform the choices of category.
10-19 Project assets
11 After effect
11.00 metadata linking the categories below to other things
11.01 project 1
11.02 project 2
JD says the numbers are just labels, not rankings or real numerical values. If we take that seriously, then we shouldn’t move 30-39 just because 20-29 disappears. The numbers are just arbitrary labels and a gap doesn’t matter. The possibility that numbers would change would also make it less likely for me to commit current number labels to memory.
Yeah try not to be bothered about gaps. I end up with gaps all the time, it’s cool. The numbers are semantically absolutely meaningless.
I get myself in trouble sometimes at work by trying to design a system ‘in order’. I try to make it pretty by having my categories in the order that they occur in a process, for example, rather than in the order that I thought about them.
If this happens, sure, it’s nice. But I find myself just delaying making the structure because I’m trying to get it ‘right’. Don’t do that! Don’t worry about the numbers, their order, gaps, whatever. Far far more important is the concept of taking everything, dividing in to at most ten, and then repeating to create categories. That is the heart of this system, really. (Ref. this comment.)
If you’re working on multiple projects then you almost certainly just need too use the multiple project syntax. And in each of those projects if you don’t use many numbers, that’s totally fine. There’s no fee to use extra numbers.
What are your thoughts about having different areas in different locations? For example, I have a work OneDrive where all my work stuff goes and a personal Dropbox where I store all my personal stuff. Would you expect the different locations to be part of the same JD system or have them each in different systems?
I can’t imagine that there is a “right” answer to this query. Personally, I suggest you go with your first instinct and combine or separate the systems if you find things aren’t working.
