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?
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):
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.
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.
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.
AC.00-09 AC.10-19
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.
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)
I have an AC.ID which contains important quarantee receipts for things I have bought. Some have really long timespans, like 10yrs.
I decided to go for a single ID named AC.ID Receipts.
But that begs the question: how can I find the one exact receipt for the toolset I bought 5 yrs ago?
Answer:
I add that toolset as a keyword for my index. If I forget to do that, there still is only one logical place for that receipt to be so that would not be a problem.
I think that the ability to add index keywords is really useful and helps to save the amount of used ids without losing organization and findability.
