# The JDex

> A Johnny.Decimal index (or JDex) is the master record of a system's IDs. It keeps you even more organised and transforms how you work.

## The index _is_ your Johnny.<wbr />Decimal system

A Johnny.Decimal index (or JDex) is the master record of every ID in a system. It can be kept in a few ways; I recommend using a notes app.

Some people push back on keeping an index because it's extra work. But they haven't realised the pitfalls of not keeping an index versus its advantages.

I consider this more important than your filesystem and encourage you to try it. It takes less time than you think, and you'll find many ways that it helps you be more organised.

The index _is_ your Johnny.Decimal system. You need to be sold on this concept, so let me convince you.

## Why I love my JDex

### I know where everything in my life is

Until recently the main place we looked for things was our filesystem. But now there's so many places a thing can be.

Email, chat, cloud storage, hard drives, servers, apps, collaboration software, calendars – the list is long.

The index solves this problem by giving you a place to note an item's location. Simple.

<JDLineDiagram
  text={`
┌──────────┐      ┌─────────────────────────────────┐
│ Title of │      │                                 │
│the index ├─────▶│ 14.14 My data storage & backups │
│  entry   │      │                                 │
└──────────┘      │                                 │
┌──────────┐      │                                 │
│Recording ├─────▶│ Location: Dropbox, iCloud,      │
│   the    │      │ Backblaze, blue hard drive      │
│ location │      │                                 │
│  of the  │      └─────────────────────────────────┘
│  thing   │                                         
└──────────┘                                         
`}
  alt="A line drawing of an index note. There is an arrow pointing to its title, which is 14.14 My data storage & backups. Another arrow points to the location data that tells us where things are stored related to this ID, namely Dropbox, iCloud, Backblaze, and a blue hard drive."
  figNumber="62.15A"
  figCaption="An index note – locations related to this ID are recorded."
/>

### I never re-use IDs

It's easy to accidentally create the same ID twice if you don't have an index.

Let's say you book a trip to Vietnam. It gets ID `15.53`. You save PDFs in your filesystem, and email confirmations in your email.

Then you book a trip to New Zealand. You only have emails to store, so you don't create a folder in your filesystem. Your situation looks like this.

<JDLineDiagram
  text={`
┌──────────────────────────────────────────────────┐
│Item                             File    Email    │
├──────────────────────────────────────────────────┤
│15.53 Vietnam, 2024               ▒        ▒      │
├──────────────────────────────────────────────────┤
│15.54 New Zealand, 2024                    ▒      │
└──────────────────────────────────────────────────┘

`}
alt="A table with two rows. The first row tells us that there are files and email stored for the ID called 15.53 Vietnam, 2024. The second row tells us that there is only email stored for the ID called 15.54 New Zealand, 2024."
figNumber="62.15B"
figCaption="One ID contains files and email, the other only has email."
/>

Next, you plan a trip to Japan and want to save a PDF. You look in your filesystem. How do you know which number to use? Don't pretend that you'll remember that `15.54` is taken and you want `15.55`. You won't. I've done it.

<JDLineDiagram
  text={`
┌──────────────────────────────────────────────────┐
│Item                             File    Email    │
├──────────────────────────────────────────────────┤
│15.53 Vietnam, 2024               ▒        ▒      │
├──────────────────────────────────────────────────┤
│15.54 New Zealand, 2024                    ▒      │
├──────────────────────────────────────────────────┤
│15.54 Japan, 2025                 ▒               │
└──────────────────────────────────────────────────┘
`}
  alt="A table with three rows. The first row tells us that there are files and email stored for the ID called 15.53 Vietnam, 2024. The second row tells us that there is only email stored for the ID called 15.54 New Zealand, 2024. The third row tells us that there are files saved in an ID called 15.54 Japan, 2025. The ID 15.54 has been used twice! This is why we need an index."
  figNumber="62.15C"
  figCaption="Oh no! We forgot we already used 15.54 for New Zealand."
/>

