This is a compelling little essay. I think the author left out a couple of important points, though.
1. Design systems may be "algorithmic," but they're primarily mathematical, and equations remain stubbornly hard to use. Metafont failed to attract designers because no one wanted to cook up high-order polynomials to express their visual ideas. (In contrast, Adobe came up with a good-enough interface for Bezier curves, and now the world uses non-algorithmic fonts.) The new class of designers will need solid grounding in at least high school algebra to get their curves and easing functions right.
2. Any argument about "XXX should learn to code", where XXX is anything other than "aspiring professional software developers," means that there is a significant market opportunity for creating usable software that does not require coding. If people are willing to spend thousands of dollars on bootcamps to learn to code -- when they'd really rather be focusing on their domain problem -- then they're theoretically willing to pay thousands of dollars to not have to learn how to code.
I don't know the state of design software, but if it's anything like other professional desktop tools, it's horrible, creaky software stuck in the early 1990s with very little competition in sight. When I read this essay I can't help but think there's an opening for usable algorithmic design software -- whatever that may look like.
I agree with your first point. I don't see designers learning to represent ideas as equations. Not even most of the people who studied Computer Science know the difference between a function and the graph of a function. So I don't see how more difficult concepts can be taught to designers who have no foundation in maths whatsoever. And I don't think that high school maths is really enough. You need a solid knowledge of Linear Algebra to understand how to display a 3D object properly.
Expressing a design as a mathematical expression that generates new representations that follow some guidelines means the designer needs to rigorously understand the very essence of what it is he's trying to do. And then he still needs to know the maths to actually formulate it. This is a tough problem if you start from scratch and I doubt that many designers are really capable of pulling it off.
AFAIK creating those layouts for iOS apps has mathematical reasoning. If you design your app, you basically specify rules to anchor each object on the screen. When the app tries to draw its interface, a linear system of equations gets solved and the solution is the best way to put all the objects on the screen, given the rules that were defined. This gives you an extremely powerful design tool to specify your layout for arbitrary screen sizes.
I would very much hope that they do the same for CSS any time soon.
> Not even most of the people who studied Computer Science know the difference between a function and the graph of a function.
I am surprised by how often I hear this example. Not because people can't define the graph of a function, but because in usual set theoretic terms[1] a function and its graph are the same thing. They are both the set of points (x, f(x)) where x ranges over the domain of f. This is an equivalence that isn't even made by most mathematicians, as they usually denote the graph a function as Γ(f), implying it is different from f itself as a function. Of course they know the equivalence, but prefer to separate the objects notationally for clarity's sake.
[1]: I'm ignoring the notion of a function in category theory, since CS students who are taught math are primarily taught naive set theory, not category theory. Of course, when you aren't working in a category of sets then the graph of a function doesn't make sense, I think.
> I am surprised by how often I hear this example.
Huh? That surprises me, too. I didn't know it was so common.
Anyway, I agree that there is an equivalence between a function and its graph. Knowing one implies you know the other. But just because it's equivalent, doesn't mean it's the same. A two-dimensional graph is, after all, a set of tupels in R^2. A function, however, is a mapping from one element in one set to another element in another set.
Mathematically they're very different. I can't draw functions, I can only draw sets. I can't apply sets, I can only apply functions. It makes sense to treat them as different things.
Actually, vector graphics are mathematically specified by graphs of functions, not pixel sets. This makes it possible to zoom in without pixelation, since the function in the graph can be defined analytically (like Bezier curves). If you started out with sets instead of functions, you'd get pixel graphics, since it's not possible to save an infinite set. So the equivalence of a function and its graph holds until you try to implement something.
For whatever reason, I hear it as a "challenge" trying to show someone they don't understand math.
But again, I would argue that you're ignoring the difference between an object and its representation for the purpose of communication. A function is defined to be a set of tuples (a relation) with some extra properties. These tuples are the input-output pairs of the function, which is exactly how you define the graph of a function. They are literally the same object, regardless of whether you choose to represent them as a picture or a mapping. The choice of language suggests they are different things because you want to treat them differently (and this is a good thing), but when you get down to the definitions they're the same.
Your example of vector graphics is not a counterexample to this because the sets that define those functions are uncountably infinite. When you render them on the screen to have to approximate them by a finite pixel set, but that is unrelated to the underlying function's mathematical nature.
These set-theoretic definitions of functions and relations are standard parts of an introductory course on set theory.
I've thought about using a pattern generator to set the background image of my IDE/editor based on the current file name. It'd be fun to see if any side benefits come up, such as:
* Knowing immediately/intuitively if you've switched to the wrong file.
* Triggering the context/ideas you had when you last opened that particular file.
I wrote this some month ago [1]. All the properties of the lines can be distorted with perlin noise. Especially when working with color this gives much better results then randomly setting the values.
I started writing code as a classically trained designer after my first layoff from an agency many years ago... Something you learn once you cross over, is that this isn't new. A little research and I can start listing design firms that have been around since the late 1980's that promote this multi-disciplinary approach, designers who code, programmers who paint, etc.
Years later;once I picked up heavier languages, from a designers point of view, programming is broken. Point and click is not ideal but slugging through pages of non-human language is worse. Faster at times... but not a solution. Flame away, that's just my opinion from an outsiders point of view.
Non-human? What makes you think the languages are non-human? There sure are some inhumane languages around (hehe) but have you ever tried e.g. Common Lisp? There are some very well designed languages around and their source code is as pleasurable to read as its authors were skillful. Of course, I can imagine a graphical s-expression editor which makes it even better to work with Lisp.
Would using code that converts data into standard visualizations (e.g. heat maps, sparklines) be considered meta-design? If so, it's not so uncommon (e.g. ggplot2, Tableau, matplotlib, Excel charts…).
I find this quite fascinating but: My browser settings include a font-size option, at least the first link's demo breaks with adjusted font sizes. (E.g. minimum font size == 15).
(Theoretically) If I would report a bug against your product, complaining that your layout breaks when I force font sizes in my browser, would you try to fix it or tell me that 99.9% of all users don't set font sizes and I shouldn't too?
the issue here is that we use pre-measured GSS (http://gridstylesheets.org/) on the site for perf reasons, and the intrinsic sizes of things were measured using the defaults. We could probably detect that you're overriding them and switch off the pre-measurements in that case. I'll talk with the GSS devs.
I suspected that this was the case. In my opinion that means GSS is fundamentally broken and the fact that nobody thought of that kind of discredits the whole thing...
The fact that 70% of "modern" websites already have the same bug doesn't justify it imho.
Exploring a meta-rule space and finding rule sets that create results that humans find interesting is much harder.
If you skip that you tend to create systems that seem too random, or too repetitive and obvious.
This is why most algorithmic art is so uninteresting. It falls on one side or the other of the randomness/repetition valley, without hitting that sweet spot that the best human creativity finds.
That's not even thinking about emotional associations, intellectual abstractions, social awareness, and models-of-mind. You might need all of them to make a genius-level creative AI, but I'd guess that the more you have, the more likely you are to get something worth keeping.
That's why I find "augmented intellect" so much more interesting as a concept than "artificial intelligence".
Truly autonomous behavior is out of reach of our reasoning systems, using most known approaches to AI. But if you put a human in charge of the creative part, and complement it with the automation capabilities that simplify the repetitive parts, the result is a win-win match combining the strengths of both.
I guess that's the continuation of automating tasks and building up. Push more and more work to the computer / AI. We've been going through writing higher level languages, and the article is describing going a step higher again.
> This is why most algorithmic art is so uninteresting. It falls on one side or the other of the randomness/repetition valley, without hitting that sweet spot that the best human creativity finds.
> That's not even thinking about emotional associations, intellectual abstractions, social awareness, and models-of-mind. You might need all of them to make a genius-level creative AI, but I'd guess that the more you have, the more likely you are to get something worth keeping.
I don't agree. I find all of those things boring in art. Mathematics and computer science are much more interesting when you think about how it relates to the mind, and why people may choose to create abstract art instead of metaphorically painting themselves naked.
This is so true. I make fractal art and desktop wallpapers as a hobby and it can actually be pretty exhausting (in a good way). Finding results for other humans is only part of the problem--finding results that keep my own continually evolving aesthetic happy is very difficult.
1. Design systems may be "algorithmic," but they're primarily mathematical, and equations remain stubbornly hard to use. Metafont failed to attract designers because no one wanted to cook up high-order polynomials to express their visual ideas. (In contrast, Adobe came up with a good-enough interface for Bezier curves, and now the world uses non-algorithmic fonts.) The new class of designers will need solid grounding in at least high school algebra to get their curves and easing functions right.
2. Any argument about "XXX should learn to code", where XXX is anything other than "aspiring professional software developers," means that there is a significant market opportunity for creating usable software that does not require coding. If people are willing to spend thousands of dollars on bootcamps to learn to code -- when they'd really rather be focusing on their domain problem -- then they're theoretically willing to pay thousands of dollars to not have to learn how to code.
I don't know the state of design software, but if it's anything like other professional desktop tools, it's horrible, creaky software stuck in the early 1990s with very little competition in sight. When I read this essay I can't help but think there's an opening for usable algorithmic design software -- whatever that may look like.