A design principle of Johnny.Decimal is that we can have no more than 10 categories in each of 10 areas. And each category has no more than 100 IDs. This enforces a shallow structure: areas contain categories contain IDs. That's it: three levels.
However some things don't fit in this structure. Trying to make them fit is unnatural and doesn't result in a neat system.
The goal of expand an area is to allow you to use a standard Johnny.Decimal system. But with one area expanded to accommodate the 'more than 10 things' or 'more than three levels' requirement.
Examples
A student or teacher: you have more than 10 classes or topics, across more than 10 semesters of study, across multiple years.
A freelance designer: you manage multiple clients with multiple products that generate multiple jobs. You might have more than 10 of any of these things. These jobs then require their own level of organisation: the brief, copy, art, reviews, and finals. So we require more depth and more than 10.
The solution
We take an area from a standard system and expand it. Exactly how you do this depends on the situation. I will document patterns for academics, creatives, and freelancers.1
Here are the guidelines for any other scenario. Treat them like a menu of options, mixing and matching to suit your requirements.
A common objection
People see this and say, "well what's the point of Johnny.Decimal if I can just make up my own thing?". To which I say: there are no absolutes in life.
I'm trying to be pragmatic and honest. My default system is great for many things, not every thing. We can still use the principles of Johnny.Decimal to stay organised -- these are outlined below.
Overarching principle: consistency is critical
You can build almost any 'shape' of system and be organised. The key is to be consistent in your structure and file naming. This sounds obvious, but if it's front of mind you won't go far wrong.
Help your future self by documenting your scheme and design decisions in your JDex. The standard zero 00.00 Index would be a good place.
Rule: only expand the part that needs to be expanded
Aim to expand a single area of your system. Most of what you do should still fit in the standard Johnny.Decimal structure. If you're a freelance designer, manage the rest of your business with standard areas and categories.
Rule: all IDs start with the area number
Standard Johnny.Decimal IDs start with the number of the area they're in: 83.66 belongs to area 80-89.
You must retain this pattern. You're going to expand one area. Choose that area, and then ensure that every number that it contains starts with the area number.
Example
In the creative pattern, area 90-99 Portfolio of creative outputs is expanded and uses a five-digit non-standard numbering scheme: A0000 … A9999. A indicates the area that has been expanded.
In this example, the usable numbers are 90000 … 99999. Expanding 70-79 the range would be 70000 … 79999.
Principle: use the alphabet
In a standard Johnny.Decimal system, numbers replace the alphabet as the primary sort. This is because most things do not benefit from being sorted alphabetically.
But some things do. For example, if you have a long list of organisations, ordering them alphabetically makes sense. It makes no sense to allocate the organisations a number and sort numerically. See figure 13.21A below.
Principle: use the date
Many things benefit from being ordered chronologically: jobs for a client; semesters at university. And we tend to remember where these kind of things happened 'in time'. So the date can help us find things later.
Look for opportunities to use the date. This must always be specified as year-month-day in the format yyyy-mm-dd, e.g. 2024-08-30. This will sort chronologically in your file system.2 See figure 13.21A below.
Principle: stop using numbers
In a standard Johnny.Decimal system, every item has a number: the ID. However in many expand an area scenarios, numbers might only make sense at the higher levels.
Use numbers to guide you to the place you need to be. Or where there isn't an alphabet or date alternative. But when they become a burden, or when the alphabet or date is better, stop using them. See figure 13.21A below.
Principle: use natural hierarchies
If natural hierarchies exist, use them. Why invent another scheme for something that already has one?
Example
As a freelancer, the jobs you manage are organised by client, product, then job.* Use this hierarchy in your system. Don't worry that it breaks the area → category → ID structure. See figure 13.21A below.
*For the purposes of this example. Adapt this to your own situation.
Principle: look for patterns
A sub-principle of 'be consistent': always look for patterns. If you do something over and over it should be a template. This saves time and helps your brain.
Templates usually benefit from having numbers to keep them in order. Numbering in tens (10, 20, 30) makes sense here. It leaves room between items (05, 15, 25) for one-offs or items you forgot.
Example
A freelance designer creates promotional material for the footwear industry. They have two clients, Joe's Shoes and Tammy's Trainers. Joe makes three products: Big Boots, Cool Kicks, and Sick Sneakers.
The jobs follow a similar pattern. The client provides a brief, copy, images, and video. The designer produces working files for review and a final delivered product.
This is an opportunity to make a reusable template. And to use numbers again. Not as a unique identifier, but to control the order of file system folders.
Here's how their system might look. Area 10-19 is a standard Johnny.Decimal area, and they've expanded 20-29 to handle their clients and jobs.
Figure 13.21A. A freelance designer's templated system. This example uses the following principles: Use the alphabet, Use the date, Stop using numbers, Use natural hierarchies, Look for patterns.
Principle: invent your own scheme
There's a reason people love their Johnny.Decimal IDs. They're a useful shortcut in many situations. So if you need an ID for something, feel free to make one up. Just remember: be consistent.
Example
I like to give each of my invoices a unique ID that relates to the job.
In the example above, we might invent a scheme like 20.JOE.BB.20240708. We're not going to use this code every day. But it serves as an unambiguous reference to that job when we need one.
And I shouldn't have to explain this scheme: it's obvious to which job I'm referring. Annotate your file system and JDex to make the scheme self-documenting.
Figure 13.21B. The designer's system annotated with codes for later use. Note the consistency: every client code is three letters; every product code is two.
Principle: Use existing codes
Much of life already uses the concept of a short code. University courses have them. Creative agencies use them. Almost every professional job management system will allocate a 'job number' of some kind. So where a code exists, don't invent another.
Example
Our student attends university in the Northern Hemisphere. They have the standard life admin pack at 10-19. And a similar structure at 20-29 to handle the administration of being a student: finances, accommodation, and extra-curricular clubs. These are standard Johnny.Decimal areas.
Their courses require an expand an area solution. They naturally group by year then semester, and each has a code assigned by the university. Within each course, we use the same template, numbered from 10 … 60.
It's convenient that the first semester, Autumn, sorts before Spring. If this wasn't the case, we could add numbers to the front to force a sort. Perhaps the month?
Figure 13.21C. A student's system with an expanded area for course work. Note the consistency: every year has two semesters; every semester has course codes; every course is templated.
What am I extending/gaining?
One of your standard areas is being expanded. It can grow to an essentially infinite size: we have abandoned the constraints of Johnny.Decimal. So be careful. Remember the chaos of the past. Don't go back there.
How does this affect my IDs?
The items in this area might not have numerical IDs. They might not have IDs at all.
The point of IDs is to help you navigate to an item, and to give you a unique reference. In this setup, you might not need an ID for either of those things. Alternatively, you might design your own scheme as documented above.
How does this affect my JDex?
It depends. Remember the point of your JDex: to help you find things, quickly, with no stress. Because most of life isn't discoverable.
If you design an area that has this discoverability built-in -- because it's a simple hierarchy of clients, products, and jobs -- then you might not need to refer to your JDex as often.
If you want to keep notes in your JDex, you should assign an ID to an item and use that ID in your JDex as usual.
Can I use this with multiple systems?
Yes. You may expand an area of a SYS.AC.ID system.
Can I use this with extend the end?
No. It makes no sense to extend the end of an area that you have expanded.
