On Monday, February 3, 2020 at 6:06:33 PM UTC-5, andyjim wrote: > > > Sure wish I were a programmer. Sometimes I've thought maybe I should dive > into programming just to gain the skills to build this myself, but I think > that's likely way too ambitious, especially at my age. > But if/when someone here wants to/has time to give it a look, I would love > to have the opportunity to submit a more lengthy 'essay' outlining in some > detail what I've evolved in my imagination over a few years of thinking > about this. Naming a few features doesn't get the idea across. I haven't > written it up in one piece as yet. I need to scramble through all my past > notes about it; might take 3-5 pages. Heck, maybe it's not as good a set > of ideas as I think, but what I envision sure appeals to me for what I do > with writing. Wish I'd had it 20 years ago. > I have written an initial set of user requirements (attached), and I would appreciate your thoughts on them. These are very high level requirements, and they don't include any actual user interface ideas. Instead, they are things that I think any UI would have to honor. I have tried to abstract from written work on paper zettelkasten systems. I also tried out several (free) zettel-programs for Windows, none of which worked well at all for me.
One key point for me is a need to prevent lock-in to this - or any - particular system by either keeping the zettelkasten in the form of text note files, or having the ability to export a complete set of such files. In the worst case, I picture to myself, one could print out the text notes and actually use them as is in a physical zettelkasten. I think this is so important that I made it the first requirement. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/1970cb58-b04e-4dfd-b6c3-deb7479b6dc2%40googlegroups.com.Title: <string>
zettel_requirements.txt
Purpose
To replicate the essential features of the paper-based Zettelkassen system, with potential improvements.
Basic User Requirements
1. No Lockin
Requirement: The notes data must be in such a form that they may be transferred to another notes system (even a paper one) without losing any essential data.
Discussion: If the note-keeper decides to change to another notes mangement system, the data must be useful outside the Zettel-box, so that months or years of research not be lost. What is the most basic alternative system? That would probably a full-text search system. Another basic system would be a paper system like the original zettelkasten.
These needs lead to the next requirement.
2. Text Files
Requirement: The zettel-box notes must be in a text format. They may be one note per file, all notes in one file, or a combination. Alternatively, the system must be able to export such files with no loss of data.
Definition: "Text format" includes slightly structured text-based formats like Markdown or ReStructured Text. It excludes more complex formats such as XML. The intent is that the note files must be easily readable by a person.
Discussion: Using one file per note seems to be the simplest way to emulate the original paper-based system, which had one card per note. However, a larger file could be used if there is simple way to extract or recognize individual notes. This would allow a computer program to separate the individual note if needed.
3. Simple Section Demarkations
Requirement: If a note needs identified sections, the section demarkations must be easy to type, easy to read, and easy to parse by computer.
Discussion: An identified section could be a URL, a group of references to other notes, a tag or indexing aid, a citation list, etc.
4. Unique Identification
Requirement: Each note must be uniquely identifiable, so that it can be referenced by other notes.
7. Time Stamp
Requirement: Each note must be able to have an optional timestamp.
Discussion: A number of people have written that having a timestamp is helpful in reconstructing the context of recent work, since the most recent notes most likely represent work that was recently done.
It is currently unclear about whether only a creation date would be enough, or whether a last-modified date will also be helpful. It the interest of simplicity in a potential move to hand-created or paper notes, a single date would be better.
8. Tags
Requirement: The system must be capable of optionally attaching one or more "tags" to any note. Tags must be easy to create, delete, and attach.
Definition: A tag means a property represented by a name (a string).
Discussion: Tags serve primarily as a filtering mechanism, to help identify notes in a general area of interest. 9. Backlinks ============
Requirement: For every link to another note that is inserted into a note, the system must create a corresponding link in the target back to the first note. Alternatively, the linking system may be inherently bi-directional, such that backlinks occur automatically.
Discussion: If the system exports data to text files, the backlinks must be included in the exported notes data. 10. Display Styles ==================
Requirement: Selected subsets of notes must be displayable in both a hierarchical display (where parent/child or sibling relationships exist) and a non-hierarchical display of associated notes.
Discussion: A strength of the original zettelkasten paper system was that one was not forced into thinking about the notes as having any kind of a strict hierarchy. This feature must be preserved in the new system. The apparently hierarchical identity coding was mainly for locating notes in the note boxes. Howver, notes near each other were more likely to relate to each other.
It would be possible to have parent/child relationship between notes that were not located near each other, but having them close together tends to make them more available when working on a subset of notes.
