Emacs org-mode is very powerful tool for personal knowledge management, but can be hard to learn, makes it hard to have the same content (notes) referenced in more than one place, and can be awkward for the hands.
Finding other tools inadequate for various reasons, I wrote OneModel to meet my own needs, and made it available. If you touch-type, it is extremely fast for to-do lists and notes of all kinds, and I generate the project web site from part of its data. It is much easier to learn and faster to navigate than emacs, and you can have the same content in as many places as desired, without duplication.
But it wants to be more: It uses an internal structure that has big future ideas for knowledge management, like embedding code within groups of entities, or linking across OneModel instances, so you can choose to share data from your personal organizer, or subscribe to (or copy) data from other instances: like a wikipedia but where the internal knowledge is structured so can be used for computation, rich queries etc. Imagine asking a system: what villages in history had economic improvements in a 4-year period, all external conditions being equal, and what do those cases all have in common?--that is the long-term vision of the system. The vision and internal structure are intended as be a prototype of a platform to manage all mankind's knowledge as a usefully computable whole.
The web site has a few screen shots (remember it's an ugly prototype but works well! -- I have my calendar/life notes/todos/contacts etc in it now) and a demo system to play with without installing anything.
(It is written in scala, using a simple/approachable coding style that should be readable by most programmers with just minutes of scala knowledge--I hope--and uses postgresql for the data.)
I frankly don't mind if someone else takes the ideas and does a better job with them: we can do better than managing mankind's knowledge in the form of huge sophisticated piles of words: words are not the real knowledge but a superstrate over it, and they are hard to compute well. Feedback welcome.
Thanks for the suggestions; I appreciate the candor. It would be easier to do what you say but for the philosophy of the web site itself, and its being generated directly from content (aka my personal notes).
The whole idea is to model knowledge, ie, what I know. So the content started out as, in effect, a network of thoughts, each one leading to the next. Something like a mind map. Then I simply generate the site. I don't know if it's worth it to me to hand-create the html pages or use a different content system, when I currently can just use my note-taking system, hit generate, push it up, and it's live.
But I grant you it's different to read, and might put people off. Maybe it could be made more sophisticated in how I generate html from my notes (aka my knowledge model) to make it more attractive and readable. That's far from the highest priority at the moment though. (like, versus some key features to let individual OM instances aka models interact with each other and share information, or maybe creating a demo video and/or whitepapers that better explain the confusing parts to people).
I hope that one mitigating factor is that it responds quickly (since it's just static, lightweight html), so a person can see the set of ideas at any given time, and click to learn more about any one of them, something like quickly navigating a map. But that kind of "ease of use" could be some wishful thinking on my part...
The whole idea is to model knowledge, ie, what I know. So the content started out as, in effect, a network of thoughts, each one leading to the next. Something like a mind map. Then I simply generate the site.
Then maybe you should add code to generate a well-readable site from your data representation. If that's not possible, I'd see that as a sign that there's information missing, namely exactly the information needed to generate a readable page from it.
Almost like a "CSS" for the data. Maybe, but a relatively lower priority right now. Thanks for the suggestions.
Smart people might want to use your software. They can figure out what you wrote and what you were thinking. But you shouldn't make them, because reward isn't guaranteed for that effort.
Instead, 'dumb it down' and make elevator pitches. Can you explain, in HARD CAPPED THIRTY SECONDS, what it does? Refine your description until you can, then use that as your descriptive text. Do the same for any other critical information. Take *important* usage recommendations ('here's how you can structure things!') and decompose using examples (grab any software-skills textbook, eg. a sql one, for the format) so that it's active learning for the reader.
EVERYTHING which is at present a brain-dump should be recompiled into (using onemodel's format) internal project docs. Get your project docs ducks in a line and keep them out of the user-public eye, and in the git-repo-public eye. Separate your internal project documentation and your user documentation!
Thanks for your comment (which I upvoted; not sure why it got downvoted before).
That is hard for me. I can probably do it with long effort, but in a previous job I found that the tech writers could transform my best writing into something much better for a given audience.
I would value greatly your participation on the om-list to provide ongoing feedback, or so I can ask "is this better..."?:https://pairlist6.pair.net/mailman/listinfo/om-list [pair.net]
(Or of course, this list whose content is a subset of the discussion list:https://pairlist10.pair.net/mailman/listinfo/om-announce [pair.net] )
Tech writing is a skill that can be learned. If you were to learn it, you'd probably find that you would require different tools to express yourself after that. You won't get it by getting a machine to write for you.
As for how to learn it, the only way I know is to do it, and revise mercilessly, getting constructive criticism from readers.
I used to hate writing. My Phd thesis was an exercise in tears. What turned me around was a good workshop on creative writing, followed by several Novembers of nanowrimo.
After that, I no longer feared writing lots of text. If something wasn't clear enough, I rewrote, and rewrote again. often from scratch each time, until it was good enough. (no that isn't the recommended approach for the nanowrimo November; then you just write the *first* draft; rewriting later). Now I just emit words roughly on topic and then change them a few times once I've found out what I was writing. Often you only find out what you have to say by saying it wrong.