At least I decided one thing. This is live!
Curiously, this phrase has never appeared on the internet.
I hate to break it to you, I really do, but there is actually a book with that tagline. (Using MS Word and hyperlinks)
Aaaah I’m spelling it with the English ‘s’. I thought that was weird.
Have you read the book?
I haven’t. I think the tag line it’s great! And appropriate. I feel quite humbled you went with it.
Now, if you excuse me, I need to go fetch my “well actually…” label. It fell off somewhere.
How about “your JD”? JD is a system to organize your stuff, so your implementation is “a JD”. I can see why you wouldn’t go this route…
My vote is for system, even if it’s ambiguous.
1 Like
I would still call the meta area 00-09 System. I have my individual JD System with my own selected techniques, tools, and behaviours. And this area is where the meta things about my personal system go.
Collection of indices sounds strange. Isn‘t an Index something I refer to, to look up things. So it is not the areas that are my index. Preferably I should have one Index per domain.
I don‘t know, but to me everything feels understandable and good as is, except for the term ‚project‘, so I would not change too much.
The more I think on this the more I agree.
‘System’ is just too natural. I’m trying to fight it, and losing.
Coming to J.D recently and this discussion late, however as someone steeped in Systems Engineering, I like the ‘systems thinking’ going on here! Fundamentally, the definition of a system is:
- It has a purpose or primary function (I like the “organize your life” one!)
- it is composed of system “Elements” (perhaps even sub-systems themselves) like the Index, Areas, etc.
- these system elements are “interconnected” - they support and depend on each other to provide for the overall purpose/function of the system
- and, especially, it’s the interconnected behavior of these elements that enable the overall “system” to provide something which “is beyond” the collection of elements by themselves without the interconnections. – I.e. the “whole” is greater than the “sum of the parts”.
Most often, people start/stop with the Elements (or parts) as if that’s the full description of the system because they are usually the easiest to see and discuss. Your car’s purpose is to drive you and your family around. It has a seating, engine, control, drivetrain, etc. We can debate the elements/parts, but it’s the interconnections of them all and how they support each other that enable the car to satisfy its purpose.
Those interconnections are worth spending some time to describe (even visually as you are doing with your 'system block diagram") that illustrates how everything works together. You already have those down in your explanations of how we go wrong with our digital lives now and how the J.D addresses the ‘organize your life’. Apply them visually to your system block diagram and it will help you not only communicate but likely refine your thinking further on the J.D ‘system’.
1 Like
I think this may be the best argument for an index (see New user / index confusion/thoughts) - there are things I can’t put in a filing system (or due to computer system requirements they have to go in some special area and I may not be able to name their folders (or even the item itself))… but I can still put an entry in the index that points to it…
I just had a thought about this - indexes is a geographically confusing term - as it’s uncommon outside the US where indices is the preferred plural.
Library is better as it’s a universal and clear term. JD is a global methodology or system for everyone, so I’d avoid the indexes/indices bear trap.
Good point – but I cannily avoided it by not using the term ‘collection of indexes’, in the end. 
Here it is. Feedback very welcome, though I think I’m set on this.[1] Lucy and I have given it a lot of thought, in the context of all of the material we’ve already written and the Workshop which we’re in the process of producing.
Let’s not forget where this all started. @talundbl, does this answer your question?
If nothing else it’d be a real pig to have to re-do those screenshots! ↩︎
1 Like
It looks and sounds wrong to me. It feels correct to me when it’s indices. Have I got that wrong?
Yeah - you’ve made it official now. Don’t overthink it.
Alright, I will challenge the status quo one last time, given you’ve put many days of thoughts into this. I’m not trying to be difficult, but there’s a challenge I see with the philosophy of things as they are.
If we say “computer” or “phone” is the level of component that merges systems, then everything will end up merging. How do you avoid “internet” or “e-mail” or “calendar” being a component that merges everything? Sure, you can use separate emails or calendars or phones or computers for everything, but I would say at least in my life the advantage of JD in the first place is using it to have a mental location of where to find something. If we use JD as a way to define how to divide things more, sure, we made it more searchable, but I don’t think that we actually made things more organized.
Some amount of organization in my life is specifically to minimize functional duplication. I don’t want to have to open 3 separate calendars to figure out what’s happening in my day. I want a central, indisputable authority for my time management.
Either JD is a philosophy to segregate systems and make individual parts of life more organized, or JD is a system to centralize life and make the interaction of systems more manageable. I’m not sure it can be both simultaneously. I instinctively assume and prefer if it was the latter.
Unless I’ve misunderstood something, I believe JD’s power is really hidden in the second potential, not in the first.
When I talk about shared components, what I’m saying is that:
- If you have more than one Johnny.Decimal system,
- and if those 2+ systems share a component — say, your email account,
- then you SHOULD use the extended
SYS.AC.IDnotation with those systems.
Because the scenario to avoid is that you have two folders in your email labelled 11.01 and one of them relates to system A and one of them relates to system B. It might then be the case where you are confused as to which is which.
(Not when browsing your hierarchy, but when viewing search results.)
Whereas if you label one folder A10.11.01 and the other B20.11.01 then you have removed this ambiguity.[1]
Correct. But if you label calendar entries with JD IDs (I generally don’t), what I’m saying here is that you SHOULD label them with the full SYS.AC.ID identifier. Otherwise when 11.01 pops up as an appointment, which system does it relate to?
The counter-point
This is relevant because sometimes you manage a collection of systems and one of them is in a silo. Here’s the scenario.
- At home you manage multiple systems. They’re in the same domain so they need the
SYS.AC.IDnotation. - At work, which is its own domain, you manage one system.
- This system is totally isolated. Nothing at work touches anything at home.
- I had this in previous jobs. No overlap whatsoever.
- And so in this scenario, this work system does not need the
SYS.AC.IDnotation. - Because there is nothing that it could be confused with.
- This helps because you don’t have to encumber your colleagues, who already think you’re weird with all these numbers, with a
SYS.AC.IDnotation. You can use the simplerAC.ID.
Am I just confusing things?
This might not be a point that’s worth making … I wonder if I’m making it more complicated than it needs to be?
This is certainly an edge case. A 1%’er.
I think I just remove it…
Hmm but then I wouldn’t recommend naming every folder with the full
SYS.AC.ID. That’d be tiresome. So this wouldn’t benefit you anyway. ↩︎
Two notes on this front:
First, this exact complexity is inherent to the problem, I think. E.g. In the workbook/old website you had something like “trip to thailand - 11.26”. I remember reading that and thinking “I wonder how many projects will have a trip to thailand as part of them?” Trying to unify AC.ID notation across domains cannot work if we define each domain as having an independent structure. Then the needs of one confine the other. On that level, this is not an edge case. This is the crux of the problem of organization of life. We need varying expertise and depths to deal with varying scale of problems.
Second, I believe the confusing part is the language, not the conclusion. It wasn’t clear to me on first read that it’s the notation that you suggest helps fix this problem. Of course that’s the case. The whole methodology is assigning unique IDs. But to me it sounded like a segregation problem: I was stuck thinking separate bookshelves, not separate addresses.
I came here from the blog post about projects and systems.
I just want to applaud the decision.
Having heard about the JD system (ha!) from Obsidian forums, I learnt about it and thought I understood the basics, until I bought the workbook.
Then I got totally confused by projects, as I thought you were referring to files about projects I was managing and didn’t realise that you meant something else.
Now I need to read the workbook again, and firstly decide how many systems I should use
1 Like