Johnny Decimal ist ein cooler typ, aber wir sind nicht die besten Freunde

📄 Geschätzte Lesedauer: 11 Minuten.

Dank Martine Ellis habe ich ein Datei-Struktur System namens Johnny.Decimal gefunden:

Martine schreibt regelmäßig über sinnvolle und gute Ideen zum Thema Produktivität, also habe ich mir das Johnny.Digits Konzept mal angeschaut und teile hier meine Gedanken. Was ist gut an dem System und woran hapert es (zumindest für mich und meine Arbeit).

Bitte lest zuerst drüben bei Johnny.Decimal, setzt es nicht direkt um und ich warte hier in der Zwischenzeit, bis ihr wiederkommt. 😉


Danke fürs Zurückkommen, wir steigen ein!

Ein wichtiger Hinweis zu Beginn: Dieser Text ist nicht dazu gedacht, dieses System schlechtzureden. Wenn es für Dich funktioniert, prima! Bleibt dabei und genieße es! Ich selber kenne aber den Schmerz, den ähnliche Systeme verursachen können und welche Nachwirkungen sie haben, wenn sie ohne weiteres eingebaut werden. Bitte setze Dich mit meinen Ideen auseinander und gebt mir Feedback, damit wir die beste Lösung für alle finden. 😎

Das Gute

Ich liebe die Idee, Anleitungen zur Datenstruktur und zur Speicherung von Dateien zu geben. Dies sollte bereits in der Schule vermittelt werden, anstatt den Kindern PDFs (gut), Word-Dateien (schlecht) und andere Dinge ohne Namenskonventionen zuzuwerfen und von ihnen zu erwarten, dass sie es richtig organisieren. Johnny.Decimal und andere Leitfäden sollten als geeignetes Lehrmaterial betrachtet werden.

Mir gefällt der Ansatz, Zahlen zu verwenden, sodass sie als Referenz auf das Dateisystem außerhalb des Dateisystems verwendet werden können. Das Hinzufügen der Zahlen zu E-Mails oder Kalendereinträgen ist eine tolle Idee. Es auf ein Post-it zu schreiben und es auf einen physischen Gegenstand zu kleben, ist eine geniale Idee.

Zweitens setzt es dem Benutzer Grenzen. Computer haben nicht mehr viele Beschränkungen für Dateien (100.000 Ordner in Outlook? Kein Problem. Eine Million Dateien auf der Festplatte? auch ok), aber wir haben Grenzen. In etwa 95 % der Fälle funktioniert es bei mir, wenn ich nur zwei Verzeichnisebenen nutze. Allerdings würde ich dies als eine „weiche“ Regel mit einem „außergewöhnlichen +1“ betrachten, wenn es wirklich nötig ist. Der Hauptgrund ist: Unser Leben verändert sich ständig, daher müssen wir dem System etwas Flexibilität geben. Ich strebe immer zwei Ebenen an, aber wenn ich einfach keine richtige Lösung finde, kann es nicht schaden, einmal in hundert Fällen eine dritte Ebene zu haben.

Das Schlechte

Die Verwendung von Nummern. Und wie sie verwendet werden. Und wo. Ja, mir ist bewusst, dass dies im Widerspruch zur obigen Aussage steht, aber hört mir zu:

  1. Zahlen bieten keinen ausreichenden Kontext. Wie es auf der Einführungsseite heißt: Wenn jemand nach einem Projektdokument fragt, gibt Ihr Kollege einfach etwas wie „21.15“ an. Das ist in Ordnung, aber in einer komplexen Umgebung weiß weder der Absender, ob er/sie/sie die richtigen Informationen bereitgestellt hat, noch weiß der Empfänger, welche Art von Informationen er/sie/sie gerade erhalten hat. Handelt es sich um einen Berichtsordner mit den Projektdetails? Handelt es sich um den „lebenden Projektordner“ mit allen aktuellen (und sich ständig ändernden) Dokumenten?
  2. Es erhöht die Komplexität des gesamten Systems. Das folgende muss alles erledigt werden, bevor das System steht:
    • Die gesamte Struktur muss im Vorraus geplant werden
    • Mann muss sichstellen, keine Fehler zu machen (mehr dazu später)
    • Alle Teammitglieder müssen sich im Vorfeld auf die Planung der Prioritäten und der gemeinsamen Struktur einigen
    • Jeder im Team muss sich die Zahlen merken und auswendig lernen
    • Sollte in einer Kommunikation ein falsche ID angegeben werden, kann das im Nachhinein zu vielen Unklarheiten führen
  3. Durch die Nummern werden die Prioritäten beim Anlegen “in Stein gemeißelt”
    • Du hast ein paar Kunden in einem Ordner und nun kommt ein Neuer, der als der wichtigste gilt? Schnall dich an, das besprechen wir im nächsten Teammeeting. Das Ergebnis wird sein: Wir ändern die Zahlen („Oh, alle alten Referenzen funktionieren nicht mehr“) oder nicht („Warum steht der neueste Kunde ganz unten auf der Liste? Sie sind wichtig!“)
    • Zahlen am Anfang des Ordners überschreiben die natürliche alphanumerische Sortierung, die wir bereits haben und die sehr gut funktioniert. Es ist „fest“ (a vor b, vor c usw.) und wir alle haben in der Schule diese „natürliche“ Sortierung gelernt und können Dinge in längeren Listen schnell finden, weil wir wissen, dass „x“ immer ganz unten steht. Und wenn Ihnen das nicht gefällt, ist die Sortierung nach „letztes Änderungsdatum“ vielleicht besser für Sie?

Ich verstehe, dass Nummern nur als Referenz dienen, es gibt jedoch einen Grund, warum wir das DNS-System verwenden und nicht nur mit IP-Adressen (z. B. 192.168.1.14) im Internet surfen. Und ja, zwei zweistellige Zahlen sind viel einfacher zu merken, aber im Falle von „zu vielen Projekten oder Kunden“ (wie hier angegeben) kann es schnell zu zwei dreistelligen Zahlen kommen und – oh – wir sind auf halbem Weg zu IPv4 Adressen. 😅

Das Häßliche

Warum die Beschränkung auf zehn Ordner? Und warum sollte man die Dinge auf „zehn“ aufteilen? Dafür gibt es keinen triftigen Grund, abgesehen davon, dass das System die Idee von Referenzen mit zwei zweistelligen Zahlen beibehalten möchte. Es kann Projekte geben, die von Anfang bis Ende problemlos mit drei Ordnern auskommen. Es wird andere geben, bei denen 23 Ordner benötigt werden (ein Kunde für mehrere Jahre, einige Projekte pro Quartal). Es besteht keine Notwendigkeit, sich auf „zehn“ zu beschränken oder ein kleines Projekt auf „fast zehn“ zu erweitern, nur weil das System dies allein rechtfertigt.

Diese zusätzliche „Begrenzung“ und „Erweiterung“ erfordert zusätzlichen Spielraum bei der Festlegung der Ausgangsstruktur. Dafür besteht keine Notwendigkeit. Außerdem ist keine Metaordnerstruktur erforderlich (auf die hier eingegangen wird). Ich werde etwas später darauf zurückkommen.

Das letzte große Problem, das ich habe, ist, dass das System die Namenskonventionen für einzelne Dateien nicht klar berücksichtigt (vielleicht habe ich das übersehen?), was entscheidend ist, sobald eine Datei ausgetauscht wird oder das System verlässt oder in einem Ordner mit mehr als 20 weitere Dateien liegt.


Ein leicht anderes System..?

Ich werde versuchen, ein alternatives System zu beschreiben, welches ich verwende. Es ist alles andere als perfekt, vermeidet aber in den meisten (!) Fällen unnötiges Nummerieren und Nachdenken.

