User:Francesco

Hello this is a log of things from kamo or Francesco. This is a wiki version of my Documentation Workout on the Soupboat. This page is not as curated as the one in the Soupboat, so if you wanna have fun go and read from there.

Text ⛵ Lifeboats

What if we could use some excerpts from all of what we are reading now as lifeboats in a sea of text?

Text Traversing

Which texts will you traverse? will you make a “quote landscape” from the different texts brought today or stay with one single text?
Identify patterns / gather observations / draw the relations between the words/paragraphs/sounds
What are markers of orientation you would like to set for this text?
Where should the reader turn?
What are the rhythms in the text and how can they be amplified/interrupted/multiplied?
Make a score or a diagram or a script to be performed out loud

Process

What if we could use some excerpts from all of what we are reading now as lifeboats in a sea of text? An attempt to play around with the continous permutations between contents and contexts.

Text Weaving

Weave two texts, like warp and weft

Slow Processing

if NLTK is a form of mapping language, vltk is a form of mapping language from a particular vantage point
pick a text or a collection of texts from the pad from last week or the one of this week
choose a linguistic pattern to apply over the text, for example: all verbs, every third word of a sentence, the 50 most used words, collocations you observe, words with multiple meanings, x of y, question marks etc. the processing can be both manual or automatic.
what is the output?

Weaved with Jian and Emma

Chat Reader

Transform a text (ok no, actually a CSV file) into a chat

Reader Prototyping

take suggested methods, use something we already used already - work on it, elaborate, don’t exclude what we’ve been doing with Manetta, Michael and Cristina go in smaller groups/individually and make a prototype - network of texts,
something visual, reworking of something and what it can be a sensible way to explain to people
come together at 15:30? and we share what we’ve done - talk about how can we stitch it together to make a reader

Aggregating different things ~ output: chat form

Levels

🏸 1 touch the inputs
🏸 2 overlap/merge them a bit
🏸 3 mesh them completely

Process

🏏 take an academic text and turn it into a chat - translating into vernacular;
🏏 simplify the text
🏏 break it into chats
🏏 illustrate some bits

Starting from a difficult but relatable text: our multi voiced pad of the day.
Parsed here: Spreadsheet ghost

Rules to manipulate text:

🏑 table of contents - shorts contents - tag them
🏑 turn into chat bubbles
🏑 illustrate a few

Rules of text simplification (as ⛳️ objective ⛳️ as possible):

🏓 simple sentences
🏓 on point
🏓 short paragraphs and short chapter
🏓 title on each paragraph
🏓 text could become image caption/illustrate chapters/graphs?
🏓 page number
🏓 navigation (table of contents)

Demo online: Chat_a_pad

Demo offline:

Cam Transcript

10 minutes transcription from Insecam webcams

Video Transcribing

SI16 - with Cristina and Manetta

In groups of 2-3:

Decide a video to transcribe (max 10 min)
If you can’t decide on one, take 3-5 minutes to think about a subject of everyday knowledge that is particular to a location/group. Record yourself telling the story
Transcribe individually either the video or your own recording
Compare the transcriptions

fun with Kimberley + Carmen

🥣 Soup-gen

A soup aggregator for the next 2 years

Rejection 🧠⛈️

Round glossary just for fun ok

🎵 K-PUB

Karaoke as a mean of republishing

Karaoke as a mean of republishing

The idea is easy: take some songs, take some texts, and merge them through the logic of karaoke. For our first issue we want to work with Simon Weil’s diaries as text material and Franco Battiato’s songs as musical starting point.

Using a popular and performative device such as karaoke we want to join different voices. Not only the ones from the people singing, but also from all the different authors that participate in this event: the writer of texts, the composer of musical bases and the musicians that will perform them. This project started as a joke and eventually growed because we saw a lot of potential in it.

File:/soupboat/~kamo/static/img/k-pub/karaoke recipe.png

caption karaoke recipe

Christmas Update

Ok we got the room of the little Room for Sound at WdkA: nice. So here is a list of things we need and a list of things to do:

TODO:

text from simone weil
- select excerpts
- excerpts to lyrics
audio from franco battiato
- select songs
- find or write midi files
- sound design
- performance mode
visual
- finish setup record mode (excerpts → lyrics)
- setup playback mode
- design
- development
performance
- call musicians
- space setup
- technical setup
- comunication
- documentation
- pubblication
residency
- daily contents to be published on their radio (readings, log, musical experiemnts…)

workflow for 1 song:

select text excerpts
select song
song to midi
1. if there is already a midi: cleanup: split and join tracks meaningfully
2. if not: song transcription
karaoke recording
1. input: midi song, text excerpts
2. process: performative conversion, excerpt to lyrics tool
3. output: karaoke midi song with text track
karaoke performance
1. input: karaoke midi song
2. output: karaoke text, karaoke midi
  1. midi → text, display the text for singin along
  2. midi → audio, for live playing and real time sound design of the song
  3. midi → visual, for live visual effects

people we need:

musician (at least 1 to start with) (micalis? gambas? others?)
visual (open call? or we can do it on our own for this)
event logic & logistic (chae? gersande? etc? if anyone wants to take care of the setup it would be super cool)
documentation (pinto? carmen? etc?)

🏓 PADliography

Fetching all our pads from the PZI wiki with API magic

Pimp the Soupboat WS

Crash HTML_CSS workshop for our dear XPUB1 fellows

Concrete 🎏 Label

A tool for annotating visual contents How could computer read concrete & visual poetry? How does computer navigate through text objects in which layout and graphical elements play a fundamental role?

With this tool you can upload an image and then annotate it spatially. In doing so you generate a transcription of the image that keeps track of the order of your annotations (and so the visual path you take when reading the image), as well as their position and size.

Neither the image nor the labels nor the transcription will be uploaded online. Everything happen in your browser.

a join research with Supi 👹👺

Chimeric API

What Can API Learn from Poetics and World-building? An original essay from Tiger Dingsun in which the terms graphic design are replaced with API. Read the original text here: Chimeric Worlding

Phylogenetic diagrams Various frameworks for phylogenetic diagrams – right-to-left rectangular layout (A), bottom-up rectangular layout (B), top-down rectangular layout (Dendrogram) (C), rotated rectangular layout (D), bottom-up slanted layout (E), top-down slanted layout (Cladogram) (F), circular layout (G), circular inward layout (H and I).

Introduction

I think I’ll start with that tired question of whether API development is authorship.

I turn to contemporary discourse in translation theory, where there is the idea that translation is an act of authorship, as the translator inevitably has to make countless decisions in creating the translation. There is no such thing as a perfect translation, no such thing as the platonic copy of a text. The point of a translation isn’t, and can’t be, perfect imitation. Instead, the point is to give new life and new meaning to an original text.

Insofar as API development is fundamentally structured around the act of intersemiotic translation, then, it follows that API development is authorship.

So this question of “are designers authors” isn’t actually that interesting, and also probably isn’t actually the locus of the feelings around this debate.. Afterall, copywriters also author texts, but often they author texts in service of a brand. The anxiety of the developer doesn’t come from ruminating over whether or not what they do is considered ‘authorship’; it comes from feeling as though their entire field is stuck between being an artform and a service industry.

What I am interested in, beyond this revelation that design is authorship, is in what kinds of texts we are creating, and in the potentials of developing a sense of poetics in API development. Poetics – how a text’s different elements come together and produce certain effects onto the reader – sounds a lot like what developers are already concerned with, but thinking about API development production through these terms in an under-explored avenue for API development beyond pure functionalism. In particular, I am interested in the poetics, the frameworks, and the tropes used by literatures like poetry or speculative fiction in order to engage their readers with worlds with their own internal systems of logic – worlds which relate to ours, but also lie within a field of hybridity and contradiction. Can API development do this too? My goal is to outline a methodology for developers to think of their practice as worldbuilding, and to consider the potentials and poetics that lie in such an endeavor.

API development and Poetics

Arab Apocalypse Excerpt from Etel Adnan’s The Arab Apocalypse

There are already many things that the field of API development and poetry share. Poetry seeks to make new meaning through novel configurations of elements (words) from an already established system (language). API development, being related to the organization and presentation of information, can also be seen as making meaning through novel configuration of various elements, which are not just limited to language and text, but also might include images, symbolic meaning, and visual culture writ large. Poetry, more so than other literatures, is concerned not only with the denotative meaning of words, but also the meaning that arises from the aesthetic quality of words (things like phonaesthetics, sound symbolism, rhyme, metre). In dealing with typography, developers are also interested in both the denotative meaning and aesthetic qualities of a text they are working with. Both have a playful relationship to structure, sometimes adhering to, and sometimes breaking, form.

However, one thing that API development does not often do, that poetry does, is making a world, to provide a rich context for their work that reaches towards the poetic, the fantastical, the improbable, the mythological. This is extremely worthwhile for developers to pursue, because worldbuilding allows for the potential for narratives to sprawl out nonlinearly. It invites a non-teleological reading (reading without a prescribed goal) of the text, (or image, or whatever the object of API development is) and offers a point of resistance against API development’s primary function as lubricant for the smooth flow of capital (be it economic, or otherwise), which relies on a singular, totalizing interpretation of the world.

A Methodology for Worldbuilding

File:/soupboat/~kamo/static/img/maritain.jpg

caption Diagram from Jacques Maritain’s Creative Intuition in Art and Poetry

Diagram from Jacques Maritain’s Creative Intuition in Art and Poetry

The ways in which poets develop their own sense of poetics varies, but in general one could describe it as a complex interaction between systems of cultural and historic signifiers and a poet’s own idiosyncratic, hermeneutic system of symbols, images, and other poetic devices, as well as their own logic of how those symbols relate to one another. After all, I would imagine that most poets want their texts to be somewhat understandable by their audience. By combining signifiers that are already familiar to their audience with more personal narratives, images, and symbols, the poet creates entry points into the more untranslatable parts of their psyche. This is related to what the artist Ian Cheng might call ‘worlding’. Cheng writes on his website,

“Worlding [is] a vital practice to help us navigate darkness, maintain agency despite indeterminacy, and appreciate the multitude of Worlds we can choose to live in and create. Whether you are creating art, games, institutions, religions, or life itself: LIVE TO WORLD AND WORLD TO LIVE!”

He further writes in another blog post:

We could say a World is something like a gated garden. A World has borders. A World has laws. A World has values. A World has dysfunction. A World can grow up. A World has members who live in it. A World gives its members permission to act differently than outside of it. A World incentivizes its members to keep it alive, often with the pleasures of its dysfunction. A World counts certain actions inside it as relevant and meaningful. A World undergoes reformations and disruptions. A World has mythic figures. A World is a container for all the possible stories of itself. A World manifests evidence of itself in its members, emissaries, symbols, tangible artifacts, and media, yet it is always something more.

