|
|
|
|
|
---
|
|
|
|
|
|
categories:
|
|
|
|
|
|
- CMS
|
|
|
|
|
|
- Doc
|
|
|
|
|
|
- Diary
|
|
|
|
|
|
cover: soup2.jpg
|
|
|
|
|
|
cover_alt: "Soup episode 2"
|
|
|
|
|
|
date: 21/09/2022
|
|
|
|
|
|
description: "notes for the next documentation workout"
|
|
|
|
|
|
slug: soup2
|
|
|
|
|
|
title: soup2
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
### Different tempo per project
|
|
|
|
|
|
|
|
|
|
|
|
It doesn't always make sense to use just a date for framing a project. Especially for long-term prototypes or ongoing researches would be nice to have some more durational way of archiving.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**timeline**
|
|
|
|
|
|
|
|
|
|
|
|
pros:
|
|
|
|
|
|
|
|
|
|
|
|
- easy to do
|
|
|
|
|
|
- just need start - end date
|
|
|
|
|
|
|
|
|
|
|
|
cons:
|
|
|
|
|
|
|
|
|
|
|
|
- it’s not really dynamic
|
|
|
|
|
|
- it’s an oversimplification of the temporailty of work
|
|
|
|
|
|
|
|
|
|
|
|
**gradient**
|
|
|
|
|
|
|
|
|
|
|
|
pros:
|
|
|
|
|
|
|
|
|
|
|
|
- interesting
|
|
|
|
|
|
- could be really expressive
|
|
|
|
|
|
- could be developed as an habit:
|
|
|
|
|
|
at the end of each week or day record on which project you worked on.
|
|
|
|
|
|
think about it as a slightly more informative git heatmap - chromatography
|
|
|
|
|
|
|
|
|
|
|
|
cons:
|
|
|
|
|
|
|
|
|
|
|
|
- uhm
|
|
|
|
|
|
- requires a bit of engineering ----- (not strictly a cons though)
|
|
|
|
|
|
- difficult to find the balance between something practical and something overcomplicated
|
|
|
|
|
|
|
|
|
|
|
|
### Sparse notes
|
|
|
|
|
|
|
|
|
|
|
|
Sometimes some thoughts belong to multiple processes. Intersection happens. It would be nice to have some modular notetaking system that could relate writings to different projects, stitching together prototypes and works.
|
|
|
|
|
|
|
|
|
|
|
|
How to? IDK
|
|
|
|
|
|
Probably with a cross reference system, in which things can embed each other. This is a complex system though, not something to be done in one afternoon. It could be done with some extended markdown syntax maybe, linking notes together with some kind of notation \[\*note about the syntax\], for example.
|
|
|
|
|
|
|
|
|
|
|
|
This could be interesting but maybe lead to obnoxious repetition of contents for external readers.
|
|
|
|
|
|
|
|
|
|
|
|
### Work in progress / Public mode
|
|
|
|
|
|
|
|
|
|
|
|
Projects could have two different modes: one for annotate the process and one to publish the outcome. If im writing a log of development such as the [OOC @summer session](../ooc-summer-session/) page is something totally different from [SI17 Visual Identity](../postit-identity/), that is a final outcome.
|
|
|
|
|
|
|
|
|
|
|
|
This could be made with a tag system for example, stating what page is a WIP and what is an outcome, but a different and more interesting approach could be something like the [text intensity of the textoscope](../textoscope/). Here something could be tagged directly while writing, with the possibility for the reader to modulate different levels of detail and polishing.
|
|
|
|
|
|
|
|
|
|
|
|
### new identity
|
|
|
|
|
|
|
|
|
|
|
|
Some sketches for a new visual identity i've done before summer, but im not sure I still like it. There is also a prototype for the auto-draw thumbnail preview. The real question is: are there energies to finish it or will it just remain a proof of concept? (the latter prob)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### aggregator: a different paradigm for note taking
|
|
|
|
|
|
|
|
|
|
|
|
I mean, a different paradigm at least for me.
|
|
|
|
|
|
|
|
|
|
|
|
Write each note in a different file and tag it.
|
|
|
|
|
|
Aggregate notes by tag or just sort them by date.
|
|
|
|
|
|
|
|
|
|
|
|
Interesting and easy to do.
|
|
|
|
|
|
It could be interesting to implement it!
|
|
|
|
|
|
|
|
|
|
|
|
From a technical point of view:
|
|
|
|
|
|
|
|
|
|
|
|
- things are stored in .md files
|
|
|
|
|
|
- static site generation? :^) in order to --> be more efficient and sustainable
|
|
|
|
|
|
- that means: whenever a git hook is called (such as every push), the server updates the list of contents.
|
|
|
|
|
|
- when a user requests the page, the server send the already rendered contents without building them on the fly
|
|
|
|
|
|
|
|
|
|
|
|
omg i hope this is what static site generation means bc im not sure
|
|
|
|
|
|
|
|
|
|
|
|
bonus: it could be done with a custom micro cms
|
|
|
|
|
|
|
|
|
|
|
|
the only thing i need are:
|
|
|
|
|
|
|
|
|
|
|
|
- text editor
|
|
|
|
|
|
- tag system
|
|
|
|
|
|
- file upload (for pictures, video, etc)
|
|
|
|
|
|
|
|
|
|
|
|
blurred documentation
|
|
|
|
|
|
|
|
|
|
|
|
### my page in the soupboat is getting slower
|
|
|
|
|
|
|
|
|
|
|
|
because there are a lot of contents! so probably should really generate the project list on the git hook, and then serve it directly
|
|
|
|
|
|
|
|
|
|
|
|
**update**
|
|
|
|
|
|
|
|
|
|
|
|
and that's what i did now.
|
