User:Ssstephen/Reading/16 case-stories

From XPUB & Lens-Based wiki
< User:Ssstephen‎ | Reading
Revision as of 22:35, 30 May 2023 by Ssstephen (talk | contribs) (Created page with "[https://gitlab.constantvzw.org/lgru/co-position-catalog in the printed copy it says source files on git but constant moved to gitlab, but the pdf is still there.] Made as part of the Libre Graphics Research Unit. <pre>dissatisfied with the shrink-wrapped relationships that proprietary software allows</pre> Is FLOSS software really more varied? I think so but a tricky thing to prove. And especially are the things that are made with it more varied? Even harder to prove...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

in the printed copy it says source files on git but constant moved to gitlab, but the pdf is still there.

Made as part of the Libre Graphics Research Unit.

dissatisfied with the shrink-wrapped relationships that proprietary software allows

Is FLOSS software really more varied? I think so but a tricky thing to prove. And especially are the things that are made with it more varied? Even harder to prove. Also, slightly related, is colour symbolism provably becoming more homogenous?

[Tools are] "path dependent", meaning that software, like any technology, is often the result of more or less arbitrary conflations of people and situations, sometimes leading to unreflected fossilisations (the text-box model) or other times unnecessarily overlooking relevant practices (chevronnage). How can we change the path of these tools, how to think about their direction?

Conflations, re parallel ports, can be good. I like that the language of this is getting vectory already.

Four axes of orientation emerged:
1. Digital Sensitivity.
2. Process Awareness.
3. Extended Dimensions.
4. Engage and Disengage.

Digital Sensitivity

Graphical Shell: putting coding closer to the designer, in this suggestion like a tool panel (brushes, layers) in a software environment.

It s a way to expose the inner vocabulary of a program, in a more radical way than most APIs would enable.

Illustrator scripting and coding for animation/interaction (eg p5.js) do generally fall short of this "live" element that is being suggested here. Maybe a functional model would be more like how music coding often works (ChucK, Supercollider, LinuxSampler) where there is a virtual machine disconnected from the part sending the commands (the part you write the code in). So possibly to make it a little less instantaneous than is suggested here, you write code snippets and send them to the canvas or composition, where they can live out their lives, be removed, or be updated. ChucK I think does a particularly fluid job of this.

Relational Layout: This one has been covered now by things like Processing I guess?

Shared undo histories: Programs already save undo histories, so why can't we wite those changes as commits? This idea got also referred to as "shared action lists", but that sounds a lot less promiscuous. We liked the possibility of distributing painful discoveries and propagating our mistakes

I really like this one. But documentation of mistakes in a competitive professional field is a much bigger issue that just sharing creative changes in direction between the people working on a layout job. How else can that part of the world be more honest and open? Are the consequences of admitting mistakes really so high that they need to be kept secret?

Conversational control:

If we see design as a practice that seeks to articulate collisions, how could computers be of use to help organise them, to make them visible and legible?

Well there have been lots of changes to how computers can be used to communicate visually since this was written, but I wonder if they have been in the direction that is implied here. What is difficult about communicating during design? Different visions for the project, different opinions on what is appropriate or best, different goals. Can these tensions be navigated in a caring and respectful way? Using computers if it's completely necessary, I guess.