A folder between categories and IDs?

Hey, Ive read the whole website few times over the past years, and the relevant section just a moment ago.
Why in the JD system there is no folder between categories and IDs?

So instead of:
10 Areas > 10 categories > 100 IDs,
it would be:
10 Areas > 10 categories > 10 “subcategories” > 10 IDs.

1 Like

Because there isn’t! :upside_down_face:

But funny you ask: in ‘life admin’, we introduced headers that kinda do the same thing.

I recommend using them with caution:

1 Like

I have sometimes wanted to do what @Karjala suggests, but have found it useful to resist. The question is whether there is a good enough reason to break the JD rule of 10 areas, 10 categories, 100 IDs. Imposing structural rules up front makes other decisions easier. More subfolders/levels of organization would change the AC.ID structure by making the ID part less random. But would they make the IDs more meaningful/memorable?

I agree 100% with @johnnydecimal‘s caution about headers. In the end, it rarely matters whether two things in the same category are subcategorized under a header with contiguous ID#, or have IDs that just reflect when they came up in time relative to the other things in that category. But, as I set up my system and reorganized existing files, it made sense to organize closely related IDs under a header and since I had room to allow for this in my numbers, I did.

I also make use of two kinds of sub categorization that @johnnydecimal fully endorses

  1. To organize files within a large ID: see the discussion of ‘all short trips’ here: 11.06 Saving files • Johnny.Decimal

  2. To extend the end of an ID that relates to several people or projects, see the + notation described here: 13.31 Extend the end • Johnny.Decimal
    and here 13.32 Guidelines • Johnny.Decimal

2 Likes

I have grappled with this too sometimes. Feeling like there’s too much of a jump from one level to the next. @johnnydecimal has written/vlogged (?) about how IDs have gradually increased in scope over the years. As @njmatch3 points out, all short trips are now inside one ID, whereas ten years ago Johnny might have recommended each of them being their own ID.

When you’re putting something somewhere, the less depth, the better. Then when you’re looking for something, if the categories and IDs are well-designed, you need surprisingly little specificity to know where to start searching. And then with full-text search and filtering you’ll find what you need pretty quickly. Even if searching for something still takes a little while, you know for sure that you’re looking in the right place which makes all the difference psychologically. The more options there are up front, which would be the case with another level, the more places something could be, which induces anxiety both when saving it and when looking for it.

(and I think most of us have way less stuff than we think, once it’s well ordered. So there won’t be that much to look through anyways).

I experimented with a more fluid type of ID hierarchy, where by using alternating numbers and letters you can nest new ‘sub’-things without breaking the order. But I concluded that it is more hassle and confusion than it’s worth. It’s possible to encode a hierarchy of knowledge with great precision, but for that information to be useful you have to use it with skill too and for 99% of things it’s just extra noise that distracts you.

3 Likes

100% to both of these responses. :pray: