I wrote this post yesterday but had not really tested the full extents of how I’d use it
I can say with a high degree of certainty this is how I will be using my notes in the future since it scales well with time
Currently I use method 2 more than method 1. (Using an autotext word). Method 1 is good if your going to bind 1-3 commonly accessed folders. For me , these are my sprints section
To give an overview of where I spent 95% of my time in dynalist. I literally look at only 1 LIST VIEW the entire day to KISS (Keep it simple, stupid) philsohopy. I called my root folder ⓟⓘ
Example of what my wikis look like:
Example of how I use my wikis with IMAGUS
This is how I generally organize notes, and a follow summary rules of thumbs I use:
- All 2 to 10 hour course notes go in their own specially designated bulletpoint - This keeps things uncluttered since a lot of coursenotes are just me trying to understand a topic, meaning notes are really polluted in nature. Consequently, this applies to things like youtube notes, lynda.com MOOC, etc
- Bulletpoints 1 level down from root doc are extremely specific, with the shortest name possible like “#excel” This keeps things clean and uncluttered, reducing the amount of time it takes for my eyes to adjust and find folders even if there is very large spans of texts everywhere in my wikis area
- Bulletpoints 2-3 levels down from root doc have customized CSS H2 and H3 header tags . This promotes high readability and being able to distinguish structure in my notes at a moments glance
- Inline images are used sparingly to split large clusters of folder names - This lets me see where I am at my notes using only my periphreal vision, so I instantly know what part of the document I’m on. Inline images are used using
![]()syntax. Images are used very sparingly, I only have a total of 4 inlined images across my entire document - Foldernames are all named with #name, and only exist at the top level only (Bulletpoint), and no #folders are nested inside other #folders. This makes each folder unique for searching and still lets you implement things like rawbytez tag index maker Tag Index bookmarklet. It keeps things simple implementing a rigid rule like this
- The phrase express macro for CTRL+F chrome navigation is heavily used this is the first post on the topic I made essentially about navigating documents.
- Child bulletpoints under the bulletpoints like #excel can be as long and descriptive as possible - I treat bulletpoints 1 level deep from root as “folders” and bulletpoints 2-3 levels deep from root as “files”. Files generally should be very descriptive in nature
- Project logs all go in SPRINTS section . The general rule of thumb is notes sitting at the top of my root doc are organized with definitive structure, but the notes down below are organized instead of the current day / time. Unsure of notes go down here as well
- Pomodoros are logged inside the sprints section . If you run a pomodro for 30 minutes and need to jot it down, it goes in that sprint’s section day tagged with #pomodoro so you can run a search on it later
- Phraseexpress macro key is right next to the folder name. Like #excel folder macro is exc#
- Bulletpoints past 4 levels deep are used very sparingly → All notes should sit within the first 3 levels deep (First level = folder, 2nd = category of notes, 3rd = notes, 4th = notes of notes). Anything past 4 levels is only used notes are too complicated to only use 4 layers deep (Dissertation Topics, PhD Thesises, etc)
To summarize briefly what the hierarchial structure is:
.
✪root
✪✪#folder - extremely short, 1 word tag like #excel with the macro next to it exc#
✪✪✪file - extremely descriptive and as long as needed, with H2 and H3 tags
✪✪✪✪notes
That is the general hierarchy of notes. I seperate 5 or so clusters of #folders together with an inline image for easier readability
Sprints at the bottom look like this:
✪root
✪✪#sprints
✪✪✪ Today
✪✪✪✪Tags - if I’m working on excel + airtable at same time, it would be @excel @airtable
✪✪✪✪✪ Notes
✪✪✪ Yesterday
✪✪✪ Day before
✪✪✪ …and so forth
I archive my sprints about once every 30 days now, but really I don’t have to at all
The reason I use sprints is because sometimes I might work on two things that belong in two places:
- E.G. does this item belong in folder A (@excel) or folder B (@airtable)? Project logs by default are very cross-folder -like, so I might be working on a macro-workflow to export @airtable → @excel for data manipulation.
- But then I would put my excel formulas in #excel and my airtable wikis at #airtable
So the following tag conventions are generally used
- #excel → There is only one bulletpoint with this name across my entire document, its a unique primary key basically. Its where I run my CTRL+F chrome search macros
- @excel → This is my project log notes related to @excel. Anytime I do cross-project work across multiple wikis, I use these tags. Consequently, these @excel or @tags only exists in my sprints logs
If you wanted to implement a more TODO task flow, put all your TODOLIST as such:
✪ root
✪✪ #excel
✪✪ #airtable
✪✪ #sprints
✪✪✪ TO-DO TASKS / KANBAN
✪✪✪ Today
✪✪✪ Yesterday
Also, when the API is released for dynalist, and when flatflowy from workflowy gets implemented, you can just have globally retroactive tags anywhere in your document as a “TO-DO-list” with integrations using IFTTT into TODOIST, Trello, asana, whatever. Just dump these somewhere in your daily log and use a special tag instead.
You can also print out all your macro functions for folder names as well, so its in front of you. Its pretty easy to remember that the autotext exc# is for folder #excel for instance, assuming you knew the folder was called #excel
Tag index bookmarklet can help you manage what folders you have and don’t have yet in alphabetical order, see here
For cross-collaboration of notes, or team-based notes, I suggest having a seperate document all together for that. These not workflows are to handle all my personal wikis for doing and understanding complex tasks, so I don’t have to go “how does this work again? how did I do XYZ last time?”
Also, you can always merge wikis together, move notes from one wiki to another, move folders down closer to sprints so you can view notes easier + sprint notes at same time, etc (but this would screw up the purpose of inlining images though). There’s no way to automatically sort your folders in a predesignated view mode yet.
This is basically, how I keep my document organized, and know it will be really organized down the road, with little to no maintenance involved
What it all boils down to is how fast I can enter a set of notes based on its context, and how fast I can retrieve it whenever I need too . Ideally what I enter in is also what I look at after. I keep markdown usage suchas extremely minimal since RENDER CONTENT =/= ENTERED CONTENT in these cases.
Example:
TL:DR
I have a rigid set of rules for scaling my notes upward when navigating around large lists. Because some of my notes are for really complicated topics that I don’t understand that well
Rules. These include inlined images, Specifically phrasing rules based on how deep a bulletpoint is, naming conventions, where notes should go, formatting rules, etc
I only use 1 list view almost the entire day. Sometimes I might use a 2nd going straight to my SPRINTS section, but that’s as far as I go really
Also, I bind my dynalist bookmark key straight to my homepage as well, using the ALT+Q button
If you want to run pomodoros, just tag them with #pomodoros in daily notes
If you want to do kanban (TODO, DOING, DONE), put it right above the SPRINTS section. Consequently when Dynalist API is released there’s many more global applications here as well anywhere in your notes.
Sprints are organized by day, with the most recent day sitting at the top of stack
Everything else is organized by well defined structures
Again, it all boils down to
- How fast I can enter a set of notes in , whatever context it is AND how fast can I retrieve a set of notes, to aid in my project based work
I like to call this term DATA ON DEMAND, and all my workflows revolve around this philosophy