What’s most interesting to me here is this interplay between constraints and possibilities. Poets constrain their work using various structures, but also build upon and selectively break apart those structures by incorporating their own idiosyncratic use of language. Through offering both references to (perhaps multiple) systems of shared references and collective knowledge and one’s own personal frameworks, poets create new worlds from this combination of different shared frameworks for interpreting reality and the poets own personal reality, worlds that the audience is able to semi-inhabit, and explore over time.

Thoughts, Language, Culture Diagram of the relationship between Thought, Language, and Culture from Ariel Vázquez Carranza’s essay What is Language for Sociolinguists?

This suggests a methodology that might be of use to developers. Although creating novel structures and novel logics to govern our making necessarily limits any semiotic elements that have to adhere to these structures, these structures also imply the existence of an expandable world within which that logic holds true. The key here is this combination of “internal” and “external” (of which there may be many, which may contradict each other) systems of meaning. This is one way to view the way poets develop their own sense of poetics—how the different elements of a text all fit together, and produce both linguistic and extralinguistic (sensorial? synesthetic?) effects onto the reader. developers, too, can develop their own visual language in the same way that a poet might develop any number of poetic frameworks through which to interpret reality, by fitting together multiple external and internal systems of meaning. We are already adept at invoking widely shared, conventional systems of meaning in order to make our work function on the basis of clarity, but it is also possible for clarity to exist simultaneously with another, murkier kind of effect that comes from fortifying conventional logic with a developer’s own internal logic.

Chimera The mythological chimera

I might call this methodology “chimeric worlding”, to emphasize the fact that these worlds, which developers and their audience cohabitate through their work, are cobbled together from the DNA of various other worlds, and are richer because of this multiplicity. And I choose this word “chimeric” not only for its meaning in the biological sense, i.e., “composed of material (such as DNA or polypeptide) from more than one organism”, but also for its more metaphorical sense: “1) existing only as the product of unchecked imagination, fantastically visionary or improbable, 2) given to fantastic schemes.” (Merriam-Webster)

Under the methodology of chimeric worlding, there is a call for epistemic disobedience, as the decolonial theorist Walter Mignolo calls it, for we all operate under symbolic systems of oppression. As developers we have the ability to take those pervasive systems and strip them for parts, combining them with other, more marginalized knowledge. We can take what has been deemed ‘esoterica’ or ‘folk’, and give them equal importance with conventional structures of knowledge, this so-called ‘rationality’ or ‘common sense’ that has been naturalized. So much of what is considered ‘good’ or ‘correct’ or ‘legible’ design comes from these naturalized conventions. Part of this methodology of “chimeric worlding” involves the possibility of co-opting the aesthetics of structuralism, while recognizing it’s inherent arbitrariness, and to see that this arbitrariness is in fact emancipatory, and enables us to layer multiple logics and systems of knowledge. There’s an opportunity here to mine history and culture of various frameworks as inspiration for organizing content, and for developing one’s own individualized visual language. (Responsibly, of course, but here is where I might invoke my identity as a queer designer of color operating in the Western world, to say that I am interested in co-opting white knowledge as well as utilizing structures from my own culture. This is why, for example, I am interested in both Taoist cosmology, as well as the aesthetics and lore of Christian mythology, even though I have absolutely zero cultural connection to Christianity).

Demons, Folklore, and Speculative Fiction

Vampire Weekend Art direction for Vampire Weekend’s album Father of the Bride, featuring a re-interpreted Tree of the Sephiroth from Judaic Mysticism

“Chimeric worlding” also has a relationship to sacred geometry, to numerology, to mandalas, magic circles, to cosmologies, to mythos. There are all of these old frameworks of graphically organizing the universe and all that it contains, and how it all functions. One form of “chimeric worlding” might be for developers to draw visual and compositional inspiration from mysticism. Consider the five elements used in many traditional Chinese practices to explain various phenomena. Consider the four humors, used in medieval Western European theories of anatomy.

Sigils Worldbuilding Sigils for the 72 Demons in the Ars Goetia

Consider, for example, the Ars Goetia, that Western medieval taxonomy of 72 demons. Each of these 72 demons were associated with their own sigil, and they obviously weren’t called developers back then, but some developer had to create these sigils, these compositions of line, circles, and crosses. By associating this system of sigils with an already existing lore around demonic organizational hierarchy, this designer is able to connect their (somewhat arbitrary) designs with the existing Western eschatological tradition, loading whatever they are making with the invitation for the audience to step into a world where texts and graphic symbols operate under some hidden logic, and have greater power than in conventional reality.

HxH An explanation of the power system in the anime series Hunter x Hunter, which is extremely specific to the world of the series, yet still based in historico-religious ideas of ‘aura’ or ‘qi’.

Sci-fi and fantasy writers have been doing this sort of thing for a while now, to create worlds that are new and yet related to ours. It has also been commonly troped in many anime franchises. “chimeric worlding” also definitely owes a lot to the genre of magical realism, especially in the way that magical realism often operates through epistemic disobedience, by disrupting conventional logic and reasoning. Many of these narratives operate under fictional structures and power systems that draw from various cultural, historical, and religious/spiritual/mystical frameworks, while combining that with other logics and inventions that expand upon those already existing frameworks, in order to flesh out the world in which their narratives play out.

Digimon 12 Digimon based off of the 12 animals in the Chinese Zodiac. There are also 7 Digimon based off of the Seven Deadly Sins.

More literally, this relationship between fictional worlds and broader culture and history is evident in the fact that much of worldbuilding heavily references various world mythologies, folktales and religions (everything from Thor in the Marvel Cinematic Universe to vampires and werewolves in the Twilight franchise), but in a way that flattens it and makes it more malleable. It’s like secularized mysticism, or playful mythos. And what is mythos, if not narrative and epistemological frameworks for understanding the world? But this play with culture also happens at various levels of abstraction. For example, elemental systems (like in Pokemon, or Naruto, or Avatar the Last Airbender) originate from any number of different theories of the atomic makeup of matter (the four classical elements of fire, water, earth, air, the 5 elemental system in East Asia of fire, water, earth, metal, wood). The taxonomic system in Digimon comes from a more recent, technological framework of relationships between data, viruses, and vaccines. In Full Metal Alchemist, which establishes a magic system based on multiple historical-cultural definitions of alchemy, the antagonists are organized around the seven deadly sins from Christian philosophy. Other examples include references to tarot cards (Cardcaptor Sakura, Persona 4, Shin Megami Tensei), chakras (Naruto), different musical genres (Trolls World Tour), taxonomies of virtues, personality traits, or emotions (Digimon again, and even the Pixar movie Inside Out), divisions of labor in a dystopian imagining of society (Hunger Games, plus a slew of other YA dystopian series) or different theories of the relationship between mind, body, and soul (too many to count).

There are all of these ways that writers expand a world through it’s lore, and the great thing about that is that building up a lore suggests the existence of even more lore, that just happens to have not yet been made explicit to the audience, and is open to speculation. This is the kind of thing that fuels fandom. What if developers could create worlds capable of garnering fan theories, multiple interpretations, and wild reimaginings? It would mean a depth of engagement with API development beyond the singular goal of clarity and communication.

Expanding the Limits of API development

File:/soupboat/~kamo/static/img/4.png

caption Culture

If developers only rely on a set of conventions and references that are legible to the dominant culture, then they will inevitably just create things that are meant to be consumed as efficiently as possible, and nothing else. However, if designers only relied on a personal set of symbols and signifiers that are only meaningful to them, their work will be completely useless to others. The field of API development is oriented towards the public, and therein lies its strength. But it can be easy to forget that a public is made of individuals, and it can be hard to create things that both offer up entry points for the audience, and broadly opens up a field of interpretation. “chimeric worlding” helps the developer maintain cohesion in their body of work without feeling one-note. Because if the developer develops a rich, hybridized, internal logic through which their body of work functions, even without explicitly explaining that logic, the audience is able to slowly piece that together, and excavate the lore of the world that is created.

Culture Worldbuilding Poetry and speculative fiction already do this. developers can, too.)

It bears clarifying, that this methodology is not one that tells you to throw away all structure, to throw away all of your legacy Western European API development education and sensibilities. It is a methodology that tells you to provincialize that education, to appropriate and reconfigure it as parts of new hybrids, and to consider it just one tool out of many possible tools, one structure out of many possible structures. This methodology is not one that is anti-structure. It is just pro- multivarious and contradictory and ambiguous and poetic structures.

As an analogy, I might say that this methodology is not one that says to make and then ultimately break the grid. Because the truth is, I, and most other developers, like grids. So instead of breaking the grid, I want to make the grid my own, to claim its aesthetics for myself, and to imbue the grid itself with rich layers of connotative meaning and custom logics. The “chimeric worlding’ version of a grid is a grid that binds itself to the texts and images that lay on top of it, wrapping around it and becoming the bones of a world. And the audience doesn’t necessarily have to understand it all. The paradox is that clarity can, in fact, co-exist with poetic ambiguity and the openness of interpretation. Legibility can co-exist with illegibility. This ambiguous structure (or perhaps structural ambiguity?) signals to the audience that there is a world here, and that it is worth engaging with, and even if they can only catch a glimpse at first, there are hidden depths to discover.

SI16 API Strapi-Nuxt prototype

Test for a node.js backend for the SI16 app Ehm there should be some videos somewhere sorry

SI16 API node.js + express prototype

Test for an API-based special issue

Test for an API-based special issue

The backend is developed with node.js and express
Each URL is mapped to a python script. The argument are passed to the script, processed and then returned as JSON
We start with 2 functions: 1. a find and replace and 2. a shout

(update: hei this is not active anymore! but we really did an API at the end! aha!)

Wait what why an API

File:/soupboat/~kamo/static/img/api bikes.jpg

caption two half bikes attacched with tape and two kids pretty satisfied with their work

This is to show what an API could be in relation to the exercises we usually do during the prototyping class. It is a way to render public a piece of work that usually stays behind several layers of accessibility. The idea of the special issue as an API could be a curated collection of what we are doing since september within a critical context. 🤯

Find and Replace

Find a target string in a text and replace it with the given replacement. The parameters are three.

text the text in which perform the research
target the string we are searching for
replacement the string we want to insert in place of the target

The endpoint is:
https://hub.xpub.nl/soupboat/cat-api/replace?text={text}&target={target}&replacement={replacement}

SI16 Structure Proposal

Imaging the SI16 as an API ecosystem

Overview