Martine hat sich diesen Artikel kurz nach der Veröffentlichung angesehen und empfohlen, diesem System einen Namen zu geben. Nach einigem Brainstorming kam ich auf Folgendes:

Yet another file-structure framework = YAFF

Dieser Name ist leicht zu merken, kann in Gesprächen verwendet werden und hat keine (bekannte) negative Konnotation (die mir bekannt ist). So sagen die Schotten auch, wenn Hunde bellen. 🐶

Yet another file-structure framework = YAFF

Step 1

Beschränke Dich möglichst auf eine zweistufige Verzeichnisstruktur. Verwende zunächst eine grobe Kategorie und darin in zweiter Ebene für mehr Details.

Schaue beim Erstellen der Kategorien von „unten nach oben“ und nicht „von oben nach unten“. Was haben alle Ordner und Dateien in dieser Kategorie gemeinsam, sodass es sinnvoll wäre, sie zu gruppieren? Am besten vorher mit Papier und Stift die Struktur skizzieren bevor Du irgendwelche Änderungen machst. Denk daran, dass

  • es auch in Zukunft flexibel sein soll.
  • sich die Struktur im Laufe der Zeit ändern kann, indem mehr Ordner als erwartet oder weniger Ordner als geplant vorhanden sind bzw. dazukommen.
  • Du Ordner identifizierst, bei denen Du nicht sicher bist, ob sie in die übergeordnete Kategorie A oder B eingeordnet werden sollen. Das ist in Ordnung. Wähle einfach diejenige aus, die sich natürlicher anfühlt (was ist das übergeordnete Element?) und halte diese Regel für diese Art von Dokumenten dabei.
Jetzt habe ich einen Ordner “Kunden” und einen “Reporting”, wo soll ich die Reports speichern?

Schaue wieder “von unten”. Welche Art von Reports werden gespeichert:

  • Es sind Projekt-bezogene Dokumente, also kommen sie in den “Projekt A”-Ordner (denn ohne Projekt gäbe es diesen Report nicht).
  • Sind es geschäftsübergreifende Reports, sollten Sie in einen eigenen “Reporting”-Ordner (denn diese Dokumente berichten über viele unterschiedliche Themen, deshalb speichern wir sie an einer zentralen Stelle).

Oberste Ebene:

- [Administration]    (internes Zeug für das Team)
- [Clients] (oder Projekte, ne nach Gusto)
- [Media] (unabhängig von Kunden)
- [Public Relations] (unabhängig von Kunden)
- [Reporting] (Du weißt, was hier hinkommt 😀)
- [Templates] (Enthält "leere" Vorlagen)

Und hier die jeweiligen Unterordner:

- [Administration]
- [Clients]
--  [Amazon]  (Falls Du viele Kunden hast, kannst)
--  [Apple]  (Du diese Ebene löschen und einfach)
--  [Google]  (<id> <Projektname> <client> verwerden)
- [Media]
- [Public Relations]
- [Reporting]
--  [2021-03]  (kommt drauf an, in wekchen Abständen)
--  [2021-06]  (Reports erstellt werden, geht )
--  [2021-09]  (monatlich oder jährlich,)
--  [2021-12]  (ganz wie es passt)
- [Templates]

Wenn es sich natürlicher anfühlt, in Projekten zu arbeiten und man viele verschiedene Kunden hat, die sich im Laufe der Zeit ändern, dann benutze einfach Projekt-Ordner wie hier:

<ID> <Projektname> <Kunde>
^ Wird normalerweise auch auf Rechnungen angegeben: "52357"
^ Wir können alle besser mit Namen arbeiten
^ Name des Kunden

Beispiele:

12345 Adsense Campaign (Google)
12346 Shopping Spree (Amazon)
12521 New album release (Spotify, Tidal, Napster)

Wie Du siehst, verwende ich hier auch Nummern. Dies sind “eindeutige Projektnummern”, die diese Projekte (meist vorgegeben durch ein Ticketsystem) bereits haben, also ist das eine elementare Information für das Projekt.

