|
|
|
|
---
|
|
|
|
|
categories:
|
|
|
|
|
- CMS
|
|
|
|
|
- Doc
|
|
|
|
|
- Diary
|
|
|
|
|
cover: soup2.jpg
|
|
|
|
|
cover_alt: "Soup episode 2"
|
|
|
|
|
date: 21/09/2022
|
|
|
|
|
description: "notes for the next documentation workout\e[D"
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
![temporalities](tempo.jpg)
|
|
|
|
|
|
|
|
|
|
**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.
|