I’m trying to implement this system for myself, but when dimensioning my system I’m trying to figure out whether the granularity is sufficient.
Which leads me to the question; how much content do you keep inside a unique ID? The screenshots in 11.06 is three files which are all seemingly independent. (None is a scanned copy of another, etc) I expect that sometimes you end up with just one file and sometimes you end up with maybe hundreds (or even thousands) very closely related. (Like a dataset split into several files) But ignoring those cases, what is your gauge on how much information to keep inside a single ID? Obviously keeping unrelated items inside a single ID is a red flag, but do you have any other red flags for when your ID is too large?
I hope my question makes sense!
Hey, great question.
On average, if I think back on all the stuff I’ve done, I’d say ‘a handful’. 3, 4, 5? Thereabouts? But obviously it depends.
But some have fewer – 1, or zero if I’m just tracking a note – and some have way more.
Example from just this morning. We’re putting together some video to demonstrate the problem of lost knowledge at work, specifically as it relates to MS Teams. Here’s how it looks (ignoring all other folders):
└── 51 Image & footage library/
└── 51.03 Visualising the Teams hierarchy using MindNode/
│ ├── BC-AC_FoamRubber-320bit.mp3
│ ├── BC-AC_Komiku_-_02_-_Remember_the_time_we_use_to_play.mp3
│ ├── BC-AC_Monkeys-Spinning-Monkeys.mp3
│ ├── BC-AC_Sad-Piano.mp3
│ ├── BC-AC_Scheming-Weasel-faster.mp3
│ ├── BC_alex-productions-sad-piano-music-children.mp3
│ ├── BC_barradeen-bedtime-after-a-coffee.mp3
│ ├── JD_Morning-Routine-Lofi-Study-Music.mp3
│ ├── JD_Still-Awake-Lofi-Study-Music.mp3
│ ├── JD_When-I-Was-A-Boy.mp3
│ ├── JD_alex-productions-lo-fi-fashion-chill-hip-hop-2021.mp3
│ └── Music.md
├── 01 JD structure expansion.screenflow
└── 01 JD structure expansion_LB.screenflow
You’ll see we’ve broken the rules and put folders in our JD folder here. Now that I look at this we should probably move
Music out to its own folder in
51. This is because we might use this music elsewhere. (If there was no chance of us ever using it anywhere else I’d be comfortable leaving it here.)
That would just leave a bunch of ScreenFlow files in
51.03. We’re not finished yet, there’ll likely be half a dozen in here when we are.
As a general rule I’d say ‘no more files than you can view on a screen’. You shouldn’t have to scroll. But as always there will be exceptions.
The golden rule is that you can find your stuff. If you find yourself hunting through a folder for a thing, there are too many things in that folder.
Thanks for the reply!
What is your thinking of ‘grouping’ sequential items with a shared ID?
You have an example of payrolls, but these are given individual IDs. Why make a single payroll ID and keep all of them there? (Assuming they are all single files)
This is the key. If they’re all single files, sure. Group them up. But will they all, always be single files? Can you be sure?
There’s no one rule here. Every case is different, you just have to decide as you go. I tend towards being more granular though: like I say, if you use all 100 IDs your category was probably too broad.
IDs are cheap! Use 'em all.
What scares me a little with too many IDs is the loss of spatial relationship between related IDs. If these are related but created days or months or even years, apart they will be interspersed with other other IDs which may or may not be related. In a non-ID setup you can group items by having common prefix, etc.
But on the other hand all IDs are sorted chronologically, so they are related in time instead.
You allude to this in 11.03, but what are your thoughts on grouping vs. sorting?
By the time I’m in a category, and thus viewing my IDs, as far as I’m concerned this is ‘organised enough’. It’s certainly way more organised than I was before.
I think trying to go further is over-optimising.
That said, there’s nothing stopping you using IDs in ranges.
and so on.
Or occasionally I have started a new ‘group’ of IDs at, say
AC.50 if I wanted to ‘shift’ them away from the others. But honestly I’ve never really enjoyed/felt comfortable doing that. Now you worry about whether you’ll ‘bump up’ against that higher number in the future and you’re over-engineering. At this point decision fatigue kicks in and I find myself just putting the thing on my Desktop instead of potentially making a bad decision.
I think trying to go further is over-optimising.
Good point! I frequently fall in this trap…
I agree with not assigning ranges. It feels like a way to build in an implicit system at arbitrary points.
Thanks for all the input!
What a great way to put it.
Today I (for some reason) realized another drawback with attempting to group IDs.
It’s actually the same drawback as folders; sometimes you want to have a file in two places. JD mitigates this by having at most 10 items in each level, so it reduces that risk. But that won’t work if you have a hundred.
Temporal numbering doesn’t suffer from this. Chronologically is always chronological. You can’t go back in time and create an ID before another was created.
It also has another advantage; the items you worked with the latest (i.e. created the latest) is probably going to be the ones you need to access most frequently.
(I guess this also implies that you should sort your system in descending order, or number it in reverse)
Anyway, just a thought that occurred to me.