A first harvest of future tools that were brought to the surface at the Co-position Research Meeting:
Commit unbaked area only
From the understanding that design files are always collections of elements (each with their own properties and timelines), we tried to think how to version selectively. A design file contains both fixed and fluid areas (some elements stabilize early on, and others might keep changing), could we think of a way to mark areas as ‘unbaked’ and only track changes for these areas?
Versioning a design-file means tracking changes between different stages in a process, rather than comparing lines in code. Looking at a diff for a Scribus file is at best confusing, and current versioning tools are not helping much to understand differences that matter to design. Since each program is already saving state data, could we use this information to make more intelligent versioning possible? Inspired by so-called edit-decision lists that are used to store edits outside the actual rendered video-file, we discussed the possibility of recording a creative process rather than the result of it. If the data is stored in a separate file, could this be used to reconstruct a design? What kind of ‘actions’ would it need to contain?
If we see design as a practice that seeks to articulate collisions, how could computers be of use to help organise them, to make them visible and legible? We worked on scenarios for potential conversations between computers and designers, interaction between computational optimization and design decisions. This prototype would also have an option ‘just start over’.
Do all these elements need to fit on one page? YES
Should all elements be legible? YES
Can we make this page bigger? NO
[system makes a proposal]
Do you like this better?
[user making changes] YES
Saving space without negative effects on legibility, could that be possible? This script removes all spaces between words and creates a gradient in letter colouring instead. As a word gets closer to its end, each letter gets progressively lighter (Python script, works with Scribus API). http://blog.manufacturaindependente.org/2012/02/implied-spacing
Lazy Landscape lay-out
We looked into Lazy Landscape, a novel way of sharing and running software inside our browsers. While we explored and got baffled by its intricacies and fixed a few bugs, we wondered how far we could take it to have a new kind of layout tool based on flows and filters. It took us only an afternoon to create the skeleton of a text engine. http://xvm-2-183.ghst.net
A commit signifies a difference that matters, but they are identified with a row of arbitrary numbers. How could these hashes be more meaningful? Could they express something about the character of the commit? How could they be more visual? We looked at http://unicornify.appspot.com and developed some images of our own.
More ideas for whitespace implementation
When we started imagining tools from the perspective of whitespace, we came up with many ideas for new types of lay-out. A few examples:
- Dactylo space: Specific spaces at specific places, after a full stop for example.
- magnetiz0r: Activating white space reveals the story http://dillydallyfoundry.com/whitespace/6.php
- Mouse trapper: Touching is erasing http://dillydallyfoundry.com/whitespace/8.php
- Warp & blackhole space: 3D on text-lay out, really
- Rock salt: Random spacing, random angles http://www.yagraph.org/images/rocksaltwhitespace
- Rivers of salt: By flowing through the text, space shapes a never ending tale http://ideeale.free.fr/tmp/necessity_of_salt.pdf
Multi-level type design interfaces
Type design is an iterative process of refining design directions. Starting from a better understanding of what happens when you design a font, we worked on a type design environment that moves more fluently between different scales of design: From single glyphs to letter-pairs and textblocks but also to move between different versions of both digital and hand-drawn sketches. Some of these features can be already discovered in Fontmatrix: http://oep-h.com/fontmatrix
Adding a ‘save-as-commit’ option to Inkscape, Scribus and/or Gimp could prevent the sometimes unnecessary harsh transition from design environment to git. Hypothesis: If commit-actions would be better integrated into the design workflow, the spirit of the design process might be better preserved in the commit history.
Shared undo histories
Programs already save undo histories, so why can’t we write those changes as commits? This idea got also referred to as ‘shared action lists’, but that sounds a lot less promiscuous. We liked the possibility of distributing painful discoveries and propagating our mistakes.
Space revelator is a tool to test the way Scribus acts on white spaces (and its support). It uses a squared-glyph font to help designing spaces: http://www.cgemy.com/public/Scribus_whiteSpaceAction.pdf
Toonloop-audio (or: Philip Glass machine)
In a parallel workshop taking place at JES, A Pure Data patch was developed that records audio fragments while Toonloop grabs a frame, and than plays it back in sync. So now Toonloop can do multimedia stopmotion!
What if we could generate believable lay-outs based on almost-right interpretations of classic rules? A persiflage on canonical grid lay-out or how to make Villard eat a snake. http://pzwart3.wdka.hro.nl/~lspeybroeck/whitespace/5.svg
The Unicode Standard is far from easy to navigate. A complicated war history of competing interests and ever-changing ideas about how to make place for All Languages of The Universe means that related glyphs are often spread out over 17 ‘planes’ and sometimes even fractured into multiple code-points. Why not make it easier for users to re-arrange glyphs according to their needs? We could work with experts to design pre-sets for specifc languages. Rarely used glyphs could be pushed into the periphery and more common ones could take center stage. These re-mappings can than be loaded into type design applications such as Fontforge. This could stimulate type-designers to prioritize their work on sets of relevant glyphs, instead of just concentrating on the first plane(s).
We tried to rethink the text-only and bureaucratic interfaces of current commit-repositories. What if you could visualize the depth of changes, the variety of mimetypes involved. What if you could understand difference at a glance?
OSP developed a working prototype that we tested and tried: http://git.constantvzw.org/?p=osp.tools.visualculture.git
Many people contributed to these ideas: http://lgru.pad.constantvzw.org:8000/42. Thank you for making this four rigorous, rich and productive days!