Python for Designers

by Roberto Arista

Fork me on GitHub

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!

Prog­etto Grafico asked me for a con­tri­bu­tion on the value of pro­gram­ming in teach­ing graphic de­sign. On var­i­ous oc­ca­sions mem­ber of the ed­i­to­r­ial board Sil­vio Lorusso and I have dis­cussed the mer­its and lim­its of pro­gram­ming and the close re­la­tion­ship with the tools that en­sues. Two years ago I was ap­pointed teacher of the ba­sic IT course at ISIA in Urbino and at the re­quest of the then di­rec­tor Lu­ciano Per­ondi I moved the syl­labus from the usual desk­top pub­lish­ing soft­ware to pro­gram­ming. I also em­barked a few months ago on the task of writ­ing a pro­gram­ming man­ual in Python lan­guage for my stu­dents. “I’ll have no trou­ble writ­ing this ar­ti­cle,” I told my­self. In­stead, it has proven tricky. Fi­nally, I re­al­ized why it was caus­ing so much dif­fi­culty – it was not the tech­ni­cal­i­ties or the ab­stract na­ture of some of the con­cepts, but the fact that learn­ing to pro­gram for me turned out to be an eman­ci­pa­tion process. And the process of eman­ci­pa­tion is by na­ture per­sonal.

The de­sign­er’s work is based largely on a di­a­logue with mono­liths of metal, glass and ce­ramic that we un­der­stand less every day and del­e­gate more and more sub­stan­tial slices of our work to. They have al­ready taken over the places where im­ages were pro­duced – places once pop­u­lated by print­ing ma­chines and photo en­larg­ers. The price we are pay­ing to lighten the weight of our la­bor is a loss of con­tact with the ma­te­ri­als that char­ac­ter­ize it. The re­la­tion­ship be­tween de­signer and the ex­e­cu­tion of his or her ideas is me­di­ated by that of­ten im­pen­e­tra­ble panel now a part of every­day speech: in­ter­face. We ab­di­cate a de­gree of con­trol to this smooth sur­face in ex­change for com­fort­ing sim­pli­fi­ca­tion. The aura of com­pe­tence af­forded by the man­ual and tech­ni­cal skills of pro­fes­sion­als has van­ished, and with it the col­lec­tive per­cep­tion of a trade: “It’ll only take you five min­utes, right?”.

An Impenetrable Desk