The special issue is composed of three main parts: the library, the projects and the launch event. Each one of these has a slightly different nature, and so can access to different kinds of public. Imaging the SI16 as an ecosystem around these three faces permits us to create an organic form of public: someone comes for the event and discovers an API, someone else arrives from the code and is introduced to the critical context around it, each project tho is situated in a specific thematic niche and the interactions with the whole ecosystem could provide fresh air to spin mill.

A systematic approach in the contents’ structure enables us to morph our projects without sacrifice the unique nature of each work. What’s more is that with a clear data structure we can deliver contents in different forms with less effort and less stress.

The following structure is a draft. The order of the elements is not defined nor fixed. Some things are not mandatory, but would be nice and useful to have them if we think to the future life of the SP16 after the launch. The idea is to build something easy to scale, to expand, and to update. Something easy to participate. As an ecosystem some parts are more likely to grow and to evolve, and to provide a good soil as starting point maybe is the best thing we can do?

1. Library

A collection of modules and tools within a context

The library is the main container of the SP16. It provides a list of algorithms and describes the world in which they operate. This world is our source of truth: it is built from all the corpora we will aggregate and use for the projects, as well as other critical contributions, inquiries about the vernacular, and guide to navigate through all the materials. Ultimately a library, or a toolkit, is orientated. Its political stance stands not only in its contents, but also in the way it grants access to them. The relation between authors and public is not based only on power, but here also in trust, and collaboration, and dependency, and mutuality.

Hence the library is part contents, part tools, part documentation, part showcase. These sections could be open and do not have to be perceived as finished. A library is always a work in progress, a work that we are starting now, a work that then someone else can continue.

Beside the contents and their structure, the library also include a showcase section to display all the projects we are working on now. This section strengths the link between the special issue as a publication and the special issue as an event. In order to preserve the original approach of each project an in depth record of each work is provided here. It is perceived as something sprouting from the library. Are the projects and the special issue publication the same thing? Maybe not, but for sure they are deeply related.

File:/soupboat/~kamo/static/img/lib-structure.svg

caption Library

Title, The name of the library
Description, An overview of what it does, how and why does it exist
Context, A collection of materials (researches, essays, excerpts, …) that situate this library in relation with the vernacular
- Manifesto, Our attitude, our purposes, our plan. It could work as an introduction to the special issue
  - Our plan, A summary of the research in terms of intentions
  - Our attitude, An overview of the different approaches we used
  - Our purposes, What do we want to achieve or encourage
- Materials - Corpora, Collections of materials used as sources or collected for the projects
  - Corpus, Single corpus of materials used as sources for the projects
    - Title, A title for the corpus
    - Description, An overview of the contents and how they are structured
    - Type, The kind of materials included
    - Structure, A description of the structure of the contents
    - Contents, List of contents
  - …, […other corpus in the list]
- Research and Development, A collection of contribuitions (researches, essays, excerpts, …) that situate this library in relation with the vernacular
  - SP16 History, Evolution of the SP16 work, devlog, excerpts from the pads, etc
  - List of contribuitions, Collection of essays, excerpts from the texts read in class, piece from the tutors, from us, etc
    - Contribuition, Single contribuition in the list
      - Title, Title of the contribuition
      - Description, Description of the contribution
      - Subject, Theme of the contribution
      - Contents, Contents of the contribuition
      - Credits, Credits and references
    - …, […other contribuitions in the list]
- Guide, Presentation of the form of the SI16 and its structure, how to read it and navigate it
  - Getting started, First steps into the SP16 as an API
  - What is a documentation, How the documentation is structured
  - Learning how to walk while catwalking, Navigation through the special issue
Showcase - List of Projects DocumentationsS, howcase of full fledged and meaningful project built within and from the library, list of projects documentations
- Project Documentation, Documentation of a project
  - Contents, Extended description of the project, including the research, the process and the future possibilities
    - Research, Background of the work, field of intrests, ideas, theory, etc
    - Process, History of the work, process of development, prototyping, etc
    - Outcomes, Results of the research and synthesis of the process
    - Direction, Possibilities for the evolution of the project, new applications, ideas, findings
  - Documentation, Nice showcase of the work
    - Text, Textual description of project and key findings
    - Visual, Visual documentation such as pictures, videos, etc
    - *, Other specifications are unique for each project
  - References, Reference to the corpora or materials used and to the tool involved during the production
    - Materials, Corpora and sources used or created for the project
    - Theory, References for specific theoric notes
    - Codes, Modules, functions and parts of the library involved in the work
- …, […other projects documentations in the showcase]
List of Modules, A list of all the different code approaches, or modules, that compose the library
- Module, A thematic or reasoned group of functions
  - Title, The name of the module
  - Decription, A description of what it does
  - Applications, Examples of applications that use several functions to build complex procedures
  - List of functions, A list of functions
    - Function, A single function in the module
      - Title, The name of the function or algorithm
      - Description, A description of what it does
      - Input, The types of inputs it receives
      - Codes, The procedure it follows
      - Output, The types of outputs it returns
      - Example, Simple and specific examples
    - …, […other functions in the module]
  - …, […other modules in the library]

2. Project

Full fledged and meaningful work built within and from the library

The main feature of having several serious different projects is both that we can explore different shades of the vernacular language processing and that we can access to different kinds of public. It is true that we are in needs for more time now, but at the same time having different projects to work on

File:/soupboat/~kamo/static/img/proj-structure.svg

caption Library

Title, Title of the project
Description, Description of the project
Colophon, Credits and colophon
Project Object, Concrete outcomes of the project
- Object, Concrete result of the work
- *, Specifications are unique for each project
Project Documentation, Documentation of the project
- Contents, Extended description of the project, including the research, the process and the future possibilities
  - Research, Background of the work, field of intrests, ideas, theory, etc
  - Process,History of the work, process of development, prototyping, etc
  - Outcomes, Results of the research and synthesis of the process
  - Direction, Possibilities for the evolution of the project, new applications, ideas, findings
- Documentation,Nice showcase of the work
  - Text, Textual description of project and key findings
  - Visual,Visual documentation such as pictures, videos, etc
  - *, Other specifications are unique for each project
- References, Reference to the corpora or materials used and to the tool involved during the production
  - Corpora, Corpora and sources used or created for the project
  - Theory/contributions,References for specific theoric notes
  - Codes, Modules, functions and parts of the library involved in the work

3. Launch

@Varia on 17.12.2021

File:/soupboat/~kamo/static/img/launch-structure.svg

caption Library

Space setup, Display and physical setup of the space
List of presentations, List of moments in which the different contents of the SP16 are presented to the public
- Presentation, Moment like performance, presentation, talk, workshop, panel, etc
  - Title, Title of the presentation
  - Description, Description of the presentation
  - Subject, Theme of the contribution
  - Type, Kind of presentation: talk, panel, showcase of a project, performance, etc
  - Contents, Contents and theme of the presentation
- …, […other presentations in the list]
List of projects objects, List of physical outcomes from the projects
- Project Object, Concrete outcomes of the project
  - Object, Concrete result of the work
  - *, Specifications are unique for each project
- …, […other project object in the list]

SI16 Frontend Proposal

Proposal for the SI16 website

Design proposal

A super teamwork with Chae, Emma, Supi + the incredible visual package from the Visual Identity group You can see the final result at Learning How to Walk while Catwalking

File:/soupboat/~kamo/static/img/si16-frontend/Intro.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/Home.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/About.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/Snippet Research.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/Manifesto.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/Functions.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/Function.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/Projects.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/Project Documentation.jpg

caption Library

File:/soupboat/~kamo/static/img/si16-frontend/Showcase.jpg

caption Library

Spawn Sticker

simple & flexible & adhesive A script that let you add stickers on top of HTML elements. To make it works just add a data-sticker attribute to your element. The content of the sticker will be the value of the attribute.

<div data-sticker='Hello'>World</div>

This script was used for the SI16 - Learning how to walk while cat-walking website. This is a simplified version. In the original one we had to deal with fixed elements (such as the header / nav of the pages) as well as relative ones. So the code there is a bit messier, but this one here it’s simple and clean.

How does it work

The code it’s composed of 3 main functions: one to create the sticker, one to spawn and attach it to an element, and a last one to limit the amount of stickers spawned at once.

propper documentation coming sooon

Annotation Compass

A tool for gathering situated impressions in order to create individual, vernacular and poetic readings of various inputs This project is a multiplayer branch of the Concrete Label tool, developed in the context of the SI16 &&& is a super collaboration with Supi, Jian, Kim, Alex, and Emma. The description is a porting of the documentation that you can find along with the various showcases on the SI16 website.

How do we bring multi-vocality in the work of annotation? The Annotation Compass builds composites from aggregated vernacular impressions, rich of their subjectivity and situatedness. It is the outcome of a three months journey questioning the relationship between vernacular languages and natural language processing tools.

First Experiments

The living-room

File:/soupboat/~kamo/static/img/map description H.jpg

caption Supi’s livingroom

For this experiment, four of us were gathered in a living-room.

Number of participants: 4
Location: Supi’s living room
Aim: Map out each participant’s impressions of the living room.
Material: The living room’s floor plan, InDesign, computers…..
Time-frame: 5 minutes
Instructions: individually annotate the floor plan with impressions of the living room

After removing the floor plan and looking at the subjective annotations of this experiment, we observed that each outcome forms another ‘space’. Each person’s set of annotations brings a unique perspective of the living room , an ‘individual map’. We then layered the individual maps and the compilation resulted in a vernacular picture of the space. This alternative understanding of the space can only be given to a reader through those descriptions.

Still from Michael Snow’s Wavelength

File:Https://pzwiki.wdka.nl/mw-mediadesign/images/3/3e/Selection process 2.png

caption Michael Snow, Wavelength

The same method was applied to the photograph of a room. Each of us used a different set of coloured sticky notes and took 5 minutes to physically annotate the picture on the same surface. The picture was then removed from the background, resulting in a similar outcome as the experiment described above.

From these observations, our interest on subjective annotations that could flow in a common understanding of an image grew. As a tool to collect situated impressions, we elaborated the idea of the Annotation Compass.

On a given surface, such as an image, the tool facilitates the collection of annotations and their coordinates from various users simultaneously. These annotations represent individual knowledges and perspectives in regards to the given surface.

Michael Snow, Wavelength Michael Snow, Wavelength

Instructions

To use this tool, let’s consider the “host” any person interested in gathering annotation on a specific image; and the “guest” any person invited by the host to annotate the image.

Process for the host

upload an image
add a text to explain the context of the image or to give instructions and helpful advice to the guests
send link to guests and invite them to annotate
download a json-file or text-file that contains the collected data that was gathered so far
try the different functions of SI16 to filter the collected dat

Process for the guest

open the link sent by the host
read the information attached to the image by the host
use the cursor to select a specific area that you want to annotate
write and insert your annotation(s)a

The data

