Srigarten System Design | DSri Seah: Investigative Designer

Srigarten System Design

Posted Sunday, March 20, 2022 by Sri.

EDITING PHASE:gathering info...

last updated: 2022-03-20

Srigarten is the working project name for my knowledge management system. The idea is to have an "open notebook" that works well for both thinking and publishing purposes, with the state of my work always visible for people who want to follow along.

My system design goals:

Be as frictionless as possible from "I have an idea" to being published
Give me absolute control over visual presentation and information hierarchy
Reflect my own knowledge gathering and analysis processes
Be a communication node within a web of other knowledge-driven websites that I am collaborating with
Have a flexible technical platform that I can extend easily

Related Systems

Many comparable systems already exist, serving open science and digital gardening users. There are also qualitative research platforms and computational notebooks for data science like Juypyter and Observable.

Why make my own? Well, all of them (except for Observable) really don't look as nice as I'd like. Besides, I've always wanted to make my own knowledge management system based on all the design work I've done with regards to process. And it's only now that my chops in Javascript are such that I think I can build it exactly the way I want.

Raw Notes

Current Schema

The main hierarchy is centered on me, split into two tracks:

TRACK 1

PROJECT/PROTOTYPE/TOOL/RELEASE for productivity/creative work audiences

TRACK 2

JOURNAL/TROPE/MEMO/CONCEPT for curious pattern seekers

Articles in track 1 all have additional tags. These additional tags are not topical, however. Instead, they are by "functional artifact". For example, if I were to write an article about using CSS to style a certain kind of webpage, the tag I would choose is "stylesheet" (functional artifact) not "css" (topical). In this way, I hope to maintain the focus on providing utility to the audience. The exception to this is the PROJECT category, which adds a category that is the name of the project so all related articles can be gathered under it.

Articles in track 2 tend not to use additional category tags because the entries themselves are a "tagging concept" that might inform another. The JOURNAL category is for chronological reporting and is unlikely to have tags. MEMO is a repository for random notes that may inspire or inform a project/tool. CONCEPT contains conceptual models.

The indexing algorithm always lists these main categories first, followed by the secondary categories.

Planned Document Features

Currently the main document format is Markdown + NJK Shortcodes to provide special formatting. However, I'd like to extend this into a clean human-readable document type that supports section-based structures.

Rather than add more Markdown-style tags to generate that structure, I would prefer to make the distinction between structure and formatting much more obvious visually. This is more in the spirit of Markdown itself, I think, to make our source text LOOK MORE LIKE the output than not. There are three levels I'm considering:

An additional layer of document structuring on top of it, designed to be very difference in syntatical appearance while still remaining human-readable.
There are also data-driven structures that I don't think look good by approximating their look. The common extension syntax for tables, for example, it terrible to work with.
A way of implicit tagging for natural inline tags of existing words. This is not the same as linking, but are a way of marking passages of text without a lot of work
Paragraph-addressible persistent anonymous text blocks that can be referenced in a network federated addressing scheme, requiring no additional markup.

Feature Development Checklist

The catch-all list of things I'm working on to bring the site up to par with the old site