Interfaces are a solid object

This article originally appeared on Progetto Grafico #33. Differently from the rest of the content, I wrote it in Italian. Isobel Butters took care of translating it in English, Silvio Lorusso was my editor. Given that the issue is now out of print, I decided to add it here. I believe it is a useful addition to the manual; it adds a few answers to the question "Should a designer code?". Enjoy the reading!

Progetto Grafico asked me for a contribution on the value of programming in teaching graphic design. On various occasions member of the editorial board Silvio Lorusso and I have discussed the merits and limits of programming and the close relationship with the tools that ensues. Two years ago I was appointed teacher of the basic IT course at ISIA in Urbino and at the request of the then director Luciano Perondi I moved the syllabus from the usual desktop publishing software to programming. I also embarked a few months ago on the task of writing a programming manual in Python language for my students. “I’ll have no trouble writing this article,” I told myself. Instead, it has proven tricky. Finally, I realized why it was causing so much difficulty – it was not the technicalities or the abstract nature of some of the concepts, but the fact that learning to program for me turned out to be an emancipation process. And the process of emancipation is by nature personal.

The designer’s work is based largely on a dialogue with monoliths of metal, glass and ceramic that we understand less every day and delegate more and more substantial slices of our work to. They have already taken over the places where images were produced – places once populated by printing machines and photo enlargers. The price we are paying to lighten the weight of our labor is a loss of contact with the materials that characterize it. The relationship between designer and the execution of his or her ideas is mediated by that often impenetrable panel now a part of everyday speech: interface. We abdicate a degree of control to this smooth surface in exchange for comforting simplification. The aura of competence afforded by the manual and technical skills of professionals has vanished, and with it the collective perception of a trade: “It’ll only take you five minutes, right?”.

An Impenetrable Desk

The economic model on which production of digital work tools is based is a devotee of the scalability mantra. Since distribution of the software takes place in the liquid realm of the Web, the latter is not forced into the logistic confines that characterize any other material goods. The result is a rapid contraction and expansion of exchanges. The production costs of multiples are almost non-existent, as is the difficulty to duplicate fraudulently. The aim of developers is to sell enough licenses to cover promotion and development costs, while all the rest is profit. From the design point of view this encourages tool designers to aim to satisfy the needs of a very large number of customers, while seeking the complex balance between userfriendliness and specialism. In the political jargon of a few decades ago, this approach would have been defined as a desire for an absolute majority. Its maximum aspiration is, after burning piles and piles of banknotes, to dominate a sector through monopoly. And behind every desire for an absolute majority there is a desire for a plebiscite.
In the compromise between large numbers and complexity of access, not all possible scenarios will be taken into account during the tool’s development. Some problems will require a sequence of very inconvenient operations in order to be linked, especially repeatedly, resulting in that strange feeling where you find yourself clicking for hours yet producing very little. In computer jargon these settings are coded in user stories, informal descriptions of typical scenarios. Let’s imagine the user story of Indesign’s “print booklet” function: “As a graphic designer for a small agency, I want to develop a 16-page booklet in order to print a prototype to discuss with my art director.”
Most of our daily digital activities have found space on some IT development company’s post-its. This is one of the various methods by which product designers keep track of software development. It is logical at this point to ask whether the user stories are made to fit our profession or do we progressively adapt our work to what the available tools are capable of doing? By definition designing means producing solutions that do not exist yet. If a solution we think up has never been produced before, it is reasonable to assume that it might never have been codified within a user story. Therefore, the most suitable digital tool to implement this solution might be missing. The question that arises at this point is: if the tool is missing, do we change the solution or create the tool? The budget and skills available for
the project usually provide the answer to this. The most common tools will not serve radical designers. Those with their own opinion about working methods feel the need to be able to sharpen their tools independently.

The shape of the tools

Every tool is the outcome of a vision that aims to define the range
of action. The width of this range is inscribed in its form. Let us consider the handle of tools we use every day – it says a lot about the way the tool is intended to be used. The less specific a tool, the more shapeless it is. I do not think it absurd to believe that the reason why User Interface (UI) and User Experience (UX) design disciplines have flourished is directly due to the need to get us communicating satisfactorily with monoliths that say very little about the way they would like to be used. Let’s compare a pasta cutter and an ordinary table knife: the cutter is specifically designed to cut something thin and soft - like edible pasta - while a knife has a much wider range of options. The different shape of the two instruments shows this clearly.