The eco­nomic model on which pro­duc­tion of dig­i­tal work tools is based is a devo­tee of the scal­a­bil­ity mantra. Since dis­tri­b­u­tion of the soft­ware takes place in the liq­uid realm of the Web, the lat­ter is not forced into the lo­gis­tic con­fines that char­ac­ter­ize any other ma­te­r­ial goods. The re­sult is a rapid con­trac­tion and ex­pan­sion of ex­changes. The pro­duc­tion costs of mul­ti­ples are al­most non-ex­is­tent, as is the dif­fi­culty to du­pli­cate fraud­u­lently. The aim of de­vel­op­ers is to sell enough li­censes to cover pro­mo­tion and de­vel­op­ment costs, while all the rest is profit. From the de­sign point of view this en­cour­ages tool de­sign­ers to aim to sat­isfy the needs of a very large num­ber of cus­tomers, while seek­ing the com­plex bal­ance be­tween user­friend­li­ness and spe­cial­ism. In the po­lit­i­cal jar­gon of a few decades ago, this ap­proach would have been de­fined as a de­sire for an ab­solute ma­jor­ity. Its max­i­mum as­pi­ra­tion is, af­ter burn­ing piles and piles of ban­knotes, to dom­i­nate a sec­tor through mo­nop­oly. And be­hind every de­sire for an ab­solute ma­jor­ity there is a de­sire for a plebiscite. In the com­pro­mise be­tween large num­bers and com­plex­ity of ac­cess, not all pos­si­ble sce­nar­ios will be taken into ac­count dur­ing the tool’s de­vel­op­ment. Some prob­lems will re­quire a se­quence of very in­con­ve­nient op­er­a­tions in or­der to be linked, es­pe­cially re­peat­edly, re­sult­ing in that strange feel­ing where you find your­self click­ing for hours yet pro­duc­ing very lit­tle. In com­puter jar­gon these set­tings are coded in user sto­ries, in­for­mal de­scrip­tions of typ­i­cal sce­nar­ios. Let’s imag­ine the user story of In­de­sign’s “print book­let” func­tion: “As a graphic de­signer for a small agency, I want to de­velop a 16-page book­let in or­der to print a pro­to­type to dis­cuss with my art di­rec­tor.” Most of our daily dig­i­tal ac­tiv­i­ties have found space on some IT de­vel­op­ment com­pa­ny’s post-its. This is one of the var­i­ous meth­ods by which prod­uct de­sign­ers keep track of soft­ware de­vel­op­ment. It is log­i­cal at this point to ask whether the user sto­ries are made to fit our pro­fes­sion or do we pro­gres­sively adapt our work to what the avail­able tools are ca­pa­ble of do­ing? By de­f­i­n­i­tion de­sign­ing means pro­duc­ing so­lu­tions that do not ex­ist yet. If a so­lu­tion we think up has never been pro­duced be­fore, it is rea­son­able to as­sume that it might never have been cod­i­fied within a user story. There­fore, the most suit­able dig­i­tal tool to im­ple­ment this so­lu­tion might be miss­ing. The ques­tion that arises at this point is: if the tool is miss­ing, do we change the so­lu­tion or cre­ate the tool? The bud­get and skills avail­able for the pro­ject usu­ally pro­vide the an­swer to this. The most com­mon tools will not serve rad­i­cal de­sign­ers. Those with their own opin­ion about work­ing meth­ods feel the need to be able to sharpen their tools in­de­pen­dently.

The shape of the tools

Every tool is the out­come of a vi­sion that aims to de­fine the range of ac­tion. The width of this range is in­scribed in its form. Let us con­sider the han­dle of tools we use every day – it says a lot about the way the tool is in­tended to be used. The less spe­cific a tool, the more shape­less it is. I do not think it ab­surd to be­lieve that the rea­son why User In­ter­face (UI) and User Ex­pe­ri­ence (UX) de­sign dis­ci­plines have flour­ished is di­rectly due to the need to get us com­mu­ni­cat­ing sat­is­fac­to­rily with mono­liths that say very lit­tle about the way they would like to be used. Let’s com­pare a pasta cut­ter and an or­di­nary table knife: the cut­ter is specif­i­cally de­signed to cut some­thing thin and soft - like ed­i­ble pasta - while a knife has a much wider range of op­tions. The dif­fer­ent shape of the two in­stru­ments shows this clearly.

No me­chanic would dis­as­sem­ble a com­po­nent from a car us­ing a Swiss army knife, un­less it was the only tool at his dis­posal. The lack of speci­ficity of a tool makes any task per­formed with it more com­pli­cated, es­pe­cially if re­peated. In an emer­gency you make do, but you don’t base your work on ex­cep­tions. How is it that im­age de­sign­ers do not feel the need to use more spe­cific tools? Has dig­i­tal razed their work­shops to the ground? Desk­top pub­lish­ing soft­ware - like per­sonal com­put­ers in gen­eral - have con­densed a myr­iad of fea­tures within a sin­gle large con­fined space, dis­cour­ag­ing re­search and de­vel­op­ment of al­ter­na­tives. Let’s not for­get that for com­mer­cial rea­sons they are de­signed to com­mu­ni­cate lit­tle with the out­side. Un­less two dig­i­tal tools are de­vel­oped by the same com­pany, it is un­likely that they will be able to ex­change data and func­tion­al­ity prof­itably. Cases where a file’s work­ing for­mat is shared by ap­pli­ca­tions de­vel­oped by mul­ti­ple en­ti­ties are very rare. More of­ten than not an ex­port for­mat - like PDF - be­comes a de facto stan­dard.

