Type Network



TYPETR / News /

ATypI 2013 keynote: what we need…

Welcome in Amsterdam, welcome to ATypI 2013. I’d like to invite you on a small virtual journey in the world of type and typography. We’ll explore areas that are common to you all. And we also will visit some places that are less familiar. Not so much in a geographical or historical context, but based on the relations between the various locations in the world of type and typography.

It is tempting to look at the past, because that is what we can remember. We can see the documentation. But it’s only the future that we can change. Interesting as it is to know how crafts were applied a couple of centuries years ago, this knowledge is purely academic, if there isn’t a way to match that knowledge with future events. It’s an old saying that the future is no longer what it used to be. And unfortunately that’s increasingly true.
What are the new professional challenges in a world that never before changed that fast in so many aspects? How should we educate young designers? How should we educate ourselves, to keep up with new technologies and the transforming expectations of readers? How should engineers be directed to what we really need in this landscape?

This lecture is a brief overview of the things that need to be done. What really would be useful regarding type and typography, in the near and distant future. The list is not complete. Far from it. And the list is biased. ATypI conferences-by definition-cannot address the real world problems such as global warming, financial crisis, hunger, refugees or child labor. To name a few.
It’s not very realistic to think that the world becomes a better place, by making pretty typefaces and readable typography. However, every small detail may help, even when it is 10 pt.

In the past, the world was pretty simple. There was a number of manufactures that produced typesetting machines. Hot metal first and phototypesetting later. As long as the manufactures owned the physical storage of type, it was easy to maintain their library, exclusively available on their machines.
But when the digital revolution started in the eighties, these old manufactures gradually ceased to exist. The knowledge of how to create type and typography spread over the world, allowing the cottage industry to grow and flourish. Every design studio could afford its own type designer. Especially from The Hague (to paraphrase Erik Spiekermann’s classic remark). No longer it was necessary to maintain expensive machine factories. Type could be made by anyone, scattering the knowledge and skills how to do that.
Meanwhile new large corporations grew-and still do-from the ashes of the old ones, induced by the volume of glyph sets and required budgets to market the right choice from the 100.000+ typefaces available.

Looking at the world map of knowledge on type and typography, the distribution of details is a matter of perspective. We are very much aware of what is nearby. Close to heart. Loving your own children is a lot easier than appreciating the brats, that live across the street. You may recognize resemblance with the famous illustration that Saul Steinberg made in 1975 for the cover of the New Yorker.

What does the world need? There are many things desperately needed. We need parents who teach their children, that acquiring knowledge is better than owning stuff. That training skills is more valuable than earning respect. We also need managers who recognize, that uncertainty and doubt are the most valuable ingredients for new developments in their companies. That, in fact, they are the crown jewels of innovation.
But that’s all very general. What does our world need?

Let’s get a bit more specific.

Whatever change we are seeking for, the future is in education. No matter what fashion, or technology, user preferences or corporate behavior will become in the future, it’s for sure that everything depends on the education of people who know how to create and solve the problems that we are facing. At any level of details or relevance. Independent from their complexity.

What do we then educate?
What to teach a student about design that is still relevant 40 years from now? Or even 10?
What do future designers need now?
Which skills should they have? What experience is essential?
What do design students need in order to educate themselves during their professional life?

We need design schools that understand the skills of doing research.
We need students that appreciate the knowledge of making, by asking “Can you tell us more about it?” Instead of “Do you really need to know all this?”
We need students who get lost in the landscape of type and typography, because they went too far out. We need them to scream for help, after which their teachers can bring them back to safe grounds. We need explorers, much more, than design students who stay on the party beach because the drinks are free and Facebook can show them an image of the world.

We need educators to understand that scripting and programming is by definition part of each design process. That it is the formal way to describe design decisions, even if the syntax is not exactly understood. Better to write the conditional behavior of a design in a pseudo language, than trying to solve the puzzle in your head with a single Photoshop image as final output. Since all design activity rapidly transforms into templates (half products that are used as starting point by others), thinking in conditions and algorithms is the only way designers will be allowed to survive.

Is that limiting their creative minds? Yes, of course. Just in the same way as grids do. Or spacing units. Or lego. Or Pantone colors. Or typefaces. Reducing the infinite amount of choices to a manageable range. That is a key task for every designer. Always.

Often the development of skills and the doing of research is seen as the opposite sides of a linear scale.

But in fact the model can be more refined. Skills and research in this slide are the two axes that span the space of available freedom for designing the process.

Making can be done by a novice and also by someone with a lot of skills. And someone can be very skilled in doing research. Or it can be a student, just starting to find out that reading actually can be a lot of fun. There are people who already wrote something about this topic. Can you imagine?

These graphs are models. Simplifications of thoughts that are too complex to understand otherwise. We remove details to understand the unthinkable.

The name of a font family is a model, a symbol that represents the entire set of design decision inside.

