Extend-the-end `+` vs. `.01`, `.02`

J.D Concepts 11 Core concepts
1

(Cross-posting from Discord so forgive the chat-like format.)

thoughts please! here’s the situation.

i’m in my SBS, tidying things up a bit. so i’ve got some notes about LinkedIn (sorry) and specifically a video course i’ve got where the guy reviews posts and says what he thinks about them

so the correct place for LinkedIn is 14.53 (SBS link)

The general admin related to setting up and managing social media accounts.

and i need to EtE because LinkedIn doesn’t have its own ID. no problem

14.53+ LinkedIn

but now i want to create sub-notes, e.g. for this course. hmm

14.53+ LinkedIn+ Postlab course notes

works? :face_with_raised_eyebrow: but i don’t love it

other options. invent a shortcode for LinkedIn

14.53+LI then 14.53+LI+ Postlab notes

but then i’m thinking, well, why don’t i just add another number there. it feels simpler really

14.53.01 LinkedIn

14.53.01+ Postlab notes

that’s probably enough of a thought-starter. i guess the primary question is, does anyone hate the last thing where we just have more numbers?

i think it adds clarity. it gives LinkedIn a 1st-class ID

the only downside is, well, more numbers. but so what? it’s not like they’re confusing

thoughts please! it feels really weird not having sentence case in a forum thread. but i’m lazy :wink:

2

I think I prefer using three digits; IMO it feels more consistent visually. And I’ve swapped + for > because it just looks right.

I love the structure that the JD offers—it’s been incredibly helpful and life changing. That said, my brain works a little differently, and I’ve made a few small tweaks to help me process it more easily.

I do use three digits for really big stuff because it gives me a stronger visual anchor. I also use >instead of + because, for me, the + symbol feels like pressure to add more, almost like a mental weight. > feels more directional and spacious, like I’m navigating through a pathway rather than piling things on top.

This isn’t a criticism of the system at all. My brain just has low processing capacity and gets easily overwhelmed, so these small changes help with cognitive overload.

3

It’s so fascinating how these little things can make such a difference to each of us individually!

For me, I like having some indication of the higher level in the line. So the last example, 14.53.01+ Postlab notes, is missing an identifier for me. I guess it would be better in the context of a list, you’d see it belongs to LinkedIn … but I don’t know, for me the title is the part my eye gets drawn to, the numbers are really only to make sure everything has an address and sorts properly…

My other feeling is that this gives too much significance to LinkedIn (yes, I mean that in more ways than one). At the classic JD level you can still sort of memorize what each AC.ID number is. But with another extension, it’s too much! what is .01, and what is .53? Hmm, maybe it would actually work ok in practise and you’d remember which ones you created.
I guess I’m finding that flatter is better for me. Dividing 9999 things into groups of 10 is already good enough for narrowing the search.

4

I think we considered this – can’t find the thread with search, but I know we talked about it here – but ruled out > because isn’t it illegal in a Windows file path?..

But whatever, if it works in your circumstances, I totally see why you’d like that.

5

So you’d go with 14.53+ LinkedIn+ Postlab course notes?

The reason for this format specifically is that it encodes the fact that 14.53+ LinkedIn is its own entry. Because anything immediately followed by a + is, by definition, a JDex entry that has been extended. Even if that thing is, itself, a JDex entry that has been extended.

  • 14.53 = a JDex entry

  • 14.53+ LinkedIn = an extend-the-ended JDex entry

  • ▔▔▔▔▔+

    • whose parent is 14.53, which is a JDex entry.

  • 14.53+ LinkedIn+ … = an extend-the-end-again JDex entry

  • ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔+

    • whose parent is 14.53+ LinkedIn, which is a JDex entry.

It’s this twice-extended thing that I’m cautious of. But as I know these aren’t notes that I’ll need to refer to from elsewhere – I’m not going to print this identifier on a document, say – then I’m okay with it in this context.

6

It’s been fine with my apple eco system :slight_smile:

1 Like
7

System context probably is important here. I interact with my JDEX primarily by filtered grep or find searches.[1] Every result is a line, so when I type to filter, if the keyword is not on the line, the line disappears[2]. Hence I want the whole hierarchy duplicated on each line.