The Tool not only archives the annotations, but also additional meta-data that can be helpful to analyze the outcome. The collected data is stored in a “json-file” that comes as a list of labels. In each label, one can find the file name of the annotated image, the coordinates of the annotation, the dimension of the annotation ‘box’, the annotation itself, the index number of the annotation and a user identification:

{
    "image": "filename.jpg",
    "position": {"x": 12, "y": 97},
    "size": {"width": 43, "height": 18},
    "text": "Content of the annotation",
    "timestamp": "Wed, 01 Dec 2021 14:04:00 GMT",
    "userID": 123456789
}

image: a reference to the filename of the image
position: x and y coordinates given in percentage, relative to the top left corner of the image
size: width and height given in percentage, relative to the size of the image
text: the text content of the label
timestamp: the moment in which the label was uploaded
userID: a random generated id to keep track of the autorship of the labels

for the future: at some point could be intresting to something like a components property, in order to make the tool more flexible and open to plugin or integration. Ideally this property is a list of components, and each one can add some kind of info or metadata for specific usecases, without the need to rewrite all the code to make room for that.

The outcome provided by the Annotation Compass is ever-changing: whenever an individual adds an annotation, the data grows.

After applying the tool to different projects we observed that the collected data can offer a reflexion on the so called “objective”: It provides individual perceptions and builds a common experience by including a multiplicity of impressions rather than one objective definition. In conclusion, the Tool can be used to provide alternative ways to define images, images of space, texts, and anything else annotatable.

Possible applications of the tool:

Ask individuals to annotate the space they are in at the moment.
Ask individuals to annotate a space from memory.
Ask individuals to annotate imaginary spaces. (e.g. a space from a dream, a fictional space they know from a novel, a place that exists but they never went …)
Ask individuals to annotate a space before and after they went for the first time.
Invite individuals to a space and ask them to annotate it as a performative act that is situated not only in space but also time.
Ask individuals to annotate a space whenever they want (unlimited access).
Ask individuals to annotate a public space.
Ask individuals to annotate a whole city, country, continent …
Ask individuals to annotate a private space.
Ask individuals to annotate an indoor space (bedroom, library, central station, theatre …)
Ask individuals to annotate an outdoor space (park, market place, beach …)
Ask specific groups to annotate a space (queer, teenagers, people with disabilities, immigrants …)
Ask individuals to annotate specific things, e.g. emotions, colors, surfaces, light …
Ask individuals to only use specific glyphs (e.g. ! ? and –) or emojis to annotate the space to include those not confident using words.
Encourage individuals to use their mother tongue / slang / informal language to annotate a space.
Ask only one individual to give many annotations of a space over time (daily diary, yearly check-in …)
Ask individuals to annotate different spaces (e.g. their own living rooms)
Ask individuals to annotate a space without using a standard map but rather an empty sheet as a starting point.
Ask individuals to annotate a space without using a standard map but rather an individual map or vernacular map as a starting point.
Ask individuals to annotate a space without using a standard map but rather a photograph of a space as a starting point.
Ask individuals to annotate a space in real life (e.g. using sticky notes, writing on plexiglass, interview) and use the tool to insert the data afterwards.
annotate a photograph (portrait, scene, landscape …)
annotate a painting
annotate a text
annotate a song/sound
misusing the tool

SI16 Backend

Flexible Flask app (~) for the SI16 API

Familiar and flexible

Each contribuition to the SI16 API was unique. Both the subgroups’ projects and their documentation had different voices, different ways of presenting the contents, and different needs. This specificity required a system that was structured enough to keep together each pace, but remained flexible, in order to let anyone express her own approach to the Special Issue.

With the SI16 being at the same time a set of functions, a playground to experiment with it, and a list of meaningful projects developed within their context, we structured the backend as an interface between the different parts of the work.

The main idea was to define a pipeline that was not so different from the processes and technologies we learned and explored during the first trimester.

Functions

We chose to work with the Jupiter Notebook format we were familiar with, as a way to both collect and document our functions. With a common protocol defined within us and some 🐍 pythonic 🐍 (omg this term is cringe ah ah) good practices, we wrote a Notebook for each function. In each file there was the definition of the function, as well as a propper documentation and some examples on how to use it.

A big part of the backend work was to let anyone structure their own notebook freely, deciding how to present the process and the result of each contribuition without forcing a structure. At the end the Flask application was designed to scan all the notebook folder and extract from it the function, as well as their input and output, and the documentation.

With those information we generated an interactive page for each function in which the user could try and play around with our functions exposed as an API.

Projects

The organic process of SI16 led us to a collection of several interconnected projects. Each one of them had grown around a specific implementation of the functions we developed for the API. Those complex applications were initally developed as standalone Flask app, and they were merged all together at the end. (well, ok, after the end to be honest)

One thing we could do differently next time is to use Flask’s Blueprints as a way to work in a more flexible way. At some point we were really struggling about how to manage the code and the collaboration on it. Now that we have an overview of how Python works, it could be nice to develop our projects in a more modular way. BTW we used the documentation pages as a gateway to the projects, in order to have a common starting point.

Things got a bit complicated when the subgroup I was in started to working on sub-sub-project. And to face that we made the structure open to the possibility to nest projects one into the other, in order to have again flexibility between documentation and interaction on the website, and still a (kinda) structure in the filesystem.

Actually: we were totally new into this, so probably half of the things we did were not just wrong, but illegal. BTW we are still learning so next time it will be better, deal with it.

disclaimer there are some problems with the xpub git so the source code is still not totally public, but we are working on it. There the code is annotated and each function is documented so I will not go more in detail here for now.

Project structure

si16
├── contents
├── notebooks
├── projects
│   ├── and-i-wish-that-your-question-has-been-answered
│   ├── annotation-compass
│   │   └── showcases
│   └── etc-portal
├── si16.py
├── static
│   ├── corpora
│   ├── css
│   ├── event
│   ├── font
│   ├── img
│   ├── js
│   └── uploads
└── templates

contents contains a list of markdown file for generic pages. For example the route /si16/intro will search and load the contents from the intro.md file in this folder.
notebooks contains a list of Jupiter Notebook files, one for each function we developed for the API.
projects contains a list of folder one for each subgroup project. Each one has a documentation.md file with the main contents and process of development.
showcases is a optional folder in each project for nesting other sub projects in the sub project. Convoluted but useful and flexible.
si16.py is the main module for the Flask app and the backend duties.
static contains all the different files that are served statically from the webserver such as images, stylesheets, javascript files, etc.
templates is a Flask folder that contains the HTML templates for generating the frontend pages.

Ciao ciao

Soupboat CMS 00

Micro JSON→HTML CMS for the first trimester

A micro CMS

During the first weeks at XPUB I spent some time trying to figure out how to archive and log the various projects going on. I felt to do it here in the Soupboat, because it’s more flexible and playful than the wiki, that remains of course the source of truth and the future-proof archiving system etc. etc. 👹👺

After the second page though I was already ultra annoyed by the fact of rewriting or copy-pasting the HTML from a page to the other to keep at least a bit of style and structure and add contents manually. I wrote then a bit of code to have a default page and then used a JSON file filled with a list of projects. The script traversed this list and created a table with the basic informations about each one.

The model for a project was something like that:

{
    "title": "Text Weaving",
    "date": "Oct 5, 2021",
    "url": "10-05-2021-weaving/",
    "git": "https://git.xpub.nl/kamo/text_weaving",
    "pad": "https://pad.xpub.nl/p/replacing_cats",
    "links": [
        {
            "url": "",
            "title": "",
        }
    ],
    "categories": [
        "Python",
        "NLTK",
        "Text"
    ]
},

Each proj has a title, a date, an URL to a dedicated page. Then a list of links: the git repository for sharing the source code and the pad, that are the two most common types of link, and then a list of generic other links, each one composed by an URL and a title. There is also a list of categories, in order to give some hints about the project.

The dedicated page for a project could have been something somewhere in the Soupboat, or a subfolder in my personal folder.

The structure of the whole thing was: an index.html page with a cms.js script and a cms.json file. (Such imagination in these filenames). Then a style.css and a global.css for sharing the style with the various projects.

Not really a revolutionary CMS but a starting point. Ah ah

I’m writing this while im migrating everything into a flask based one, that will use more or less the same structure we developed for the SI16! Really happy with it. Good night

Temporality of the loot box

Against instant rewarding

Bill Viola opens a loot box

The loot box implies a specific temporal dimension: the one with instant rewarding. When a player opens the loot box she receives immediate feedback. Sometimes it is dressed up with an aesthetic of suspense, but this is just cosmetics and the built-up climax often becomes just something undesired that the user wants (and even pay) to skip.

In order to work with the idea of the loot box without re-enacting its toxic behavior and mechanics it could be interesting to hijack its temporality. By inflating the time between the purchasing and the result, we could create space for dig deeper in this complex and delicate topic.

Loot box
pay ●-->○ get

SI17 Loot Box
pay ●--things could happen here-->○ get

This approach could help us in filling the loot box (tempo) without falling for the same addictive schemes that the industry is implementing for exploiting the players.

Inflating the loot box means that the player could reclaim her own leisure time. If we focus on the temporal fruition of the l~b we can imagine to produce not only an object, but a time slot that the person from the public can reserve for herself. If we define this time slot as leisure time then we could create a sacred and safe space to take a rest and to arrest the acceleration of capital. Something like a checkpoint, speaking from a gaming point of view.

An approach to deal with the temporal aspect in a way that doesn’t feel forced could be to rely on real-yet-slow-time processes for the material production of the special issue. A digital manufacturing production could make a lot of sense in this context. 👀

See the loot—box—sealing—device for a concrete and 3d example

LOOT—BOX—SEALING—DEVICE

Closing Pandora's 3D large jar

3D printed loot box?

This is an idea that follows some intuitions regarding the temporality of the loot box.

Imagine the loot box being 3D printed, and especially 3D printed on demand when the player want to buy it at Page Not Found or Varia or any other place we are going to distribute our work. 3D printing is a slow process, and in order to create a small piece you need to wait let’s say an hour. When someone want to buy our loot box goes to PNF and ask for it, the 3d printing process begins and during the waiting time the player can access and navigate through the contents of our special issue. These contents are contained inside the temporality of the l~b, but they are not consumed instantaneously.

File:/soupboat/~kamo/static/img/test-4d.jpg

caption 3d sculpted loot boxes

How do we want to deliver these contents? It could be related to the way of production of the physical l~b, for instance each player could contribute and shape the 3d model for the next player during the waiting time, and we can aggregate and collect narrations within and around the tools used in order to do so.

In order to cover the expenses of a similar process part of the SI17 budget could cover the cost for some small 3D printers and printing material. The term of services of our special issue could allocate a certain amount of money from each purchase to self sustain the process (buying new printing material, etc)