You need an index as the central store of your IDs. Now you won't go to your filesystem to create a new ID: you'll open your index. **Your filesystem is not your index**.

### My note-taking is next level

What if you had a place to store quick notes and knew that you could find them again? As we see below, when you keep your index in a notes app, you get this for free. All your notes live in IDs.[^keeping-notes]

[^keeping-notes]: I talk more about this in [keeping notes](/documentation/keeping-notes/).

## How to keep your JDex

Until I get around to making a Johnny.Decimal app, the simplest way to keep an index is in a notes app. I've tried other ways but they were more effort.[^see-advanced]

[^see-advanced]: [JDex: Two other methods](/documentation/jdex-other-methods/) documents the more advanced ways to keep your JDex.

Any app that lets you search your notes quickly will work.

- I use, love, and recommend [Bear](https://bear.app) for all Apple platforms.
- [Obsidian](https://obsidian.md) is a crowd favourite. Cross-platform.
- In the [Workshop](/jdu/workshop/) we see Lucy create her JDex in Apple Notes.

### One note per ID

To create a new ID, just create a new note:

- First, search your notes for the relevant category.

- Your app should filter all notes and show only those that match.

- Identify the next available number and make a new note.

The title is the index entry. The rest of the note can be blank. But, as mentioned, adding location data can be really helpful.[^not-an-inventory]

[^not-an-inventory]: An index is _not_ an inventory. It is for recording the IDs that you have assigned, not to track all of your documents.

You must do this before you create a folder in your filesystem, email, or anywhere else. Creating the note _is_ creating the new ID.

### What this looks like in Bear

By typing `15` and `.` in search, we can (usually) filter out other notes that just include the text '15'.

<JDImage
  alt="A screenshot of Bear. We're using its search feature with the search term '15.' to show only those notes whose title contains that text."
  folder="documentation"
  src="62.15D-Bear_searching_15-803x362@2x.png"
  width={803}
  height={362}
  dropShadow
  caption="Figure 62.15D. Using Search to show only the IDs in category 15."
/>

It's showing us that `15.55` is the next available ID in the category. So we create a new note.

<JDImage
  alt="A screenshot of Bear. Now we've added a new note called 15.55 Japan, 2025."
  folder="documentation"
  src="62.15E-Bear_adding_1555-803x362@2x.png"
  width={803}
  height={362}
  dropShadow
  caption="Figure 62.15E. We're off to Japan."
/>

## The power of search

When you're saving all sorts of items in your system, you won't always remember where they are. Did you store your car insurance policy in your email or filesystem? Is your hotel booking in your email or a travel app?

The whole point of the Johnny.Decimal system is to remove this frustration.

Having a central index allows you to search for items by title, or filter everything by area or category. This lets you see, immediately, what you've saved. If your system also tells you the item's location, fantastic.

<JDImage
  alt="Another Bear screenshot. We're searching for 'car insurance policy', and one note has been found. Its title is 12.32 Motor vehicle insurance & claims. In the note we've added the text 'Keywords: car, policy'. The note also shows the location of this item as email."
  folder="documentation"
  src="62.15F-Bear_search_car_insurance-804x375@2x.png"
  width={804}
  height={375}
  dropShadow
  caption="Figure 62.15F. Using search to instantly find the location of our car insurance policy."
/>

As you can see here, we've also added 'keywords' to our JDex entry to help us find it in the future.

## Your system's memory

As you use it more, your index becomes your system's memory. As well as just keeping simple lists of what's where, you can use it to record higher-level details about the system.

For example, I have two systems in my life: [Life Admin](/las/), and [Small Business](/sbs/). Each contains a category `13` which relates to finance. And in there I have IDs where I track my subscriptions.

But some of my subscriptions apply to both life and business. I use the same backup service for both, for example. So which system should I store that in?

This is where you decide and document.

### Decide

Just decide! I decided that my life comes above my business. If you like, life _contains_ business. So where there are things that could be in either system, I put them in [Life Admin](/las/).

### Document

A simple decision, which you're sure you'll remember. But why chance it? This is exactly what your JDex is for.