If you’re doing more of the filtering with your own visual system, then a graphical hierarchy works. If you’re relying more on finding the parent first and then navigating a path of links, then you also don’t need this.

  1. ripgrep and fd to be precise. ↩︎

  2. completely unrelated rant. This is the main problem I have with all Internet Browser History interfaces I know. you run a search, and they show you only the matches. When 99 times out of 100, I’m trying to find something for which I don’t know the name, but I do remember the names of things that came before. The nature of web browsing is precisely that you click around links on sites you already know, until you find a link that takes you somewhere new. But Somewhere New is still unfamiliar, so you forget the name. Later, you need to be able to find all occurrences of Familiar Place so you can select the one where Somewhere New came right after . A history search feature should take you to that point in the fully intact chronological list, highlighting the results, so you can see what came before and after. I’ve tried writing blog articles about this many times but I always fail because my blood starts boiling. It seems like the biggest UX fail ever, and it’s especially frustrating because all this information is right there in a relational database. So now at least I’ve snuck this observation out into the Internet via this footnote. ↩︎

1 Like
8

Just my 2 cents.

The whole reason why I was/am so attracted to the JD system is its simplicity and shallowness.

Adding EtE has always itched me a little.

This discussion to me looks like we have reached the boundaries of the basic concept.

9

You nailed my concern. With the double-+ I feel like I’m down a hole with no reference. (Even though I’m not, really. I can find my notes real easy. But there’s a feeling that I am.)

But what’s the alternative? LinkedIn isn’t going to get its own ID in this system. There’s no room[1] and it doesn’t deserve it.

  1. Unless I create another area and I’m not going to do that. ↩︎

10

I’ve always imagined that an ID will never contain more items than I can either scan visually or narrow down with a query, without breaking my flow, provided everything is tidy. I haven’t gotten any IDs that full yet, but that’s what I’ve always assumed. And if it does become a problem, then it should become it’s own area/system whatever; that’s a clear tenet of JD.

So I guess why add more identifiers? Surely LinkedIn is unique enough within the contxt of 14.53? Just like for @Jayde20 the +/> distinction matters, maybe for @johnnydecimal having some kind of mark feels significant, just like I get irrationally nervous if the full hierarchy isn’t in the path …
My point being, perhaps here we reach the level of ideosyncracy.

11

I look at it like, in the context of this system – SBS – can I find the thing, and does its level of granularity work in the context of that system?

Because remember, we’re talking the entire contents of my business here. What percentage of that does the entity that is LinkedIn ‘deserve’? Very little, I say! As much as a single ID? Apparently not: unless I do a massive amount of business there, and then I could create an ID for it somewhere in 31 Marketing, PR, & communications.

Maybe that’s the solution? In fact, I had this there until Lucy reminded me that 14.53 Social media existed. Hmm.

Maybe 14.53 is a simple bucket for simple folk who really don’t have much by way of ‘social media’ to manage.

By posting this thread, I’ve self-defined myself as being out of that category of people. LinkedIn for me has become something larger, and thus deserves its own ID.

The key, then, would be noting this in 14.53 so that I don’t become confused when I do go looking there.

12

Again an exciting post!

A JD principle is: Make it as simple as possible and as complex as necessary.

Why don’t we use the Dewey Decimal System? Because it starts with too much space!
We want to keep our classification as shallow as possible.
Ok — but then reality strikes, and we classify from general to more specific… and run out of space.

Should we switch to DDS? No.
But we could rethink how we use EtE.

I prefer to have two or more levels of SUB IDs for a simple reason:
:backhand_index_pointing_right: It makes sense for our brain.

No classification system pushes more-specific things out to a level of equal specificity.
Our brain expects structure to go from general → specific, and it costs mental energy to break that.

It also runs against how classification systems normally work.

So, if + + + starts to feel cluttered, maybe we take inspiration from DDS.

  • We keep AC.ID as our stable root.
  • The + still signals a subdivision — of any depth.
  • But we introduce optional decimal-style numeric subs under the +.

For example:

Instead of:
14.53+LI+ Postlab course notes

We get:
14.53+11 Postlab course notes

Alternatively, to indicate depth more clearly using dots:
14.53+1.1 Postlab course notes

We could just let go of alphabetical sub-IDs altogether and fully embrace decimal-style subdivisions after the +.
This keeps the ID sleek, the order logical, and the depth optional.

PS: I also never use the expanding signifier + without an identifier.
If you expand it, it deserves an identifier — in my point of view.

Everyone should still be reminded:

Keep the classification as shallow as possible —
but sometimes, it just makes sense to go deeper.

So that’s my personal, spontaneous take on it.

3 Likes
13

I … really … like … this.

Again, it’s my feeling that JD has become this thing whose goal is to take you from the whole world and everything in it, through the levels of chaos, down and down, until you reach a place where you can do some work. That place being an ID.

Ref. this YouTube if you’ve not seen it.

So then the question to ourselves becomes: at the ID that I’ve found – 14.53 Social media – do I feel like I’m at that place? For me, currently, the answer is yes.[1]

