Graphical shell

Label for a wine bottle, Scribus + Pierre Marchand, 2006.
Custom script for Scribus to generate a text where every letter has a random color.

How about?

Could we mix real programming into layout tools, to somehow link the ‘tick’ (functionalities, workforce?) of a program to the rhythm of layout? We are not talking about the automatisation of layout, but how laying-out could be brought on the same level as programming (and vice versa?). Scribus or Inkscape scripting APIs (‘An Application Programming Interface is a specification intended to be used as an interface by software components to communicate with each other.’) are just the beginning; the way Blender exposes its own actions very explicitly and in place of action, is already more appealing.

But: there still are no tools that allow you to program at the same level as other layout work, by putting the programming interface at the same level as for example ‘Brushes’ or ‘Properties Boxes’, which would make it (litterally) closer to the practice of design.

The Inkscape XML-editor is a hybrid: it is a text-editor but it also is a console. The XML-editor is great for local editing, but what if it would offer some console-features such as auto-complete or find and replace? Could the browser be the place to go? Does this really need to happen inside each software itself? It may help us if we begin to think of this form of laying-out as a series of micro-commands that each execute discrete functions.


Comparing different ways code reveals itself in design tools (GIMP-scripting, Blender, Inkscape, Scribus etc.)

Relational lay-out

Proportional layout experiment, Gijs de Heij, 2012.
Made to be viewed in a browser, css & javascript.


How about?

What if we would introduce relationships between properties of objects and their environment. This experiment extends css through javascript. CSS be based on the css properties of others, the browser window, simply math or a combination of the three. Since the window properties are the only variable parameters at this time a window resize only invokes a redrawing of the layout. This experiment tries to create a responsive, flexible design. Ideally this tool should have an graphical interface that allows users to define how properties are related. Enabling the designer to play with different types of awareness, interconnectedness between objects and their surrounding.

Experiment, exercise

Try this out manually in Inkscape: Bend of this curve relates to filling of this shape Distance between these two objects changes width of outline

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

Conversational control

Workshop during Brussels Co-position Research Meeting, February 2012, with Nik Gaffney as spontaneous and enthusiastic animator. We worked on scenarios for potential conversations between computers and designers, interaction between design decisions and computational optimization. This prototype would also have an option to let you ‘just start over’.

Workshop during Brussels Co-position Research Meeting, February 2012
with Nik Gaffney as spontaneous and enthusiastic animator.

  1. Do all these elements need to fit on one page? YES
  2. Should all elements be legible? YES
  3. Can we make this page bigger? NO
  4. [system makes a proposal]
  5. Do you like this better?
  6. [user making changes] YES

How about?

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


Setup a multi dialog situation around a layout construction, with some ask questions to others in rounds. And these rounds are commented as commits, to produce a written history of decisions.