No mechanic would disassemble a component from a car using a Swiss army knife, unless it was the only tool at his disposal. The lack of specificity of a tool makes any task performed with it more complicated, especially if repeated. In an emergency you make do, but you don’t base your work on exceptions. How is it that image designers do not feel the need to use more specific tools? Has digital razed their workshops to the ground?
Desktop publishing software - like personal computers in general - have condensed a myriad of features within a single large confined space, discouraging research and development of alternatives. Let’s not forget that for commercial reasons they are designed to communicate little with the outside. Unless two digital tools are developed by the same company, it is unlikely that they will be able to exchange data and functionality profitably. Cases where a file’s working format is shared by applications developed by multiple entities are very rare. More often than not an export format - like PDF - becomes a de facto standard.

Programming then can become a way to escape this confinement, connecting different regions and patiently rebuilding the workshop within the tools that effectively destroyed these regions. It is a way of starting to produce radical tools again, useful for doing one thing perfectly rather general purpose: exactly what design and the designer need.

How the education system betrays us

Simplifying drastically, we could put an expiry date on skills. For
example, the theoretical principles that underlie the composition of movable type are crystallized in the history of the method (so there is no expiry date), but composing lead type by hand will not prove very useful in daily life. However, it will be useful to remember that knowing how to compose type manually will help to impress on the mind similarities and differences between composing lead and silicon. There are many seemingly useless skills that regain enormous value if translated into contemporary practice.
Teaching is therefore based on a delicate balance between skills with expiry dates and those with different types of use. One of the greatest difficulties often lies in demonstrating the value that teaching some skills not currently of use can have during the course of continuous training.
The pace at which educational courses are updated and organized are not (and should not try to be) the same as in the professional world. The rate of change in informatics and technology is oppressive. By their very nature schools and universities should not pursue unsustainable rhythms, but rather concentrate on medium-term skills that allow the student to make their own way once training is completed. No one can state with certainty how the work of the graphic designer will change over the next few years and the least an educational establishment can do is to try is to equip its students to manage their skills autonomously.
On a technological level, I consider it wrong to teach the use of tools of a profession whose coding will become obsolete before long. I think it more appropriate to aim at creating a package of solid technical skills that prepare the student to move in the ever changing workshop of calculators. Less desktop publishing software and more graphics-oriented programming.

What united me and my new colleagues was a profound sense of frustration. Our professionalizing studies were based on a model that was already crumbling in the nineties, and that in the 2000s was just a faded multiple of the original matrix. We were ready to offer services that our ideal interlocutors did not need and we had none of the tools required to fill the void. The school we had laid our trust in had not kept its promise. We had just set out and we already felt useless. We were too many scribes of a language that had become less and less complex to write.

Left High and Dry

What usually escapes the popular narrative about programming is its linguistic side. Programming is first of all writing a machine’s performance. Using monospaced characters, composition generally works on two active spatial axes. It is not difficult to find echoes in the concrete poetry or internal vertical justification of Stefan Themerson.
Programming languages belong within the wide group of formal languages, that is those forms of notation and expression designed at a given moment (updated there and then if necessary) to fulfill a specific purpose. While a natural language evolves naturally through cycles of contraction and expansion along a time span that exceeds the life of the individual, a formal language comes to life through the work of a small group of human beings. Formal languages include scientific notations of various kinds, in areas such as chemistry, physics and mathematics. Or in the arts, the music notation and the Laban notation used in choreography. It is no coincidence that Progetto Grafico has dedicated a great deal of space to it over the years.
Being a writing activity, one of the purposes of programming is to create a system of organized knowledge. One of the most often repeated principles in managing all these data and behavioral segments is DRY (do not repeat yourself), coined by Andy Hunt and Dave Thomas in the late 1990s. Each segment of knowledge organized within a system should be devoid of ambiguity. If this is not so, sooner or later the different representations will inevitably fall out of step with each other. Taking into account that systems are subject to updates, multiple representations also have to be kept aligned.