Alternatively, think about it like, if you were at work and someone new started. Hey Steve, go and brush up on that LinkedIn course, it’s in our social media folder. Just search the JDex, you’ll find it.

Steve’s going to find 14.53 and now, if there are a handful of folders for each of our social media platforms, and inside the one neatly labelled LinkedIn there are a handful of folders and one of them is Postlab course, is Steve going to be okay? I think he is.

So let’s ask ourselves, at what point might Steve be confused? Well if we have dozens of social media platforms and within each of those we have dozens of artefacts, that might be a bit stressful. He might not be able to find his things quickly, with more confidence, and less stress.

But at this point we’re really in to social media, clearly, and need to think about giving it more room than the meagre single ID we designed for it. We might even have hired Steve as Social Media Manager, it sounds like we need one. And so we probably promote it to 31 Marketing, PR, & comms and maybe even end up with a header 31.10 ■ Social media platforms.

So back to this notion of IDs-after-the-+. Here’s what I might do. Tell me if this is too cute.

I want 14.53+__ in the first instance. I don’t like the idea of using LI as a short identifier because, while 2 letters works for LinkedIn, it doesn’t work as well for other platforms.[2] So what if I used 12, being the 12th letter of the alphabet? Then future stuff will sort above/below LinkedIn as appropriate.

(There’s an assumption here, which is that I’ll never have more than 26 social media platforms to manage. And not every one must get its ‘proper’ place in this list, it’s just a rough guide to keep L below A and above Z. So if I inexplicably start using LiveJournal, it’ll just have to be 13 and that’s fine.)

So we’re at 14.53+12 LinkedIn

Feels very neat indeed. It’s very obvious where we are. And now if I want those Postlab notes to have their own note, I don’t need a further ID. They don’t need one – this is more than enough. Because now I can extend-the-end of 14.53+12 with the pattern that is just a plus, a space, and the title of a note.

14.53+12+ Postlab course

Recap: the two styles of EtE

This needs its own blog post, which is on my list.

  • Style 1: AC.ID+ID <Title>

Here, after the + an ID immediately follows. No space. See above: 14.53+12.

Obviously in this case you created an additional ID that you can reference from anywhere.

  • Style 2: AC.ID+ <Title>

Here, we don’t need an ID. We’re just typing additional notes on the main entry, but we want those notes in their own file. This is just like taking a single file that looks like this:

# 14.53 Social media

## LinkedIn
Just some notes yada yada.

## LiveJournal
Wait what?

## Yammer
Kill me now.

And turning it in to 3 files:

# 14.53+ LinkedIn

Just some notes yada yada.

# 14.53+ LiveJournal

Wait what?

# 14.53+ Yammer

Kill me now.

I find this much clearer than a long note with many headers and I’m using it liberally. In this case you did not create an additional ID that you can use anywhere.

Back to Postlab

The question is, do I need a unique ID to Postlab or am I just keeping notes on a LinkedIn thing? And the answer is the latter. So this is enough.

14.53+12+ Postlab course

And I think we’re done.

  1. As always, if an ID starts getting out of hand, you should promote it in the future. Split it up in to multiple IDs; create a category; something. ↩︎

  2. I prefer this pattern where there’s a very obvious initialism to be had, e.g. your family’s initials. ↩︎

14

Update: Lucy says I’m crazy. This isn’t what 14.53 is for. That’s just for simple admin-level details about my LinkedIn account.

I need to be creating a LinkedIn ID up in 31 Marketing etc.

Just had a long chat which has turned me back in @trintera’s direction. This needs to be much simpler.

Have thoughts, will form.

15

I understand the tension now better. I always looked at the ID as an address—like that of a building. And the building contains all the stuff that matters to me for the work I want to get done, including floors, rooms, etc. However, some buildings become more complex over time! So we may need to specify the address, the staircase, and the door.

The fundamental tension arises from the fact that we notice someday: “Oh no, this building became too complex. Every door now deserves its own address (ID).” Maybe. Maybe not. What is more important? Shallowness/short ID, or familiarity/less effort with your existing structure that has grown over time? Since we can search by ID, we can just type it into the search bar and get fast and reliable access to where the work—and everything we need for it—awaits us.

So does shallowness trump familiarity? I don’t know. Me, personally, I think I would just let things grow as they do and where they are. And when parts of it deserve their own ID, just slap it with an extended optional ID. It’s easier in my mind.

16

Here’s where I’ve landed. This still needs deeper thought but this will do for now.

What’s made me uncomfortable about this for a while is that I can’t clearly explain all of the ‘rules’, end-to-end. See: this thread! I have a couple of ‘ideal users’ in mind, none of them sophisticated nerds, and my goal is that all of these concepts must be crystal clear to those people. If they’re not, there’s a problem.

