# Expand an area: Overview

> Some things don't fit in a standard Johnny.Decimal structure. By expanding an area, more depth can be created where we need it.

## The problem

A design principle of Johnny.Decimal is that there are 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 expanding 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.

### Example: A student or teacher

You have more than 10 classes or topics, across more than 10 semesters of study, across multiple years.

### Example: A freelancer

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 need 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. Treat the following [guidelines](/documentation/expand-an-area-guidelines/) as a menu of options, mixing and matching to suit your requirements.

I plan to document patterns for academics, creatives, and freelancers – keep an eye on the [blog](/blog/) for updates.

## FAQs

### 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.