Pro­gram­ming then can be­come a way to es­cape this con­fine­ment, con­nect­ing dif­fer­ent re­gions and pa­tiently re­build­ing the work­shop within the tools that ef­fec­tively de­stroyed these re­gions. It is a way of start­ing to pro­duce rad­i­cal tools again, use­ful for do­ing one thing per­fectly rather gen­eral pur­pose: ex­actly what de­sign and the de­signer need.

How the education system betrays us

Sim­pli­fy­ing dras­ti­cally, we could put an ex­piry date on skills. For ex­am­ple, the the­o­ret­i­cal prin­ci­ples that un­der­lie the com­po­si­tion of mov­able type are crys­tal­lized in the his­tory of the method (so there is no ex­piry date), but com­pos­ing lead type by hand will not prove very use­ful in daily life. How­ever, it will be use­ful to re­mem­ber that know­ing how to com­pose type man­u­ally will help to im­press on the mind sim­i­lar­i­ties and dif­fer­ences be­tween com­pos­ing lead and sil­i­con. There are many seem­ingly use­less skills that re­gain enor­mous value if trans­lated into con­tem­po­rary prac­tice. Teach­ing is there­fore based on a del­i­cate bal­ance be­tween skills with ex­piry dates and those with dif­fer­ent types of use. One of the great­est dif­fi­cul­ties of­ten lies in demon­strat­ing the value that teach­ing some skills not cur­rently of use can have dur­ing the course of con­tin­u­ous train­ing. The pace at which ed­u­ca­tional courses are up­dated and or­ga­nized are not (and should not try to be) the same as in the pro­fes­sional world. The rate of change in in­for­mat­ics and tech­nol­ogy is op­pres­sive. By their very na­ture schools and uni­ver­si­ties should not pur­sue un­sus­tain­able rhythms, but rather con­cen­trate on medium-term skills that al­low the stu­dent to make their own way once train­ing is com­pleted. No one can state with cer­tainty how the work of the graphic de­signer will change over the next few years and the least an ed­u­ca­tional es­tab­lish­ment can do is to try is to equip its stu­dents to man­age their skills au­tonomously. On a tech­no­log­i­cal level, I con­sider it wrong to teach the use of tools of a pro­fes­sion whose cod­ing will be­come ob­so­lete be­fore long. I think it more ap­pro­pri­ate to aim at cre­at­ing a pack­age of solid tech­ni­cal skills that pre­pare the stu­dent to move in the ever chang­ing work­shop of cal­cu­la­tors. Less desk­top pub­lish­ing soft­ware and more graph­ics-ori­ented pro­gram­ming.

What united me and my new col­leagues was a pro­found sense of frus­tra­tion. Our pro­fes­sion­al­iz­ing stud­ies were based on a model that was al­ready crum­bling in the nineties, and that in the 2000s was just a faded mul­ti­ple of the orig­i­nal ma­trix. We were ready to of­fer ser­vices that our ideal in­ter­locu­tors did not need and we had none of the tools re­quired to fill the void. The school we had laid our trust in had not kept its promise. We had just set out and we al­ready felt use­less. We were too many scribes of a lan­guage that had be­come less and less com­plex to write.

Left High and Dry

