Why does JD have nested folders?

10-19 Concepts 11 Core Concepts
21

A very good reminder. I should just bump my numbering from 000 to 0000.

The other thing I was exploring was whether it is ever useful to have structure. It seems useful, but is it a trap, as you said just now?

I suppose I’m just fascinated by the way structure flows up and down. Original JD: very strong case for keeping structure in front of the decimal, and content after (explained well in the Workshop). No mixing. By doing something like this (which is essentially an extension of your header IDs), you are adding structure after the decimal, without adding more depth. Seems like it breaks rules, and yet, aren’t many things in life fluid?

My partner was showing me the healthcare insurance declaration codes she works with. The numbers obviously have structure encoded in them. Also obviously, they thought about the numbering scheme up front, instead of adding things ad-hoc like I was doing here. And yet they choose to have a single list of 5-6 digit numbers, and not a folder hierarchy.
Or product numbers at a grocery wholesaler. Some are longer than others; potatoes are 11, cherry cocktail tomatoes are 321116. And again, related things have numbers close together.
So the question becomes: would one want to keep one’s product list in a Johnny Decimal system, or in a database (or why couldn’t it be both)? I.e. would your index contain 42.10 Product List (containing a spreadsheet or link to database), or 42.010002 Golden Delicious, 42.01003 Royal Gala etc?

(just something to mull over. Ignore if you have more important things to do).

22

Great point. I hadn’t made that link myself … maybe that’s why I’m reticent to endorse subheaders in the general case.

With ‘classic JD’, you make a structural choice. Two: which area, which category. And really it’s ’which category’ and you know which area that contains. It’s simple, quick, and a mental model you can actually hold in your mind.

As soon as you introduce more structure, you introduce more choice. More questions. This is already hard enough. Being organised. So I think we should be really careful about making it harder.

And so an argument for the subheadings that are in the QS:LA pack. They’re fixed now. That is a finished structure. So really they’re there to help you guide your eye. Would the system work if we deleted them? Totally. Would it work if we squished all those IDs up and left no gaps? Totally. It’s just a bit nicer with those headers.

So obviously this isn’t a hard rule. Like ‘don’t store files in your category folders’. That is a hard rule. But ‘don’t use headers’ is in the ‘strong guidance’ category. :wink:

Edit: oh, and ‘don’t store your product database as JD IDs’. Heeeeeellllllll no!

23

Yeah, I think the conclusion is pretty clear: this isn’t a good idea, except maybe in very specific cases where you need to have this structure in your Johnny Decimal system for some weird, important reason.
I think one of the prerequisites for where it might be feasible is where you know in advance what it is you’re structuring. In other words, don’t expect you can flesh out this structure as you go; but if you know that you have n levels that you really want to be visible as (sub-) IDs, then you could define a certain schema up front.

'Nuff said. Except …

again, don’t mind my rambling @johnnydecimal if you have more important things to do, but since this thread was started as a big heretical thought experiment, I thought I would continue that a bit. Because,

I take this to mean ‘it is indeed a very bad idea to store your product database as JD IDs’. But very strictly speaking, isn’t this simply on a continuum with the ‘creative’ or ‘freelance’ model? Johnny Decimal’s products do, in fact, have IDs, as attested in the product downloads and in screencasts of the Johnny Decimal system (The Life Admin Quick Start Pack is apparently 84.44.11). These are things you work on in a creative cycle, but they are also products people buy in a webshop. Over time, how many of these might accumulate?

Imagine a woodworker/furniture maker who has a line of about two dozen semi-standardized products: simple chairs and stools, garden furniture, a modular box system for making storage cabinets. Oh, and maybe some small things made in batches like cutting boards and wooden spoons; those always sell well. Customers can order these from a website, so it makes sense that they have product IDs so they can be tracked in invoices, shipping etc.

But at the same time, these are things which our furniture maker continues developing over time. Each is a project similar in scope and life cycle to a QSP or workbook or workshop. Material sourcing changes over time, the design gets tweaked, new variants developed. I think this would be perfect for an ID in a JD system.

And what about scaling to a large furniture manufacturer? Maybe not IKEA, but I know of a few medium-sized businesses (100-500 employees) in this sector, with a 200-page yearly catalogue etc. Chances are Johnny Decimal could help at least some of these companies organise their workflow quite a bit. I feel – here I’m squinting a bit – that it would make sense for this organisation to look similar to the solo entrepreneur furniture maker’s setup. Each product is something that needs to be the focus of attention. If a design team of 50 people is managing the catalogue update for 200 complex products, wouldn’t it be helpful if they could use those products’ IDs everywhere – in email subject lines, filesystem, etc?

Ok, I think I’ve made my point that I feel there is a continuum here. As to my original proposal – that you’d want to encode the hierarchy of these products in the ID structure instead of just giving yourself enough zeros to go for a while – I dunno, it could be helpful but isn’t really necessary. But I do find it interesting that I initially also thought you would obviously just have one ID for ‘the product database’ but when I thought of my area of work, it started to make more and more sense to bring that into scope. Am I missing something?

24

Ha! You got me.

They do, but mostly because I was trying to be cute. Johnny.Decimal can’t release a product and it not have an ID on it. What would people say?

Actually I don’t love how they worked out. Because tbh we didn’t give them much thought. They weren’t actually important.

For the record, here’s how they came about. This is super inside-baseball and I am not recommending anyone do this.

The workbook was first. Internally it started out as 41.11. We’ve since re-done that system but I think 41 was Products and this was the first. So that was the internal ID where we kept all our stuff. As you can see in video D85.90028 at around 09:00.

But then the product itself — the PDF — is organised by the JD system. Again, because it kinda had to be. Did it make perfect sense? Probably not. For example there’s text directly under a category header and not an ID which, if that were a file, would be a hard no. So we bent the rules.[1]

So now the question is, what is the full ID, in my global system, of those inter-book IDs? It can’t be 41.11.AC.ID. So the book needs its own SYS identifier, and the obvious choice was 41. Hence D41.

And so theoretically, though we never had cause to, you could refer to a section in the book as D41.AC.ID. Ta-da! :tophat::rabbit2:

The workshop came next, so it got D42. Actually IIRC in the old system we had 41 Products, written and 42 Products, visual or something. So internally it was 42.11.

By the time we’d released the QSLA pack, we’d re-org’d the D85 Johnny.Decimal business system. See again the video linked above. So now QSLA is at 44.11-.19 and I decided just to use that ID as its product ID. I could just have well used D44 and I think this decision was made really at the last minute after weeks of hard work and it didn’t feel important enough to deeply consider. If I’m honest.

Here’s a thought then: yes, you’re right, JD could be really nice for this sort of thing. But I suggest — without having really thought it through — that your product database must be a separate system to your internal business. B01.AC.ID contains all your accounting and any internal working that caused you to create that chair, and P01.AC.ID is the final, output, as-sold chair. For the reasons carefully explained that I blathered on about above.

  1. Although of course having an internal structure that you can refer to is tremendously useful. Documents at work do this and you end up with section 5.b.iv.G.aa. The way the law marks up their documents is also quite odd. If anyone’s reading this and is curious, ask me about it. Oh and do not trust MS Word to do these numbers for you without error. Also ask me about that. ↩︎