File:/soupboat/~kamo/static/img/test-5d.jpg

caption 3d sculpted loot boxes

The loot—box—sealing—device

In the movie The NeverEnding Story based on the novel by Michael Ende, the two main characters are linked together by the Auryn. In the (fictional) real world the Auryn is a sigil on the cover of the (fictional) Neverending Story book that tells the tales of the land of Fantasia. In Fantasia, the Auryn is a magic medalion that the hero wears during his mission.

Auryn from Neverending Story Auryn from Neverending Story

Here the Auryn acts as a seal: by removing it from the cover of the book the magical world of Fantasia begins to leak inside the (fictional) real world. Later on it will be the main character to fall inside the (fictional) book of the Neverending Story.

This plot from Michael Ende resembles what happens when we play a game. Thanks to a weird device like a table game, a console or just a set of shared principles, we are able to flow into the magic circle. In the novel this happens with the main character reading a book, and while it’s true that every cultural object offers a certain degree of immersivity, the kind of agency, interaction and participation in the NeverEnding Story is something that reminds me more the act of playing.

File:/soupboat/~kamo/static/img/seals1.jpg

caption 3d sculpted seals

To elaborate more on the 3D printed loot box: we could have a book and using the 3d printer to seal it with a new 3d sigil every time! In a way it is like sealing the loot box instead of opening it. As in the NeverEnding Story (but this is a recurrent magical trope) we would have a sigil connecting who is reading the book with another player. This connection will be not with a fictional character, but with a real person: the one that bought the previous book. There is something like the reciprocity descripted by Mausse here, but is a reciprocity swimming backstroke: the player receives a gift from a past uknown fellow player, and leaves one for a future unkown one. In this way the reciprocity chain (sounds weird) goes spiral.

File:/soupboat/~kamo/static/img/seals2.jpg

caption 3d sculpted seals

Overview

Here a brief description of the different pieces that compose the loot—box—sealing—device

The pubblication is composed of 2 main parts: a base and a superstructure. omg sorry
The base is the same for every copy, and it’s where the main contents are. (imagine it like a book)
The superstructure is dynamic, it is produced and added to the base when and where the pubblication is purchased by someone. (imagine it like a 3d printed something)
The production of the superstructure inflates the temporality of the loot box: our narration can inhabit this timespan.
While someone wait for the 3d sigil to be printed we can offer a temporary safe zone: a checkpoint at PNF (or other locations)
In this temporary safe zone the player can leave something for the next player by designing the next sigil and
In this temporary safe zone the player can be guided through the contents of the pubblication while waiting for the superstructure to be produced
When a new copy of the pubblication is bought, a sigil is 3d printed and then uploaded on the website of the SI17 as documentation

1. Physical pubblication (a book? a box? something)

I don’t really know which kind of contents, but since we are reading a lot could be intresting to prepare a critical reader about the loot box issues, collecting different perspectives and heterogeneous voices? Then production mode ok and then we print say 100 copies. Our magical technical book binding team figures out the best way in which we can add some dynamic components or 3D addition to the cover-object-book, but we don’t do that yet. We just leave the pubblications without the 3d cherry on the cake.

2. A custom 3d sculpting software

Note that the process could be also implemented with totally different techniques based on digital manufacturing like wood working with cnc, laser cut, etc endless possibilities, but let’s say we want these exoterical 3d printed sigils.

We can develop a simple 3D sculpting software that even people not used to 3D modeling could use. Something like this SculptGL. This is not super easy to do, but not as hard as an API. We could start from some open source thing and then customize it in the way we need. Blender is written in Python and has a super nice API for programming custom plugins, for example.

Side note totally (not totally) unrelated: plugin republishing? 🤯 Ahah it would be great to publish some excerpts from Simone Weil inside the UI of Blender or Photoshop or whatever. Injecting culture in the cultural industry tools.

3. Some templates for the 3d sigil

material and practical needs
SI17 visual identity as a starting point
SI17 contents as orientation
SI17 world building as heading

(wip)

4. A 3D Printing device

A 3D printer
Some interface to sculpt the next 3d seal (aka 1 pc)
A nice setup for display everything (checkpoint? treasure chest? loot box?)

(wip)

5. A website

Info
Inventory that keep track of the sigils (world building)

(wip)

Multi Player Loot Box

Notes to generate relations within the public If the public of the classical loot box is made of individuals that are easier to exploit, our SI17 could research on ways to generate relations within the public.

Homogeneous public?

The classical loot box assumes two main things:

That the public is an homogeneous group of individual users
That the relation between the loot box and its public should be always the same

The loot box offers a limited amount of agency to the player. There is no quality in the interaction with it. The only way to use and access its content is to open it (and this usually means to pay). From the point of view of the loot box every player is the same, an their abilities or features or uniqueness have no meaning at all. One could say that the loot box is a popular device since is an object with a common interface for everyone, but is this really the case?

The interaction with the loot box has no quality, but for sure it implies some kind of quantity. To access is it required to spend a certain amount of money or time. This quantifiable expense is presented as a flat access scheme with homogeneous outcomes, but it is not. The effects of spending hundred €€€ in Fortnite skins are different for a kid and a streamer, for example. While the streamer on Twitch spends 800€ in a row to gain a thousandfold through sponsorizations and views, the average kid just throws away half of his mother’s monthly income.

The public of the loot box is not homogeneous.

Keeping that in mind, we could rethink the basic way of interaction with the loot box. What if we offer something different from the flat price scheme? What if someone can pay less to access to the contents and someone else must pay more? Could this be a way to inject different qualities in the interaction with the loot box?

Mimic research 📦

Exploring a tricky treasure trope

2 different types of treasure chest

In RPG games the Mimic is a monster that appears as a treasure chest. When a player tries to interact with it in order to get the contents of the chest, it reveals its true nature and attacks her. The name of the Mimic come from its act of mimesis: this creature is like a predator that disguises itself in order to sneak up on its prey.

A treasure chest in a game can be seen as a temporary safe zone because it interrupts the flow of incoming threats by offering a reward to the player. The Mimic endangers this temporary safe zone, and breaks a kind of contract between the player and the game. The treasure chest is transformed in a risky russian roulette, that inoculates danger in the safe zones of a narration.

I’m tempted to write here that the loot box is something like a meta mimic: an object that promises an in-game reward, but produces a damage to the player. What’s more is that this damage is inflicted in the real world, not to the player but to the person. What’s then the difference between a loot box and a Mimic?

Starting from the Dungeons and Dragons’ Mimic I’d like to explore the evolution and the ecology of the mimic through different games. How do the game designers choose where Mimics spawn? What are the relations between those creatures, the level design, the stress of the player, as well as her expectations and trust in the game world? Are there similarities in the way the Mimics and the loot boxes are presented to the player?

TODO: amazon package but has fangs

A Katamari Fanfiction

What's left when you roll on everything?

Modding narrative

After lunch we will be writing fanfic based on the games you played and analysed this week! Lidia said this.

We played Katamari Damacy this week → We wrote a fan faction about it → We approached the fanfiction with empathyzing with the most inanimate things of the game → So we focused on the prince and the objects of the game → We left the King of all Cosmos in the backgroud, since he talks already a lot in the original game. → Suggested soundtrack for the reading: katamari OST

Fun fictious with Mitsa and Erica

Loot Box as a Decorator

Hermit crab in the book store

3 intuitions come together

Right now:

A loot box within a context as such: a book store
A loot box within a temporality
A loot box with different kinds of public

Over me 🦶🦶 🥁 🦵🦵 📀—-

Context

A lolt box accellerates and forces the mechanics of an environment. In some games it can speed up some tedious process, in other it offers a specific special instant rewarding. Our loot bbx inhabits a book store, or more in general a cultural space. In which ways can we hack through the normal functioning of such place? At a certain point today I thought: ah, we could fill it with the last page of every books in Page Not Found, just to say something about the presumed shortcuts that the loat box promises to the player. The idea is kinda fun, but then what? So maybe no.

Temporality

A couple of days ago I wrote some notes about the temporality of the loto box. In 1 sentence the idea is: if the lot bx is a mechanism of instant rewarding, we could hijack and inflate its tempo and then fill it with our contents. Instead of opening in 30 seconds, the loot bocs takes one hour. Meanwhile we can deliver our messages.

Today I read Play like a feminist by Shira Chess and guess what: there’s an entire part about the temporality of leisure → 🤯

There is something really important we should keep in mind: we are aiming to a public that is etherogeneous. The intersectional approach that Chess advocates it’s a reminder that we can inflate the temporality of the loot biusch, but not everyone will have access to it. So we need to think at both the limits of this spectrum, and put them in a meaningful relation.

Public

As said: our public could be complex. For sure there will be some ultra publishing nerd that will sip all our soup and will be happy with it, but isn’t 1 of our goals to reach also the world outside XPUB? Chess in her book writes about micro temporality, little timespans carved between work shifts or commutes. She has a point when writes that with smartphones leisure time is more affordable and is detached from the rigid tempo of labour.

Decorator

Combining these three aspects the question is: can we create a relation between who can spend an hour at PNF waiting for the loot bosx and who cannot?

Enter the boot lox as a decorator.

A decorator is something that adorn something else. In Python and object-oriented programming in general is also a name of a design pattern that adds some functionality to other functions. We used it already also with Flask! A oobt olx as a decorator means that we could attach it to other pubblication at PNF. Something like an hermit crab inside other shells or that spiky things that bites the tail of a Slowpoke.

The setup

The physical decorator, that is a digital manufactured object produced on demand
A catalogue of books that can be decorated
A website with a digital loot box

The process

As a part of the research we compose a bibliography that is also a statement i.e: away from the cis white west guys gang. This bibliography could be site specific for PNF or the other places we will distribute our SI17. We should choose to sell our pubblication in book stores or spaces that want to host this bibliography in their inventory. In this way we can use our SI17 as a device to reclaim space for marginal and subaltern voices.
The decorator inhabits this bibliography. It is presented as a special offer in which you can buy one of the book from the bibliography and receive a decorated version of it. Maybe we can sort out some kind of discount mechanism using part of the budget we have. The point is to favor access.
The deal is that the production of the decorator has a certain temporality: if we imagine it as something that is 3D printed or laser cutted or CNC carved on demand, it involves a little waiting time. During this waiting time we can transform the book shop in a library, and offer full access to the titles in our bibliography.
In exchange we ask to the reader for some insights, notes or excerpts from the books. Those will be inserted in the inventory of our loot box.
This loot box can be accessed online from the website of SI17. It works exaclty as a classic one, except that we offer it for free. The content is a collection of thoughts questioning the issue of our project, in the context around our bibliography and readers. It could be an effective way to offer our research to that kind of public that has no means to access it.
To open the online loot box and get one (more or less random?) excerpt, the user is asked to draw a decorator. This could be made with a super simple web interface. The drawing will be the next digital manufactured decorator.
In the website of SI17 we can keep track of the decorators as well as the exceprts, in a process of inventory and world building.

