Drop #213 (2023-03-06): Design Time

Semantic Typography; Stop Designing Languages?; Design System Accessibility

Every so often, these Drops encourage folks to exit their terminals, quiesce their Docker containers, close VS Code

¹

, pour a cup/glass of their fav beverage, and go for a digital excursion into Designville.

Longtime

²

readers can likely jump to today's sections, all of which focus on some aspect of “design”. Folks new to the Drop may benefit from the following tiny expository on “design”:

"Design" refers to the process of creating a plan or blueprint for the creation of something, whether it be a physical object, a system, a process, or a communication. It involves making intentional choices about the form, function, aesthetics, and usability of the object or system being designed.

It can be seen as a problem-solving process that involves identifying needs and constraints, brainstorming and generating ideas, refining and iterating on those ideas, and ultimately producing a final solution that meets the identified needs and constraints.

You can apply design principles to many different areas, including architecture, engineering, graphic design, fashion design, product design, software design, and more. The goal is often to create something that is not only functional and efficient, but also beautiful, meaningful, and enjoyable to use.

Semantic Typography

In a recent paper (direct PDF 🔗), a group of anonymous authors showcase a new AI model — based on Stable Diffusion — that can take the semantic meaning of a word or passage and reshape the individual glyphs to help visualize intuited meaning. They describe it much better:

A word-as-image is a semantic typography technique where a word illustration presents a visualization of the meaning of the word, while also preserving its readability. We present a method to create word-as-image illustrations automatically. This task is highly challenging as it requires semantic understanding of the word and a creative idea of where and how to depict these semantics in a visually pleasing and legible manner. We rely on the remarkable ability of recent large pre-trained language-vision models to distill textual concepts visually. We target simple, concise, black-and-white designs that convey the semantics clearly. We deliberately do not change the color or texture of the letters and do not use embellishments. Our method optimizes the outline of each letter to convey the desired concept, guided by a pre-trained Stable Diffusion model. We incorporate additional loss terms to ensure the legibility of the text and the preservation of the style of the font. We show high quality and engaging results on numerous examples and compare to alternative techniques.

The section header is an example of the output of their work. While it's a YouTube link

³

(to make it easier to embed in Substack), the video was made by the paper's authors.

Their word-as-image method can handle a large variety of semantic concepts and use any font, while preserving the legibility of the text and the overall style of the font:

The approach is focused on changing only the geometry of the individual letters. It utilizes the Score Distillation Sampling (paper) to “encourage” the appearance of each glyph to reflect the guessed textual concept.

Hit up their site and paper to get the rest of the technical details (code and online model “coming soon”).

I don't know if this text-to-image model is going to fuel/reignite the “AI is replacing human artists” debate, but my opinion is that it really should not. It seems like this would be an excellent tool for designers and artists to use as part of their workflows. Sure, it will also enable mere mortals (such as myself) to make logos, adorn decks and docs, and enhance other visual comms on our own. But, I can already envision many ways artists-proper could level-up initially transformed text to make even more compelling designs. What's more, it should give actual artists more time to focus on said enhancements.

It'll be interesting to see what the remainder of 2023 has in store for the creative application of existing and forthcoming powerful AI models.

Stop Designing Languages?

Photo by Kai Pilger on Unsplash

There are scads of programming languages out there. Back in August 2022, the Drop showcased the Programming Language Database (pldb)

⁴

, and its current language tally sits at just over 4,300 (up from just over ~4K).

That number may seem a tad excessive. I mean, we have Smalltalk, Rust, and R, so why would one really need any other language?

My sad attempt at fueling a language war debate in this post’s comments notwithstanding, one of Patrick S. Li's friends did think there were, perhaps, too many languages, which inspired him to write “Stop Designing Languages. Write Libraries Instead.”, which we'll dig into in a moment.

NOTE: all links to lbstanza.org are http vs https, as their site does not have a certificate. This may cause some browsers to generate a full “safety” warning or light up a warning indicator. I can assure you it is safe to visit the site.

Patrick is the designer and implementer of Stanza, an optionally typed general purpose programming language from U.C. Berkeley. Stanza was “designed to help programmers tackle the complexity of architecting large programs and significantly increase the productivity of application programmers across the entire software development life cycle”. We'll cover Stanza in some future edition, but you can poke at it now if you like.