Cartography is perhaps the field in which it is easiest to find a connection with this principle: when the elements of a map are associated with a group of visual variables it is essential that the attributions do not conflict so as not to generate confusion. If you decide to use the double red dashed line to signal highways, the same group of visual variables cannot be used for any of the other elements.
Building grammatically solid images involves building a system of equally solid syntactic rules. When you arrange a system of images, write a typographical regulation or take a series of photos you perform a more or less informal type of programming. Is programming then perhaps not so different from writing images?

Towards a new workshop?

An increase in complexity corresponds proportionally to an increase
in the number of devices that separate us from an understanding of the
underlying processes. For every interface accepted uncritically, a degree of understanding and the ability to manipulate the image material is forfeited.
Fitted tightly into the monopoly of tools that impose a highly standardized workflow, image designing is thus forced to be part of an assembly line of creativity where the designer will sooner or later become obsolete.
Digital graphics workshops need to be brought back through the world of teaching. Hopefully, there will be a reaction to the marginalization of the job of the graphic designer, who will be given skills that restore their independence in this technological model.
Let’s make one thing clear – computers themselves are not the cause of this impoverishment, but the surrender to the changes they have imposed. The potential is enormous, the problem is that the language skills are lacking to harness it. It wouldn’t take much to understand each other better; to peel a few layers off the computer and take a look inside.

Highlights

The article was originally conceived with a few extra independent highlights. They are part of a broader collection of facts and tools I encountered while writing this article. Somehow I thought they could add something to the rest even without a complete integration in the main topic.

Recurring motifs in the strings

Programming languages exist to suit all tastes, and it is worth spending a little time to understand what might come in really useful without requiring years of study. For example, there is a popular programming language that allows you to code a pattern of text characters. These patterns are called regular expressions. It is a notation that allows you to make statements like: “A sequence of characters that begins with uppercase letters, contains at least one digit, does not end in a T and is set between spaces or punctuation marks.” This notation is so powerful as to be everywhere. Every selfrespecting text editor supports regular expressions for its search capabilities, Adobe Indesign is no exception.
When I made the rough draft of this article I overused adverbs that end in –ly. This often happens when you are just jotting down. They make for heavy reading and can in some cases be distracting. So I decided to use the regular expression \b[AZa- z] + ly\b to select all the adverbs from the article and delete them. Then when re-reading, I put them back only where I felt the meaning had been lost. Here is the list of those I couldn’t do without (in order of appearance): especially, progressively, usually, specifically, decidedly, especially, unlikely, patiently, drastically, seemingly, autonomously, usually, generally, naturally, grammatically, proportionally, acritically, highly.

The craftsman and his workshop

There is an interesting tradition of craftspeople/designers who describe ways in which they have shaped their work environment. Norman Potter devotes an entire section of his monograph published by Hyphen Press to explaining in detail the spatial organization of his work tools. Writing Illuminating and Lettering by Edward Johnston contains considerations gathered from years of practice and tool creation. Fred Smeijers’ Counterpunch is a historical retro-engineering investigation into the work flow of Renaissance punchcutters. When I discovered the fervor with which developers – of all sorts and levels – bicker over the settings of their code editors or the style guides for writing them, it seems to me they are unwittingly feeding a long-standing literary tradition.

Unwitting Rule

At the dawn of digital graphics, champions of American graphic modernism such as Paul Rand and Massimo Vignelli showed an illconcealed contempt for what the new generation of designers was producing. The computer was, after all, causing their hierarchy to crumble, making it harder for them to criticize the world of the image.
In the preface to Design by Numbers by John Maeda, Paola Antonelli recounts how Maeda went on a pilgrimage to the bad-tempered Paul Rand. The purpose of the mission was to try to convince the maestro that a computer could also be used to make good modernist design, and not only the crazy graphics of Carson, Brody and Emigre. The episode speaks volumes about the awareness the rule writers had of the tools of their trade, whether these were typefaces or design tools.

The rich portfolio of the tool monopolist

During the 2017 edition of TypoLabs in Berlin, the director of Adobe’s type department, Matthew Rechs, was called into question over the high cost of Creative Cloud. “Why should I have to spend €70 a month to test the typefaces I’m working on?”, a designer asked from the crowd. A little embarrassed, Mr. Rechs claimed to take his point but replied that since Adobe introduced the monthly subscription it had never been so successful. In fact, the increase in value on the NASDAQ stock market speaks for itself: previously Adobe was trading at $25 per share, today it is around $200. The advantage of having a monopoly.