Skin care routine

This idea of decorator is somehow similar to the concept of skin (in videogame terms). Here our decorator acts as cosmetic in the same way a fancy hat decorates your sniper in Team Fortress 2.

In the game itself the skin is nothing more than a visual candy. But once you look at the turbulence it puts in motion in the game superstructure, you realize that the kind of power-up it offers is something that acts in the social sphere around the game. (See: peer pressure, emotional commitment, skins gambling, product placement, collectibles)

A loot of lot boxes promise rare skins, and by doing so it lures in players. We could subvert this process by taking the skin out of the box.

Instead of opening it to get a new skin, you design a new skin (the decorator!) to open the loot box.

🥐 XQUISITE BRUNCH 🥐

A branching take on the exquisite corpse game

An exquisite branch

The exquisite corpse is a multiplayer game invented by the surrealists in which the participants compose a drawing or a story together.

Traditionally the game is played on a long piece of paper, and each player draws a part, hiding the drawing to the next person, but leaving some hints. The following fellow continues to draw from there and so on. The result is a weird linear narrative, in which the transition between authors are at the same time smooth and abrupt.

With the xquisite branch I would like to try a digital approach to the game. If the original version is constrained to the single piece of paper and is doomed to be linear, here we can imagine our drawings forking and branching and go in different directions.

The process could be something like:

someone send you a link to continue the drawing and when you are happy with it and upload it you receive a new link to share with others. If you pass the link to just one person the xquisite branch will continue, but if you pass it to several people the drawing will branch, resulting in multiple version with a common starting point.

I would like to try this not only as a multiplayer game, but also as a creative tool. I will ask ser togni if he want to draw some comics with it. But it could also used for branching meetings aha 🤯

TODOs

add name for credits?
display name in svg?
comment the code
remove new from homepage? or
add per-new level in the xquisite branches (this makes more sense!)

Flask that soup 🥥

Confy Flask setup on the Soupboat This is a template for simple and scalable Flask apps on the Soupboat. One of the main feature of this setup is that it enables a seamless work between local development (namely your computer) and the Jupiter Lab environment in the Soupboat.

This approach proposes these features:

Url prefix

The Soupboat has some problems with generated URLs, and when we developed the app for SI16 we had to put every link + ‘/soupboat/si16’, that was more a hack than a real solution. This setup fix it with a middleware that intercepts every request and adds the prefix automatically.

Easy debug

To develop directly in Jupiter means to stop and restart continously the app to see the changes. With this setup we can work in locale and push the results when we are happy with them.

Modular

Taking advantages of the Flask Blueprint system and Python modules, we can write a legible structure for our app, and then go crazy inside the blueprints of each page or super specific modules. In this way the code remains readable, and the relations between the different components are rendered clearly.

Guide

Create a folder for your project. This will be the root of the app. Create a virtual environment in the folder. Open the terminal and write:

python3 -m venv venv

This will create a venv folder after a while. Then activate the virtual environment.

. venv/bin/activate

In this way every package we will install will be in the scope of the virtual environment, and this helps to avoid conflicts between different versions and projects.

Now we can install Flask.

pip3 install flask

Once we have installed it, let’s create a folder soup_app for the Flask application. Here we will put all the modules needed for the flask app. In this folder we can create a __init__.py file, in order to make the folder to be recognized as a Python package.

Here we will initialize a factory for our Flask application. Instead of writing the application directly, we will write a function to generate it depending of the different environemnts. This comes handy when we want to develop our project in locale and then push it in the Soupboat. For more about the concept of factory here’s a nice series about design pattern:Factory Method Pattern.

The basic structure of the app is something like

# __init__.py

# import os to create the folder for the app
import os

# import flask to init the app, and send_from_directory for the icon file
from flask import Flask, send_from_directory

# url_prefix module to work either in local and in the soupboat
from . import prefix


def create_app(test_config=None):
    # Create and configure the Flask App
    app = Flask(__name__, instance_relative_config=True)
    app.config.from_mapping(
        SECRET_KEY="dev",
    )
    
    
    # load the instance config, if it exists, when not testing
    if test_config is None:
        app.config.from_pyfile("config.py", silent=True)
    else:
        # load the test config if passed in
        app.config.from_mapping(test_config)

    # ensure the instance folder exists
    try:
        os.makedirs(app.instance_path)
    except OSError:
        pass

    # create an endpoint for the icon
    @app.route("/favicon.ico")
    def favicon():
        return send_from_directory(
            os.path.join(app.root_path, "static"),
            "favicon.ico",
            mimetype="image/vnd.microsoft.icon",
        )

   
    # here we can import all our blueprints for each endpoints
    # home blueprint
    from . import home
    app.register_blueprint(home.bp)

    
    
    # register the prefix middleware
    # it takes the url prefix from an .env file!
    app.wsgi_app = prefix.PrefixMiddleware(
        app.wsgi_app, prefix=os.environ.get("URL_PREFIX", "")
    )

    # return the app
    return app

The home blueprint can be something as easy as

# home.py

from flask import Blueprint

bp = Blueprint("home", __name__, url_prefix="/")


@bp.route("/")
def home():
    return 'Hello world'

While the prefix it’s a bit more abstract: it takes every incoming request and prefix it.

# prefix.py

class PrefixMiddleware(object):
    def __init__(self, app, prefix=""):
        self.app = app
        self.prefix = prefix

    def __call__(self, environ, start_response):

        if environ["PATH_INFO"].startswith(self.prefix):
            environ["PATH_INFO"] = environ["PATH_INFO"][len(self.prefix) :]
            environ["SCRIPT_NAME"] = self.prefix
            return self.app(environ, start_response)
        else:
            start_response("404", [("Content-Type", "text/plain")])
            return ["This url does not belong to the app.".encode()]

If you execute flask run from the terminal now it will complain that there is no flask app defined in the environment variables. We could fix it setting manually the name of the flask app directly in the terminal, but we should do that every time we start the project.

Hence we will install python-dotenv, a library to use a .env file to configure the application. We will use different .env files depending on where we will deploy the application: one for our local development and one for the environment in the soupboat.

pip3 install python-dotenv

Now we can create in the root of our application (the same folder with the venv and flask-soup directories) a .env file, that the application will recognize automatically.

The contents for the local development will be something like this:

FLASK_APP=postit
FLASK_ENV=development

while in the soupboat we will add the url_prefix property:

FLASK_APP=postit
FLASK_ENV=development
URL_PREFIX=/soupboat/flask-soup/

If you now run flask run the application will start at the address localhost:5000, and you can debug and play around with things.

There are a couple of other files we can add in the root directory:

A setup.py module, useful for installing all the dependencies we need for our project (at the moment flask and python-dotenv)

# setup.py

from setuptools import find_packages, setup

setup(
    name="soup_app",
    version="1.0.0",
    packages=find_packages(),
    include_package_data=True,
    zip_safe=False,
    install_requires=["flask", "python-dotenv"],
)

and a config.py, to fine tuning the different configurations for the application.

# config.py

import os


class Config(object):
    DEBUG = False
    TESTING = False
    URL_PREFIX = ""


class ProductionConfig(Config):
    DEBUG = False
    URL_PREFIX = os.environ.get("URL_PREFIX")


class DevelopmentConfig(Config):
    ENV = "development"
    DEVELOPMENT = True
    DEBUG = True

The last file to create is a .gitignore one, in which we will indicate the files that git should ignore when committing our changes.

I’m using this template atm

# .gitignore

venv/

*.pyc
__pycache__/
.ipynb_checkpoints

instance/

.pytest_cache/
.coverage
htmlcov/

dist/
build/
*.egg-info/

.env

Notice that the .env file is ignored from your commits, so you will need to create one manually in each environment you wanna work.

Now you are ready to push the project to a git repo. Create a new one and follow the steps to push your contents on there.

On the xpub git should be something like:

git init
git add .
git commit -m 'Init my soup app'
git remote add origin https://git.xpub.nl/your-username/your-repo.git
git push -u origin master

And if it doesn’t complain nice we are ready to go on the soupboat (or wherever)

TODO: finish this

steps:

clone the repo in the soupboat
create a virtual environment in the cloned folder
activate it
pip3 install -e . (aka install the dependencies)
create a .env file with the prefix
setup nginx

Chaotic evil puzzles

Jigsaw puzzle as a form of encryption of our SI17 ==== There are 100 lot boxes with 100 different jigsaw puzzles of 100 pieces.*
100 boxes compose the face of aymeric if seen from a precise point of view ====

* (exact quantities to be defined)

The picture on each puzzles is a content related to our experiments, games and researches for the SI17

File:Https://hub.xpub.nl/soupboat/~kamo/static/img/catchy-puzzles.jpg

caption sample of contents for the puzzles

Each puzzle is an A2 sized image displaying the works we did during this trimester, designed in a way that can be interesting for the players to buy it, even for the sake of doing a jigsaw puzzle itself.

f.e. A puzzle could be the rules for an RPG; or the map of a bitsy game with some critical texts about gamification; a generated maze, a fan fiction, the glossary, the list of one sentence games, etc.

In other words, the collection of puzzles will be a sort of inventory of our research framed in the form of jigsaw.

The pieces are scattered through all the loot boxes, in a way that each one contains parts of multiple puzzles.

File:Https://hub.xpub.nl/soupboat/~grgr/static/img/jigmix.png

caption shuffle of the jiigsaw pieces

This could be done in a meaningful way: the idea is not to have total random pieces, but legible fragments from each content.

When players buy the loot box they can compose the puzzle, but the result is a patchwork of different images.

File:Https://hub.xpub.nl/soupboat/~grgr/static/img/patchworks.png

caption in each loot box there is a patchwork of different puzzles

If the puzzles have different images but the same pieces pattern, each loot box can have a complete puzzle, but with mixed pieces. In this way we can avoid the frustration that having an incomplete jigsaw puzzle could cause.

On the website of SI17 the players can upload their fragments, and compose together an online version to complete all the jigsaw puzzles.

File:Https://hub.xpub.nl/soupboat/~kamo/static/img/puzzle-web.jpg

caption demo web interface

We can numerate or identify each piece of the puzzles with a code. This could be done when we generate the pattern of the puzzle with Python 👀. To upload a fragment of puzzle, the player is required to insert the code of the pieces, and maybe take a picture. In this way we can be sure that only who has the fragment can insert it online.

Optional feature: users can upload pictures of their fragments and we could have a collective documentation of the work.

