Keep your notes organized store your other files all over the place, wherever it is convenient. There is some empirical support in favor of search over tagging. I, at least, cannot accurately predict what taxonomy I'll need 5 years in the future, nor can I consistently tag every file correctly. Don't bother with elaborate tag or folder based taxonomies. Similarly, a collection of files is more reliable and flexible than a database tied to a subscription-based service.Ģ. Text-based notes are easiest, but formats that have ubiquitous support (like docx or html) are ok too. Your files need to be searchable, and at some point you will need portability.
Make sure your files and their organizational scheme can be transferred between tools. My list of lessons learned (which has some overlap with yours) is:ġ. Focusing on principles over tools is good tools come and go. I endorse the idea that over-engineering is counterproductive. That link I posted above was from my archival system but remembering Noguci's system and that it applies in this case is from repetition over active information systems.
FREEPLANE EXPORT AS BULLETED LIST ARCHIVE
Just wanted to point out that important difference between active and archive information. Screens and the internet while great at archival, just dont work well for active information that I want to recall at will. I have learnt to differentiate between archive and active areas. I have recently begun exploring concepts of spaced repetition to this effect but its too early to comment on this. I tend to frequently write, bookmark, capture things and leave it at that. However, my system is stunningly poor at filtering and modelling information into memory. Here's the post that inspired me towards this system. I'm fairly settled on a homebrew style of noguci's system including pen, folded paper in my back pocket, a few paper notebooks as well as markdown, google docs, simplenote (via notational velocity) and google keep. I attest to the per use-case notion for organizing anything. I've used and refined these principles in setting up wikis at my last 3 companies and it's worked pretty well for organizing a collective knowledge base as well. Wikis do work for me, provided it's organized around Schelling points. As wenc puts it, "discover your own data use patterns." Then I need to be rigorous, reorganizing things when they don't work intuitively and adding new nodes when something I need has not yet been recorded. But as wenc notes, keep the graph shallow. They are the edges in my knowledge graph. Links/URLs will tie everything together. It shouldn't take me more than three clicks to get from my starting point to the information I'm looking for. For me, this is the home page of my wiki. To retrieve information, I should know where to start: a Schelling point. It's a little too heavy for me, but many people seem to find it useful. Wikis don't fit the PKM use case that well, so these too have fallen by the wayside for me.įor me, PKMs need to in some way feel like a single broadsheet where I can easily see and touch my information without having to drill-down hierarchies and follow too many links. I've tried wikis but due to their multipage nature, they segment knowledge too finely (often there are wiki pages hidden in deep in the link hierarchy that I forgot existed). I also occasionally use some specialized tools like Jabref (BibTeX) for specific types of data like references, but I hardly ever write papers anymore, so these have fallen by the wayside. It's simple, searchable, and multi-device. My PKM system is very simple: a single unorganized Google Docs for quick thoughts and ideas (just bullet points), separate Google Docs files for specific projects, etc. If you go with a super organization system on day 1, it will likely be too general and require too much effort (tagging, keywords, hierarchies, version controlled, branches, etc.) you will end up expending resources on metadata management on data that you may never ever need to retrieve and very soon you will abandon the effort. After a couple of projects, and you will naturally discover your own data use patterns.
FREEPLANE EXPORT AS BULLETED LIST HOW TO
writing a blog or paper), and work backwards to figure out how to organize your data to meet the requirements of that project. Start with a specific use-case/project (e.g. Instead, organize your information per "use-case". You will end up overengineering your org method. There is no single all-purpose organization method.ĭon't start with figuring out a method to organize your information. If your data is variegated in format and form, don't look for a single tool/method solution to organize them. This is what I learned from designing data architectures:
0 kommentar(er)