What usu­ally es­capes the pop­u­lar nar­ra­tive about pro­gram­ming is its lin­guis­tic side. Pro­gram­ming is first of all writ­ing a ma­chine’s per­for­mance. Us­ing mono­spaced char­ac­ters, com­po­si­tion gen­er­ally works on two ac­tive spa­tial axes. It is not dif­fi­cult to find echoes in the con­crete po­etry or in­ter­nal ver­ti­cal jus­ti­fi­ca­tion of Ste­fan The­mer­son. Pro­gram­ming lan­guages be­long within the wide group of for­mal lan­guages, that is those forms of no­ta­tion and ex­pres­sion de­signed at a given mo­ment (up­dated there and then if nec­es­sary) to ful­fill a spe­cific pur­pose. While a nat­ural lan­guage evolves nat­u­rally through cy­cles of con­trac­tion and ex­pan­sion along a time span that ex­ceeds the life of the in­di­vid­ual, a for­mal lan­guage comes to life through the work of a small group of hu­man be­ings. For­mal lan­guages in­clude sci­en­tific no­ta­tions of var­i­ous kinds, in ar­eas such as chem­istry, physics and math­e­mat­ics. Or in the arts, the mu­sic no­ta­tion and the La­ban no­ta­tion used in chore­og­ra­phy. It is no co­in­ci­dence that Prog­etto Grafico has ded­i­cated a great deal of space to it over the years. Be­ing a writ­ing ac­tiv­ity, one of the pur­poses of pro­gram­ming is to cre­ate a sys­tem of or­ga­nized knowl­edge. One of the most of­ten re­peated prin­ci­ples in man­ag­ing all these data and be­hav­ioral seg­ments is DRY (do not re­peat your­self), coined by Andy Hunt and Dave Thomas in the late 1990s. Each seg­ment of knowl­edge or­ga­nized within a sys­tem should be de­void of am­bi­gu­ity. If this is not so, sooner or later the dif­fer­ent rep­re­sen­ta­tions will in­evitably fall out of step with each other. Tak­ing into ac­count that sys­tems are sub­ject to up­dates, mul­ti­ple rep­re­sen­ta­tions also have to be kept aligned.

Car­tog­ra­phy is per­haps the field in which it is eas­i­est to find a con­nec­tion with this prin­ci­ple: when the el­e­ments of a map are as­so­ci­ated with a group of vi­sual vari­ables it is es­sen­tial that the at­tri­bu­tions do not con­flict so as not to gen­er­ate con­fu­sion. If you de­cide to use the dou­ble red dashed line to sig­nal high­ways, the same group of vi­sual vari­ables can­not be used for any of the other el­e­ments. Build­ing gram­mat­i­cally solid im­ages in­volves build­ing a sys­tem of equally solid syn­tac­tic rules. When you arrange a sys­tem of im­ages, write a ty­po­graph­i­cal reg­u­la­tion or take a se­ries of pho­tos you per­form a more or less in­for­mal type of pro­gram­ming. Is pro­gram­ming then per­haps not so dif­fer­ent from writ­ing im­ages?

Towards a new workshop?

An in­crease in com­plex­ity cor­re­sponds pro­por­tion­ally to an in­crease in the num­ber of de­vices that sep­a­rate us from an un­der­stand­ing of the un­der­ly­ing processes. For every in­ter­face ac­cepted un­crit­i­cally, a de­gree of un­der­stand­ing and the abil­ity to ma­nip­u­late the im­age ma­te­r­ial is for­feited. Fit­ted tightly into the mo­nop­oly of tools that im­pose a highly stan­dard­ized work­flow, im­age de­sign­ing is thus forced to be part of an as­sem­bly line of cre­ativ­ity where the de­signer will sooner or later be­come ob­so­lete. Dig­i­tal graph­ics work­shops need to be brought back through the world of teach­ing. Hope­fully, there will be a re­ac­tion to the mar­gin­al­iza­tion of the job of the graphic de­signer, who will be given skills that re­store their in­de­pen­dence in this tech­no­log­i­cal model. Let’s make one thing clear – com­put­ers them­selves are not the cause of this im­pov­er­ish­ment, but the sur­ren­der to the changes they have im­posed. The po­ten­tial is enor­mous, the prob­lem is that the lan­guage skills are lack­ing to har­ness it. It would­n’t take much to un­der­stand each other bet­ter; to peel a few lay­ers off the com­puter and take a look in­side.

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