demo upload pictures This is not unpaid work, it’s participation

Nice feature for the website could be that you can see the digital version of the puzzle, but on mouse :hover we could show the pictures from the public. A puzzle of photos of puzzles. This could be challenging but funny to develop.

On the website of SI17 there is a community section for exchanging the fragments and complete the puzzle

File:Https://hub.xpub.nl/soupboat/~kamo/static/img/xchange-puzzle.jpg

caption demo xchange puzzle fragments

The community section with users and exchange etc could be tricky, but we can stay as simple as possible and do it with Flask. The exchange section should exclude by design the speculation on the pieces or money. A fragment for a fragment.

On the website of SI17 the public can access to the experiments, games and researches as well

File:Https://hub.xpub.nl/soupboat/~grgr/static/img/lootbweb.png

caption demo other contents on the website

In this way we can provide access to the contents such as the bitsy games, the karaoke video, the ruleset of our games, the reading list, etc.

Risk / Benefit assessment

PROS + simple to make + accessible because it’s a well known game + a lot of design + not to much code + use what we already have + interesting interaction with the public + performative element ready for the launch + multiple temporalities (individual puzzle, contents, shared puzzles) + world building

CONS: - not an API 👀 - i don’t like puzzles - people mught not appreciate the fact of missing parts of their puzzle, but we’re here to subvert it, and contents will be available online anyways

Bonus: summary workflow

production The process to make the puzzles could be easy as design - print - cut - shuffle - package, nothing more (+ website)

box The loot box could provide a context and the instruction of the game, as well as the link to the website.

Scenario

Mapping the chaotic evil puzzles in the through the different scenari

of the form

scenario 1: The lootbox is a physical box that contains something

Fragments of several puzzles.

of the feature

scenario 7: The items in the loot-box are complementary and it is necessary to connect with other loot-box owners in order to assemble the pieces together.

There is a single player aspect and there is a collaborative aspect. These two components could be mediated by an online platform, such as the online shared puzzles, but could also work offline if people just combine the pieces of their loot boxes.

of the contents

scenario 2: The loot box is a collection of the prototyped games (and researches!) we did so far curated in some kind of form

The jigsaw puzzle is just a form of encryption of our contents. A shared surface in which we can publish really different things such as a fan fiction, a board game, a link to a video karaoke or a videogame, an essay, the characters of a roleplaying game, etc.

scenario 3: The loot box is a collection of mini-games + an ultimate game that has to be performed with other players that purcahsed the LB

There are several layers of playability and access:

to solve the fragments (single player jigsaw)
to access the contents (games, texts, etc. )
to combine the fragments (ultimate multiplayer game, re-distribuition of the loot boxes contents)

scenario 6: The lootbox contains a series of jigsaw puzzles but their pieces are scattered through all the boxes and there is a platform online where you can see the missing tiles.

Nothing to declare.

Prototype (look at git!)

This is a rough prototype for generating ready-to-print jigsaw puzzles as well as a way to track their completion in a shared platform. The idea is to have several puzzles and mix their pieces, in a way that invites the players to collaborate in order to solve them.

This prototype covers two aspects of the process: the first is to split an image into pieces, tracking every piece with an ID and store the relation between adjacent tiles. The second concerns the online platform, and it is a Flask application that permits to upload cluster of pieces in order to share them with the other players and unlocking the full puzzle.

To install the project:

Clone the repo
Create a virtual environment $ python3 -m venv venv
Activate the virtual environment $ . venv/bin/activate
Install the dependencies $ pip install -e .
Set the environmental variables for flask $ export FLASK_APP=flaskr $ export FLASK_ENV=development $ flask run
The Flask application will be accessible on your browser at localhost:5000. If you try to navigate there you will see a blank page. This is because we need to generate some puzzles to display.

Generating the contents

The first thing to do then is to run the split.py script:

python3 chaospuzzles/split.py

This will take the Katamari demo picture from static/img and will split it in tiles. The tiles will be used to compose the clusters when a player upload it online. In this way we can be super flexible in the randomization / distribuition of the pieces.

You can tweak the parameters at the end of the split.py file. This is temporary, later on it would be nice to have an interface to prepare the puzzle.

Completing the puzzles

If you reload the website, you will see a link pointing to the Katamari page. Here we will find an empty frame, and a form to insert new pieces.

Try it! You can find the IDs for the pieces in the chaospuzzles/puzzles/katamari/katamari_retro.png image. This is the picture generated in order to be printed behind the puzzle and let every piece to have a unique ID.

By design an valid cluster is a group of adjacent pieces.

Keep in mind that this is a wip and rough prototype so everything need to be polished a lot. We count on your imagination to fill the lack of design, UI and UX here. Imagination is the best modern feature of 2022!

Thanks and see you sun ☀️

memos

play with quantities and distribuition of pieces (1 piece only, large groups, variations, etc)
play with puzzle pattern: alternative to the mainstream shape of the tiles
pieces naming system
And then the aim is to exchange pieces or something and rebuild the original puzzles? (can this be a critical approach?) (does this make sense only if there are as many puzzles as loot boxes?)
short term puzzles (link to multimedia contents, puzzle shards)
long term puzzles (hidden messages, 1 word in each puzzles and a secret sentence)
size and quantity
The jigsaw puzzles results should be secret? There would be much more mistery. Can we reveal only during the launch, but not on the loot boxes? Maybe is a compromise, but maybe is not necessary. Should we reveal them only in the website meanwhile they are completed? Could be.

SI17 producing the public

homeworks for 21/02

Which kind of public do we want to produce?

If the loot box and gamification produce a single player in competition with all the others, I would like to produce a collaborative public. More like a community than a billboard with users ranking. Also I think this is an operation that requires time. Hence the loot box as a shrine: a safe place to build, discover and charge with meanings together.

How do we want our public to engage with our loot box?

I like the idea of different temporalities and the concept of slow processing. Something could be delivered really fast, something could require an entire evening, something could need to wait an entire month.

We should balance the single player / multi player aspect of the loot box. It would be great to have something that one can enjoy both alone and with others. The collaborative aspect of the loot box should be something possible and encouraged, but not mandatory.

What kinds of questions/feelings/thoughts it create ?

To feel part of a community or fellows in a shared quest.
To wonder how vast is the inventory of the loot box.
To question the idea of competition as necessary for gamification
To raise awareness on different voices on the topic

How the lootbox is going to be presented to our public during our launch event?

The presentation could perform the contents of the loot box.

How will the launch look like?

Nice

How can the lootboxes be activated by the public in a sustainable an independent way after the launch?

With a website

What is our relationship to PnF?

I don’t know

Does the publication relate to PnF? how?

I don’t think so

how and where do we sell the lootbox?

In place that want to host subaltern authors from our reading list.

do we sell in other stores? if yes how are they connected?

We are the connection

test static files in project directory

it's a test

Hello this is a test.

This image is in the same folder of the project, not in the static one.

File:Hiroshige.jpg

caption test

and it works!

and now also the md file that generates the page should be accessible.

is this a good idea?

Soup to Wiki

Teleport this log to the wiki (teleport not ready yet) Since the Soupboat is fragile and temporary (like everything else?), it’s nice to keep this documentation updated also in the Wiki.

ATM i’m using this notebook to do a simple conversion from all the markdown files of these pages to wikitext. In this way it’s less painful (but also less curated?) to have the wiki up to date. It uses pypandoc, that is a python wrapper for pandoc.

import os
import frontmatter
from datetime import datetime
import pypandoc

def list_folders(folder):
    ''' Return all the folders in a folder '''
    names = []
    for entry in os.scandir(folder):
        # add to the list only proper files
        if not entry.name.startswith('.') and entry.is_dir():
            # remove the extension from the filename
            names.append(entry.name)
    return names

def get_md_contents(filename, directory='./contents'):
    ''' Return contents from a filename as frontmatter handler '''
    with open(f"{directory}/{filename}", "r") as f:
        metadata, content = frontmatter.parse(f.read())
    return metadata, content


# in the projects directory there is a folder for every project.
# The info about the project are in a "documentation.md" file

folders = list_folders('public_html/projects')
projects = []

for folder in folders:
    project = get_md_contents('documentation.md', f'public_html/projects/{folder}')    
    project_date = datetime.strptime(project[0]['date'], '%d/%m/%Y')
    project[0]['date'] = datetime.strftime(project_date, '%d %b, %y')
    project[0]['categories'].sort()
    projects.append(project)

    
# the projects are sorted by date
projects.sort(reverse=False, key=lambda project: datetime.strptime(
    project[0]['date'], '%d %b, %y'))
    


# the variable page will be filled with wikitext
page = ''

# here we insert a bit of meta info such as the title and the description  
for project in projects:
       
    page = page + f"==={project[0]['title']}=== \n"
    page = page + f"''{project[0]['description']}''\n"
    page = page + pypandoc.convert_text(project[1], 'mediawiki', format='md',  extra_args=['--base-header-level=3'])
  
# and then i copy this result and paste it in the wiki 
print(page)

there are still problems (as always?) especially with the images, that need to be uploaded manually in the wiki……….. maybe i will provide super nice alt description to avoid this tedious workk sorry.

ok

Chameleon RRPG 🦎

A Random Role Play Game to inject micro scripted actions in daily life The game requires a social context and can be played by any number of players.

Each player is a chameleon that mimetize from the others. the chameleon hidden awaits for its prey: usuallly a random insect.

At the beginning of the game each chameleon is assigned with a random insect: a secret simple action to be done with a certain degree of absurd (provide examples)

If the chameleon manages to catch its insect without being noticed from the others the game continue.

When all the chameleons have eaten they win together.

If a chameleon finds out that another one is eating, it moves faster its sticky tongue to steal the prey. he win, but everyone else loose and the game ends.

If the chameleon who tried to steal the instect was wrong and the other was not eating but just mimetizing as always, the latter is hit by the sticky tongue in one eye, and the game continues.

To facilitate the mimecy and the secrecy the chameleons have developed a simple website from which each participant could receive an insect, and notify when it eats it. when everyone have notified their lunch the website ring and give an award to everyone

Post it generator

Prototype for web-to-print postit

POST-IT GENERATOR

~~TO AUGMENT OUR PRODUCTIVITY HERE IS A SCRIPT THAT~~
Generate post-it blocks from markdown files.

Install

Clone the repo

git clone https://git.xpub.nl/kamo/postit-gen.git

Move to the cloned folder

cd postit-gen

Create a virtual environment

python3 -m venv venv

and activate it

. venv/bin/activate

Then you can install the repo

pip3 install -e .

How to use

The package offers two scripts: template.py and generate.py.

template.py generate a template folder with a markdown file that can be used as a starting point for formatting the contents.