So there’s a problem. Which makes me lean back towards @trintera’s view: keep it simple.

The clear case: extending ‘across’

When you’re extending an ID with more of the same thing, that feels easy. A popular one in Life Admin is, how do I save the kids’ passports?

We have 11.12 Passports, residency, & citizenship, so the base one of those things is yours: your passport. And if you want to manage the kids’ passports, you EtE using their initials or whatever. Here, you’re not going down in a subfolder sense. You’re extending across. No problem.

z-CleanShot 2025-06-07 20-01-12@2x
z-CleanShot 2025-06-07 20-01-12@2x1002×208 9.81 KB

Similarly, tax returns. 13.34 Tax returns & accounting includes 2023, 2024, and 2025. But they’re all just tax returns. There’s no nesting of a concept.

Don’t extend ‘down’

Whereas, LinkedIn was a child of 14.53 Social media. It was, itself, its own thing. Which then demanded its own child, Postlab notes. And now we’re way down some rabbit-hole.

z-CleanShot 2025-06-07 20-45-28@2x
z-CleanShot 2025-06-07 20-45-28@2x570×642 19.5 KB

Bonkers! Absolute nonsense. Crazy talk.

My solution

LinkedIn needs its own ID in 31, probably under a heading 31.0_ ■ Social media platforms.

17

I see the point made, and I now understand that JD is not a classification system.

We like to nest things from general to more specific — but you’ve made it completely clear that identification is more important than classification. So JD isn’t about organizing by type; it’s about assigning a place where work gets done — an index that doesn’t convey a hierarchy of meaning, beyond area and category.

That means we break things out and throw them somewhere else when they grow beyond their original scope.

I’m not yet sure how I feel about that rigorous approach. I’ll have to think about it.

1 Like
18

Yay for @LucyDecimal!
Saves me reams of commentary. Always a relief to find you’re not crazy, and you had designed for this.

Two things I will say. First, probably the total complexity can never be reduced - just moved from place to place. A complex organization system will always take skill to operate. Skill which must be learned through instruction and experience.

Second, indeed JD is about finding things for doing work. I was going to mention this in response to the increasing complexity above. In my shop, I have hundreds of individual tools and supplies. I can instantly think of every single one as soon as it becomes relevant to the task at hand - it’s finding them that was the problem until I JD’d my shop a few weeks ago. Now I have a two-step path to every last type of screw and nail. The last step is still a jumbled box that takes a minute to look through, but now I know that what I’m looking for is in that box.

Combining those two, the new hire is always going to need instruction. Just to know what goes in 13 and what goes in 53. So in my view, the documents pertaining to LinkedIn can be in their own format, it doesn’t matter, consistency is nice but you can’t force each tool’s documentation into a standard format. Just like a track saw, a hand plane, a router all have their own instructions and storage etc.

3 Likes
19

I know recognize the shortcomings of my classificational mindset. Establishing semantical hierarchies especial encoded into codes/indices are brittle when systems evolve over time (and most do). More general or finder granulared concepts or overlapping concepts may force users to restructure their systems over and over again. I know that codes in an ideal dynamically evolving world shouldn’t convey any meaning at all! It’s for us humans who like semantically meaningful codes. So not caring about semantical structure on the ID level makes kind of sense now to me.

However, EtE seduces the user into assuming a semantic hierarchy. In reality, there’s only a structural grouping of Sub-IDs — not a semantic one. You could just as easily assign each item a full ID scattered across the category. EtE is simply a convenient pattern for repetitive items.

20

I’m currently in the throes of taking my company’s Pre-JD administrative file index (mostly dating to 2006) and trying to JDify it, so this whole conversation resonates. So, to your point, every room in a big building does have its own address. If you were to send snail mail to an office, the required address is:

  • street address
  • city, state (for the US, region of some kind elsewhere), country, postal code (in most countries)
  • company name and/or suite number.

The second line is the JDex area, the first line is the JDex ID, the third line is, in the original JDex set-up, a named and unnumbered folder within the ID. In other words, every suite - defined as a work area of some size with one door facing the public - has its own address. In mailing addresses, the door usually has a number. There are three scales at work: the city/area, which gets you in a recognizable location out of the entire world; the street/ID, which gets you to a single spot; and the suite number/item, which gets you exactly where you want to go.

Note that the postal code can be used as a purely numeric substitute for the city/state/country; just as the suite number can be used as a numeric substitute for the company name.

Other than stating the obvious, here’s my point: no one balks at having to know all three items when addressing an envelope. I don’t think it causes any cognitive overload.

3 Likes