It's easy to see why someone would strike up a conversation about programming languages with Patrick, given his domain expertise. Since he helped design and implement an actual programming language, he's also in a good position to address the topic:

I had a friend tell me recently that all programming languages seem very similar to each other. They all have variables, and arrays, a few loop constructs, functions, and some arithmetic constructs. Sure, some languages have fancier features like first-class functions or coroutines, but he doesn't consider himself an expert programmer anyway and doesn't use those features.

What really makes a programming language productive for him, he says, are the libraries it comes with. For example, he got into programming by using the popular Ruby on Rails web framework. There is no way that he could have written a full database-driven web stack by himself, nor is he interested in doing so. But thanks to Ruby on Rails, he doesn't have to! So he said that he has no particular opinion about the Ruby programming language, but he absolutely loves Rails. The vast majority of programmers are non-experts, like himself, and the largest gains in productivity for non-experts come from having a wide spectrum of easy-to-use libraries. Subtle language features like first-class functions, and object systems, are lost on them because they don't really use them anyway. Computer scientists should really be spending their time developing new libraries rather than inventing new programming languages.

Patrick then frames the rest of the post with a good question: why isn't there, now, a Rails framework for every programming language? He quickly neutralizes two arguments around “incompetency” and “economics”.

After some deep dives, we get to the heart of the answer:

The design of the programming language directly determines what sort of libraries you can write and how easy they are to use in the end. In the C language, the only major feature provided for enabling reuse is the ability to declare and call functions. So guess what? The majority of C libraries are basically large collections of functions. Ruby on Rails provides a concise way for expressing: do this when the button is clicked. The "do this" part is implemented in Ruby as a first-class function. How would it be implemented in languages like Java which don't support them? Well, the behaviour of first-class functions can be mocked by defining a new event handler class with a single perform_action method and then passing an instance of this class to the button object. So guess what? Using a Java library typically entails declaring a humongous number of handler classes. The programming language directly shapes the design of its libraries.

and, ultimately concludes:

…the purpose of a general-purpose programming language is to enable the creation of powerful and easy-to-use libraries. The more powerful the language, the easier the libraries are to use. Code that makes use of a perfectly tuned library should read almost like a set of instructions for a coworker. So the next time you come across a particularly elegant library, know that many decades of language research has gone into making that possible. If you're curious about specifically which language features a library makes use of, then you can dig deeper, explore, and appreciate the thought that went into its implementation. If you're not curious about all this subtle language stuff, you can safely ignore it all and get on with your work. That's the whole point.

It's a thoughtful and well-crafted post that I'll be keeping around for when pldb reaches 5,000 entries, which may be this year given the frenetic pace of new language creation.

Design System Accessibility

In part one of a two-part series, Stephanie Smith [LI], a Senior Product Designer at Wise Design takes a deep dive into picking accessible colors for a design system. Wise is re-branding, and Steph is ensuring the new design is both appealing and accessible. We (GreyNoise) are also in the process of leveling up our design system with a heavy focus on increased accessibility, so Steph's post really piqued my interest. She has a great pitch:

There’s a misconception that making a product accessible means sacrificing the visual design. Your UI will look too plain, they say. Your branding too dry, or too ugly. But gone are the days when you had to look like a boring bank to build a product that can be used by all. It’s time to think bigger. Bold brands embrace accessibility.

At Wise, 1 in 3 of our Android customers use an accessibility setting. To work everywhere, we have to work for everyone. Zero compromises. The challenge we set ourselves when re-branding our design system — be bolder with less, and open to all.

Stephanie goes on to discuss how to strike a vibrant and inclusive tone with deliberate color choices, takes a look at the need to focus on contrast ratios, and explains how to conduct testing using various accessibly tools,

Part two will lean into typography, icons, focus states, and more. Wise does not have an RSS feed (that seems like a bit of a design/UX failure to me), but I created one for it in my Inoreader setup and will drop a note in a future Drop when it lands on their site.

FIN

I hope everyone's Monday is designed for success! ☮

1. Or your telemetry-free editor of choice.

2. It’s almost been a year!

3. Substack claims to support Vimeo embeds, but it did not work for me. I’m trying harder to not use Google/Microsoft kit, but plenty of environments do not make that an easy goal.

4. TIL you can link to individual sections in Substack newsletters.