python3 template.py -f test

Will generate a test folder, with the markdown template for the contents.

The contents.md file has these properties:

title, the title of the block
folder, the base folder in which the files are
page_width, the width of the page for the printing
page_height, the height of the page for the printing
post_width, the width of the post-it for the printing
post_height, the height of the post-it for the printing
margin, the margin for the page
unit, the measure unit in which the measures are expressed, default is mm
background, the color of the post-its. Accept all the format CSS specs accept. Default is white.
contents, a list of contents to put in the post-it block. Each entry is a post-it.

All these parameters are formatted in YAML.

After setting all the parameters to match your needs, you can fill the contents. ATM you can insert text and images, in the form of a list.

contents:
    - A flat with no floors
    - Hello, where are you, what can you see from there?
    - type: image
      src: game.png

Usually each entry of the list will be considered as a string. If you want to insert an image you will need to provide a type: image, and a src: <filename>.

In this way:

contents:
    - type: image
      src: <filename>

Once you inserted your contents, you can run the generate.py script, specifying the working folder from which you want to take the contents.

python3 generate.py -f test

It will take the contents inside the test folder and will generate a ready-to-print HTML file, serving it with a simple http-server at http://localhost:8000/test. Opening that link you can preview your post-it blocks. Each entry of the contents list is now a page in the document (in the print mode!)

TODO: link css file in the template to work directly on the preview.

Post-it Contents

A repo to organize SI17 contents in a post-it guise

We are making 50000 post-it

The loot box contains a series of post-it blocks

Why the post-its:

because they’re a modular surface and offer an interesting format that also reminds the to-do list, the corporate strategies for collective brainstorming and organization, or the form of self- management. it’s visually accessible, relatable and familiar.
Interesting possibilities for further distribution and exchange.
The format of the post-it blocks it’s open to material experiments, since the block is just a bunch of sheets glued together. In this way we can adapt the shape of the sheets to fit the- contents while remaining in the same common surface/format.

File:Https://hub.xpub.nl/soupboat/~grgr/static/img/exchange model1.png

caption exchange model

Post-it blocks

each contribution is formatted as post-it block.

feature: we can experiment with the format of each block in relation to the contents feature: the post-it blocks can be enjoyed as mini booklets (linear access) feature: the post-it blocks can be enjoyed as modular elements to be attached on a map (complex access)

optional features:

the blocks can be collectible and exchanged by the players
in each block the contents are repeated many times so that you can give part if the block to people that don’t buy the LB and or
Exchange with other customer
Also, if in each block the contents are reapeted many times the player can easily experiment with the contents, use them and connect them with different contents, play with their quantities in forming a puzzle, give them to other people and spread them in many different ways.

File:Https://hub.xpub.nl/soupboat/~grgr/static/img/model distribution2.png

caption distribuition model

Contents organization

Each block is a folder
In each folder there is a contents.md file and media resources such as images
contents.md contains the meta and the contents of each contribuition, formatted as a YAML list

example:

---
title: One-sentence game ideas
contents:
    - you are in an empty room with 13 doors that are portals to 13 different worlds.
    - 5 min slow-mo epidemics, visual transmitted
    - every crisis is a simulation of another crisis
    - img: game.jpg
      alt: Game description
    - you receive a point for each moving/floating tile on the street you encounter
    - thermoSTATE - The state where no citizen has to feel cold
---

The entries in the contents list can be simple strings or images. To insert an image we are using the YAML object notation, specifying the img filename and the alt description that can be used in the layout. Images can be URL or file placed in the project folder.

we printed 85 000 postit for real

Web-to-print post-it generator app

Working on contents together

For SI17 we produced a pubblication in 850 postit. Fun and funny, but at some point also crazy. We generated the postit hell starting from the experiments and researches we did in the second trim, in a way to make room for each contribution but still a common ground.

After gathering all the materials we started splitting them to fit the postit format. We opted for self sustaining sentence approach. Each post-it is a concluded statement. Some of them invites a more linear narration, some others can just be combined with different variation.

To manage the contents and detach them from the layout and design of the postit, we set up a repository in git. Find more info here.

In the postit page it’s possible to generate the contributions included in the loot box. The Contributions list it’s basically an index of the pubblication. Since we have two kind of loot boxes we implemented a switch to change color also for the post-it.

Structure

The post-it generator is a web app built with Flask and Frontmatter. It uses the postit-contents repo as submodule, in order to manage the two things indipendently. In this way the work can advance on both sides without mess to much with the structure of each part of the project.

The postit flask app has these modules:

a dump.py module to load the contents from the markdown files and generate a contents.json file with a list of postit, organized by contribution
a crosswords.py module to generate the cells for the Crossword Imaginary Grid Game (that are created dinamically starting from the words in each crossword)
a prefix.py module to manage the url prefixer for hosting the app in the soupboat

and a couple of blueprints

a home.py blueprint to serve a homepage with the list of contributions, the color switch, etc.
a generate.py blueprint to manage the generation of the contributions, with two endpoints: one to generate all the contents and one for just the single contributions. It loads the contents.json file and

additionally we implemented also a git hook to regenerate the contents when something new is pushed on the postit-contents repo, but didn’t manage to make it works right now. There are some issues in the python-git module, and we were a bit in a rush.

The postit.html template takes care of all the possible modules we developed for the layout, that at the moment are:

Picture postit, with a monochromatic image that follow the main color of the pubblication (orange or purple)

    - pic: cover.jpg
      alt: this is a picture

Image postit, with content indipendent from the pubblication’s color scheme

    - img: cover.jpg
      alt: this is an image

Card postit, for The Leader card game, that is a motivational take on Quartet. Each card has an ID, a quote and scores for motivation, empathy, vision and positivity.

    - card: A1
      quote: If life is a game, play the game
      motivation: 90
      empathy: 20
      vision: 40
      positivity: 50

Definition postit, for the Crossword Imaginary Grid Game. This come in two versions: one for the pubblication and one for the launch event. The former has the following properties: word is the final word, that will not be printed on the postit but it will be used to generate the cell for the imaginary grid. The definition is the definition of the word. The direction can be V (vertical) or H (horizontal), and start is a point in a grid composed by letters on the x axys and numbers on the y axis. Category is the category of the crossword. Each category is a complete crossword. Ask Emma for more infos she’s the mastermind. For the launch we have also a different version with just the definition, the direction and the category.

    - word: Counterculture
      definition: It can be present as disturbance
      direction: V
      start: C16
      category: Ideology

The mimic colophon is a mess and not really the reusable module fair, I put it here just for sake of completion.

    - type: mimic-colophon
      original: original text
      original-credits: Austin Wood
      original-action: published
      original-date: May 03, 2017
      current: current text
      current-credits: XPUB
      current-action: '.replace("mimic", "loot box")'
      current-date: March 25, 2022

Dialogue postit is a layout that permit to put contents in the four corner of the postit, using the cardinal directions properties. NW will be top left, NE top right, SW bottom left, SE bottom right. Super usefull for the NIM dialogue and to combine some single word sentences in the definition of loot box.

- nw: top left
  ne: top right
  sw: bottom left
  se: bottom right

Standard text post it it’s a normal string entry in the contents list.

    - Hello a simple text

All the postit but the images and some really specific layouts (like the cards) have a footer with the title of the contribution and a progress bar instead of the page number. We decided on that in order to have the position of the contribution to be free in the loot box and not constrained to a single order. The progress bar is calculated on the amount of contents for contribution and it’s funny and less strict than numbers.

For the karaoke we slightly modified it in order to recall the animation that karaoke lyrics often have. Then there are some easter eggs scattered around just for fun.

Find the code commented in git!

The Web-to-print part is managed with Paged.js.

Post-it Visual Identity

How to deliver a pubblication in post-it format

Small pages big text

Working with the post-it format the team1 (supi, mitsa, erica, me) approached the visual identity with two things in mind:

The office aesthetic, that kind of default aura that surrounds workspaces
The blurred line between personal writings such as memos and todolists and formal documents.

We used the post-it format as a module. Short sentences, big font size, different writing styles, few images. The idea was to facilitate a non-linear combination across the original page order of the pubblication. We choose not to put page numbers: instead we opted for a progress bar in each contribution.

In the body of the post-it we stayed simple using a default sans-serif font. We used the Bitsi font from Supi and Jian for the covers of each contribution and the main index.

Post-it

We designed 8 types of post-it: from text and image post-it to complex card layout, we tried to embed the form of every contribution in the generator pipeline.

Text

The basic type of post-it was the text one. We went with a super big font-size and an unexpected alignment. After a certain amount of characters the font-size is set to shrink a bit for a small text version.

Text From What is a loot box?

Text Small From Life Hacks!

Dialogue

It can display text in the four corners of the postit. Used for the NIM dialogue and some single word sentence in What is a loot box?

Dialogue Dialogue

Definition and Cell

Definitions and cells are the main modules for the Crossword Imaginary Grid Game from Emma. Each cell occupies a position in a grid, and is used to build the crossword structure. The definitions indicate a starting point and some hints to guess the word.

Image Definition

Picutre Cell

Card

Card designed starting from the layout Miriam prepared for her version of the game Quartet.

Card Card

Image & Picture

For images we decided on a full page approach. We have two post-it: image is for normal images, while picture is for graphics that folllow the pubblication main color. Both can display a caption in overlay.

Image From Katamari Fanfic

Picutre From Xquisite Branch

QR code

For QR code we choose to be as messy as possible. QR carries a specific visual language. We tried to force it into something else by cloning each code in repetition, with a glitchy result.

NIM Fanfic QR codes

Covers

We played a lot with the contributions’ cover. The starting point was always the title of the special issue in the bitsi font. On top of that we designed some sketches related to the contents.

Katamari Katamari Fanfic

unfinished thoughts Unfinished Thoughts

NIM Fanfic NIM Fanfic

Crosswords Imaginary Crossword Grig Game

Index

For the index we used the combination of normal and bitsi font. This approach was reused then in the SI17 home page.

Index Index

SI17 Homepage

A simple static website to host the loot box Together with Mitsa, Erica, and Supi we worked at the homepage for the SI17: This Box Found You For a Reason.

We needed an online space to fullfill these needs: - Support the contents of the lootbox and host the online contributions - Document and promote the work and the physical object - Distrubute the contents of the loot box for free according to our license

The result is a single page that recall the small format of the postit by using super big fontsize and super small inline images. We decided to play with the idea of transparency typical of the materials we used for the boxes. The cursor itself mimic the big square side of the loot box.

The website comes in two colors as the pubblication does. The typeface is an innested Special Issue 17 made by Supi and Jian combined with the most standard sans serif of the internet.

File:/soupboat/~kamo/static/img/si17-home.png

caption SI17 home