Und warum ist es nun für Dich ok, Nummern zu benutzen?

In diesem Fall geben die Nummern einen “historischen” Kontext zu allen Projekten (Projekt IDs werden normalerweise mit der Zeit größer) oder eine Information zu welchem Kunden sie gehören (Kunden ID + Projekt ID), welche bereits vor der Implementation unseres Dateisystems vergeben werden. Also sollten wir diese Nummern weiter verwenden.

This structure will work with searches (Search “Google” and get all “Google” projects) and is permanent… at least after it is finished. If you run a second project in the same manner, you will not mix up the two projects, because of the unique number that every new project gets. If a project is changing it’s name over time and you want to make sure to keep the history right (Five year ago project 12354 was called “Banana” today it is called “Pineapple”), the structure could look like this:

12354 Banana (Kunde X)
[...] (viele weitere)
12454 Pineapple [fka Banana] (Kunde X)

*fka steht für "formerly known as", andere Abkürzungen gehen natürlich auch, man braucht aber auch nicht unbedingt eins.
AB HIER GEHTS IN ENGLISCH WEITER, RESTLICHE ÜBERSETZUNG FOLGT IN DEN NÄCHSTEN TAGEN!

The trick is not to add more & more words to the folder, but to give it sufficient context, so your brain can properly connect to it even after a long time. Be mindful, when creating (start), working on (progress) and closing (end) a project. As long as there is something in flight, most people will know, where to find it but everybody needs to ensure that it will be found after the hype is gone and the project has been closed six months ago but you need to find the last draft of that concept again.

You can go one step further (which I personally don’t like) using shortcuts. This only works if you drive names never change and you continuously work on projects, which have changing names:

12454 Pineapple [fka Banana] (Client X)
-  12354 Banana (Client X).lnk  (this is the shortcut to the previous project)

I don’t like it, because if the folders change, the shortcuts don’t work anymore and that annoys everybody, so you better use the words in the folder (and file search) to guide everyone.

Step 2

Use the root-folder and the sub-folders to place files there as well. This could me “meta data” or things, which are belonging to the main category but not into any folder.

- [Administration] (internal stuff for the team)
- [Clients] (& their projects, depends on your choice)
-- [Amazon]
-- [Apple]
-- [Google]
--  All open invoices.xlsx  (This applies to all clients)
- [Media] (unrelated to the clients)
- [Public Relations] (unrelated to the clients)
- [Reporting] (you know this content 😀)
-- [2021-03]  (highly depends on your reporting cycles)
-- [2021-06]  (can be done every month)
-- [2021-09]  (or if you only a handfull or reports)
-- [2021-12]  (years might be sufficient as well)
--  2020 end of year report.xlsx  (a summary of the year)
--  2021 end of year report.xlsx  (no need for another folder)
- [Templates] (contains all "empty" documents]

The main reason why I am doing this:
If a file does not fit into any category, we would add complexity to the whole system by adding a new category just to place a single file. There will be a few single files, which will perfectly fit in the root-folder or sub-root-folder. I’m speaking of key files, which fit for all sub-folders and are a “parent” for all the subfolders (like the example above). You will only need a handful of files here and there. By adding them in the root-folder you will find them faster instead of adding a new category, where your single file will sit all by itself, being bored and not accompanied by other relatable folders/files.

And if you identify a new common thing after you have added several documents, great: Create the new category for these.

Step 3

Settle on a “file paradigm” for each high-level folder and stick to it. With that you can adapt different ideas for different folders.

I did this already up above as you can see:

- [Clients] (& their projects, depends on your choice)
-- [Amazon]
-- [Apple]
-- [Google]
--  All open invoices.xlsx  (This applies to all clients)
- [Reporting] (you know this content 😀)
-- [2021-03]  (highly depends on your reporting cycles)
-- [2021-06]  (can be done every month)
-- [2021-09]  (or if you only a handfull or reports)
-- [2021-12]  (years might be sufficient as well)
--  2020 end of year report.xlsx  (a summary of the year)
--  2021 end of year report.xlsx  (no need for another folder)