A glyph outline is model-a template in this case-that is used to create sets of anti-aliased pixels when rendered on a particular size.

The program of this conference is a model, a prediction of the time to come, carefully designed so it contains just enough information. And it worked, because you all are here.

And so does the map of Amsterdam, because you all returned safely home after visiting the Red Light District somewhere in the past few days.

In all these models the crucial factor is the amount of relevant details.

Relevance implies understanding the task at hand. What is the sketch supposed to do. A 10 minute sketch for a website can be a valuable tool to discuss directions in an early stage of the process. Even by showing to the client of the site.

But a sketch must contain more detail, if used later in the design process. Wether or not a visualization is a “sketch”, says something about the stage of usage, not about the technique being applied.
Text is an example of the usage of commonly understood symbols reducing the amount of details in the actual story. With the text of this lecture I assume that I am referring to objects and situations that you recognize.

Design is the management of details. It’s a useful definition, talking about the subject with students or clients. Just keeping the level of details-that is relevant for a certain task-simplifies the communication. 

So we need designers that can design these models. There are just too many directions to choose from. As literally as the model of the type world-the one used in this presentation–, models also can be very abstract.

Models can be based on intuition “I have the feeling that this is the right approach”, or by taste or gut feeling. Some designers like to approach a design problem with cultivated opportunism. “We pretend that we can do this in the given amount of time, although we know that it is not true”.

And there are many more models to create models with.

Tools use models to operate. They understand what the task is that needs to be done.

What we need is design tools and design languages. Not production tools, shaped up like it. Where is the Python Powered InDesign? Why hasn’t that been made before? I know it’s possible with JavaScript, but is any designer using that? Why were designers unable to convince Adobe that this dramatically would improve their production of designs? Why was is possible too boost all type design application by adding a powerful and complete object oriented programming language, while none of the layout programs have made that move so far?

Applications for designers need to be scriptable by Python.

Therefor InDesign, Illustrator, Photoshop, Sketchup and many other tools are not design applications. Drawing a fast conclusion here?

Watch Robothon! If the total amount of 150 tickets for Robothon-the triennial conference in The Hague about the scripting of type-are sold out within one hour-think about the world were every Adobe app would be scriptable by Python objects.
The explanation is that designers don’t really ask. Or care. They prefer to think that doing repeating labor work is the ultimate design accomplishment. They mistakenly think that programming is not design.

We need programming languages for designers.

We need web tools that go beyond the level of assembler and Postscript. We need designers that understand why the line at the bottom is not part of the list above.

If you want to know more, and you should, watch The Future of Programming on Vimeo by Bret Victor “The nature of adopting ideas. Parallel processing should have been there by now.”

We need designers that know the difference between Idea Space and Tool Space. You most likely saw this illustration by Erik van Blokland before. Most designers live on the yellow island of existing tool spaces. It’s a very crowded beach there, where everyone tries to earn a living by doing the same as all neighbors.
But the designers that know how to escape, and build their own islands, are by definition unique. Not limited to the ideaspace of the application builders, they can explore anything they want.

We need tools that understand the principle of “single source”.
And we need designers who grasp what that means.

Replace files by databases. Working in the cloud is a good start, but far from adequate. Who didn’t see archived Dropbox files disappear, because someone else dragged them on his own desktop? Instead of making a copy.

We need applications that solve the versioning of design work. As easy as the undo button is, why can I not look back into the state my work was last week? If it is possible to fill up half of the web volume with porn, there must be some space left to save the previous versions of any project that we do.
Where is the type design version of Git? Programmers solved it for themselves, keeping track of the versions of their program code. Even when multiple programmers work on the same source. Even when they work on the same source file. We need programmers that can solve the problem for the rest of the world.

Designers seem to be satisfied with the fact that they need to work on files that are sitting on their local machines.

Their private gated community. Their well secured office. But reality is that we need environments where multiple designers (and testers and hinters and programmers and typographers and marketeers) use the same source at the same time, to create the versions of type that they need. In TypeNetwork terms this is the “landing pattern” of a type face.

First establish the requirements for the specific task of a set of font files. Then automate the transformation to generate all fonts from a central set of sources. Not necessary to mention that all this information lives in an online database, not on someones desktop computer.

We need designers that understand the difference between “kinds of” and “a single one”. Not thinking literal, like the creation of a unique piece of art. But thinking instead in categories, types, parse pro totos and algorithms.

We need algorithms that are able to take design decision. There is simply not enough design capacity in the world available to allow human designers to do all the work. But how do you design programs that can design? There are very few designers that know that. Where have they been educated? And what tools are available for them to do their work? Prolog, Processing or Python would be good candidates for a start, but it needs more than just an empty programming environment to write programs with artificial intelligence.