Pro­gram­ming lan­guages ex­ist to suit all tastes, and it is worth spend­ing a lit­tle time to un­der­stand what might come in re­ally use­ful with­out re­quir­ing years of study. For ex­am­ple, there is a pop­u­lar pro­gram­ming lan­guage that al­lows you to code a pat­tern of text char­ac­ters. These pat­terns are called reg­u­lar ex­pres­sions. It is a no­ta­tion that al­lows you to make state­ments like: “A se­quence of char­ac­ters that be­gins with up­per­case let­ters, con­tains at least one digit, does not end in a T and is set be­tween spaces or punc­tu­a­tion marks.” This no­ta­tion is so pow­er­ful as to be every­where. Every sel­f­re­spect­ing text ed­i­tor sup­ports reg­u­lar ex­pres­sions for its search ca­pa­bil­i­ties, Adobe In­de­sign is no ex­cep­tion. When I made the rough draft of this ar­ti­cle I overused ad­verbs that end in –ly. This of­ten hap­pens when you are just jot­ting down. They make for heavy read­ing and can in some cases be dis­tract­ing. So I de­cided to use the reg­u­lar ex­pres­sion \b[AZa- z] + ly\b to se­lect all the ad­verbs from the ar­ti­cle and delete them. Then when re-read­ing, I put them back only where I felt the mean­ing had been lost. Here is the list of those I could­n’t do with­out (in or­der of ap­pear­ance): es­pe­cially, pro­gres­sively, usu­ally, specif­i­cally, de­cid­edly, es­pe­cially, un­likely, pa­tiently, dras­ti­cally, seem­ingly, au­tonomously, usu­ally, gen­er­ally, nat­u­rally, gram­mat­i­cally, pro­por­tion­ally, acrit­i­cally, highly.

The craftsman and his workshop

There is an in­ter­est­ing tra­di­tion of crafts­peo­ple/​de­sign­ers who de­scribe ways in which they have shaped their work en­vi­ron­ment. Nor­man Pot­ter de­votes an en­tire sec­tion of his mono­graph pub­lished by Hy­phen Press to ex­plain­ing in de­tail the spa­tial or­ga­ni­za­tion of his work tools. Writ­ing Il­lu­mi­nat­ing and Let­ter­ing by Ed­ward John­ston con­tains con­sid­er­a­tions gath­ered from years of prac­tice and tool cre­ation. Fred Smei­jers’ Coun­ter­punch is a his­tor­i­cal retro-en­gi­neer­ing in­ves­ti­ga­tion into the work flow of Re­nais­sance punch­cut­ters. When I dis­cov­ered the fer­vor with which de­vel­op­ers – of all sorts and lev­els – bicker over the set­tings of their code ed­i­tors or the style guides for writ­ing them, it seems to me they are un­wit­tingly feed­ing a long-stand­ing lit­er­ary tra­di­tion.

Unwitting Rule

At the dawn of dig­i­tal graph­ics, cham­pi­ons of Amer­i­can graphic mod­ernism such as Paul Rand and Mas­simo Vi­gnelli showed an ill­con­cealed con­tempt for what the new gen­er­a­tion of de­sign­ers was pro­duc­ing. The com­puter was, af­ter all, caus­ing their hi­er­ar­chy to crum­ble, mak­ing it harder for them to crit­i­cize the world of the im­age. In the pref­ace to De­sign by Num­bers by John Maeda, Paola An­tonelli re­counts how Maeda went on a pil­grim­age to the bad-tem­pered Paul Rand. The pur­pose of the mis­sion was to try to con­vince the mae­stro that a com­puter could also be used to make good mod­ernist de­sign, and not only the crazy graph­ics of Car­son, Brody and Emi­gre. The episode speaks vol­umes about the aware­ness the rule writ­ers had of the tools of their trade, whether these were type­faces or de­sign tools.

The rich portfolio of the tool monopolist

Dur­ing the 2017 edi­tion of Ty­po­Labs in Berlin, the di­rec­tor of Adobe’s type de­part­ment, Matthew Rechs, was called into ques­tion over the high cost of Cre­ative Cloud. “Why should I have to spend €70 a month to test the type­faces I’m work­ing on?”, a de­signer asked from the crowd. A lit­tle em­bar­rassed, Mr. Rechs claimed to take his point but replied that since Adobe in­tro­duced the monthly sub­scrip­tion it had never been so suc­cess­ful. In fact, the in­crease in value on the NAS­DAQ stock mar­ket speaks for it­self: pre­vi­ously Adobe was trad­ing at $25 per share, to­day it is around $200. The ad­van­tage of hav­ing a mo­nop­oly.