“Clients” are structured in a different way than the “reports”, and the structure is given by the “common” thing, these documents share. For clients the key thing is the “client name” (or the unique “projects id” in the other example) and for reports, it follows the natural history of the files.

Uhh, the reporting order sucks, I will always need to scroll down to the latest reports.

Yeah, I hear you. But how about changing the sorting on that folder in your finder / explorer to be the other way around? Or add a “!” at the beginning for all “open reports”, so they are at the top. As soon as the work on it is finished, remove the “!” and they are archived. Be creative, but limit yourself to simple rules, which everybody understands.

Step 4

Give your filenames enough context to live on it’s own inside of your system.

For usual project folders I use this:

 <Content of document> <Version as 000>.<filetype> 
Examples:
- Snapshot initial tweet.png
- Johnny Digits blog entry 002.txt
  • “Content of document” describes in a few words, that I’m about the see, if I open the file
  • “Version” is basically a fallback since many file systems do not offer a proper file versioning and I want to keep older versions of my files. Let’s say I work on a presentation and the final version has only the needed five slides but the previous version had all the nice concepts and I want to keep these 20 slides. With that I might have two files, but I now exactly, which one is the latest. Good to have three digits, you might often have more than nine versions, but never move than 999.
Please avoid words here like “final” or “draft“. There will be “final final draft final 13” filenames then.

If I have a category, where over time “single file projects” are created, I’ll use this alternative:

<start date in YYYY-MM-DD> <Purpose of document> ([<project id>] <project name>) <Version as 000>.<filetype>
Examples:
- 2021-12-01 print concepts (12345 Xmas campaign) 001.pptx
- 2022-02-25 blog entry (constantinluegering.de) 002.txt

My mind remembers often when a project started: The year, the month, most of the time not the day (which is not an issue to be there, when I search for it).

So, why are you adding a number again?

In this case, the date is a unique identifier, which provides me guidance on the “when”. Yes, I could have a look at the creation date, however this is not always reliable after you moved all project files to a new hard drive!

This is followed by the purpose of the file, which I need nearby the start of the filename because I don’t want a big width in my file viewer.

Then I add the related project (which I already know through my system) but since that information is forgotten as soon as I share it outside, let’s add it. Helps in case of a full directory search as well. 😉

Important!
As soon as a file leaves your system, it has to survive among all other files without the context of the parent folder. Ensure that you add the project id or project name consistently to all files in the filename when sharing. This is additional work for every “leaving file”, but there is no need to have it in place before that to reduce redundancy in efforts.

If I have a single project folder, which is not running for long and will not contain many (like 40?) files, I do not put the date at all, since I have creation date, last change date (which is even find, if I set the “content” and “version” properly and lose the original creation date).

You might consider different naming conventions for different “high level categories” again, but be careful about that, too many different ones will render the whole idea useless.

Conclusion:

Having a system which limits & structures your file system is great. However be mindful about the purpose of the structure and be flexible (and strict at the same time), when you define the rules. Every organisation works differently and this system is here to support you, not to put your ways of working in a too tight corsett.


If you got until here, thanks a lot for reading and I hope it did not sound too arrogant. I believe that the Johnny.Digits system has a few tiny flaws and I tried to address them here and improve them. Of course everybody’s brain does work differently and I got used to this and that’s why I like it and I believe in it.

Give it a try, tell me what does work and what doesn’t. Maybe I have sorted it out, but not documented it here. I will also update this blog entry if needed.

  • Update 26 Feb 2022:
    Fixed a few typos and mistakes in formatting.
  • Update 27 Feb 2022:
    More layout fixes (fixed width for examples) and added the info box about the name of the system. Created a quick logo, because you know.