Hard as it may seem, the solution is in studying multiple areas at the same time. Combine the science of Artificial Intelligence, Typography and the creation of applications, and an extremely interesting field of design research pops up. By the way, this is true for any combination of areas, no matter if they appear to be too remote at first glance.
Matthew Butterick is a type designers that knows all about copyrights. Or is he a lawyer with extreme detailed knowledge about typography? Check out his new online book about the topic: Practical Typography (http://practicaltypography.com) and pay by one of suggested methods if you appreciate.

Is a designer who makes his own tools a programming designer or a designing programmer? There is no need to answer this question: it’s both, of course. Any combination makes designers unique in the world, just by picking two remote specialisms.

Borrowing from the models in Artificial Intelligence, we can create some very useful tools to evaluate the complexity of a design job.
Take these 6 extremes. Although originally made for the development of intelligent programs, the rules apply perfectly to design processes. That is best illustrated by relating them to some example tasks such as playing a game of chess.

Values in the left column are easy to solve. The values in the right column are complex. A game of chess scores like this. It is fully observable, meaning that the players can see all pieces on the board. Nothing is hidden from their view. The game is deterministic, as there is no dice in the game. It is a sequential game, because it is not allowed to undo a move, once it proves to be a bad choice. The game is static: the rules don’t change during the game. It is discreet, as the edge position between a black and white square doesn’t have a meaning. And there is more than one player involved in the game.

If we compare these values with the design task to design a page without using a grid, then this is the score. The page is still fully observable (there is not a stack of hidden cards) and it is also deterministic, there is no dice. But different from a game of chess, the task typically is a design process. The designer can go back to one of the previous versions any time, and continue from there. The process is episodic, not sequential. One could call the task dynamic, as the client may call anytime during the process to change the rules (“we need less text and more photo’s”). There is no grid, so the positioning of the elements is continuous. And despite the involvement of the client, the design process itself is – in most cases – an individual task.

Designing the page with a grid, will-of course-change the parameter from continuous to discreet. Simplifying the problem.

Making a car drive through traffic, all by itself, requires of course an extremely difficult program, as all parameters on the right side apply. Science fiction 20 years ago, it became reality.

We need clever device manufacturers, that don’t make stupid mistakes due to ignorance, lack of development time or the urge to keep legacy compatibility alive.

We need devices that are made with the quality of type and typography in mind. We need browsers that understand at least the basic typographic rules.

We need page a page description languages that are made for designers. CSS is not a design language, because I cannot tell it more or less what I want. I only can tell it exactly what I want, and I have to remember the specifics for every browser and every project again, from scratch. Getting CSS and HTML to work properly in every browser for every screen size, is an art form that is close to magic. We need a page description languages that at least will hide the crappy legacy from view.

We need to think the unthinkable. Watch this other great lecture by Bret Victor.

Instead of making applications to generate pages, we also can make pages really interactive, when they respond to actions. Info-graphics that understand what the user wants to know.

We need people like Just van Rossum and Erik van Blokland and Tal Leming and Frederik Berlaen and many others, who have built a library of tools, that a whole generation of type design students is using to their advantage. The possibility to script repeating production tasks, during the process of design, by the designer herself, not by a programmer, is entirely based on the existence of Python, the Open Source project of Guido van Rossum.

There is TTX, which Just donated to the world of type, a relatively small and simple program, that is used by everyone, the cottage industry and the corporations alike. What would the world have been without this tool, that decompiles binary fonts into readable XML documents, and compiles them back into binary fonts just as easy.

There is Vanilla and Defcon
There is UFO
There is Woff
There is Gerrit Noordzij’s contrast cube
There is RoboFont
There is Glyphs
There is Superpolator

We need more programs like Erik’s Superpolator3 – check him out – where infinite new glyphs are created on-the-fly from only a limited amount of masters. Interpolation is one of the few fully-automated manipulation of glyphs, where the result does not require heavy manual editing. It’s an old method, but this one solves real design problems. The results are pretty exciting.

And we need more people who, on their turn, are not satisfied with just these tools. Who think it can be done better, now knowing what can be done. They need to dive into it, and inherit, adjust, improve, scale up, generalize the existing code. And educate others to do it even better.

There are many important areas that we did not talk about. The web, writing, identities and branding. And we forgot about print. It still is in the top left corner, close to the horizon. We didn’t talk about design theory. Oh well, maybe we did. We didn’t talk about hinting, setting up your own company, the history of curves, styles, classes, classification, music, architecture or art.
I give up, you have to do the exploration by yourself.

We need ATypI, as a place where this all happens. Not only in the lectures-It is good to see the vast amount of submitted papers, from which this packed program of lectures could be selected-but especially the gutters between the lectures are valuable resources, when there is room for people to meet.

Let’s try to look outside the box, not just focus on our own local cottage. What are the big issues that need to be solved? And what part of that can be solved by designing type or paging a layout. I wish you an interesting time in the remaining days of this ATypI Amsterdam 2013-and after-acquiring everything that you need.

Thank you.