Bonus Drop #4 (2023-02-25): Good By Design

Typographic Hierarchy; dstp; Nickel; Ride-By-Wire

Releasing another Bonus Drop vs. WPE b/c of (yes, still) this daft digit of mine.

In other news, Arc decided to let google win, so you may want to use https://rud.is/sandbox-check/ on any Chrome instance (Canary overrides some prefs now, too) if you are still using Chrome/Chromium browsers.

Hello again, weekend warriors, wayfarers, and wanderers! Today's Bonus Drop presents four resources: an information presentation system, a “do one thing well” tool, an emerging standard, and a spiffy invention that share one crucial concept in common: they are all good by design.

Head down the “kitchen gadget” aisle at any dollar store and pick up a can opener at random. You may be able to tell just by the sight of it that it's not going to be very useful at its job. However, some shiny wrappers can be deceiving. But, once you have it in hand, the lack of quality of the product likely begins to become super apparent. And, when try to use it to get open any given tin can, the results will further likely confirm that the tool was no good from the start.

Being thoughtful and intentional about what we build and use is important if we want our work to be taken seriously and be used + shared with others. In the case of the example can opener, using a poorly designed one can have other negative consequences (beyond just losing ~$3.00 — dollar stores are woefully misnamed these days).

Let's dig in.

Typographic Hierarchy

Photo by Bruno Martins on Unsplash

Longtime readers will know I'm a font snob. I started off my career steeped in typography, and those glyphs still have a solid hold over me.

A well-designed document or user interface stands out from the crowd (in a good way). And, as is the case with so many other areas in life, a huge amount of the burden falls upon some foundational rules.

One of those rules is covered incredibly well in this article by Oliver Schöndorfer, a designer out of Austria. I'll let Oliver give you the pitch:

Visual hierarchy enables viewers to get the things they need quicker. This is why it’s key to let your print, web, or app design perform at its best. In this practical article you will learn how to leverage the two main principles of visual hierarchy in typography. So you can create convincing document layouts, outstanding buttons in web design, and clear components in your next app or UI design.

If you can forgive Oliver's use of some insidious (but easily foiled) JavaScript to make select+copy operations difficult, you'll be greeted with numerous examples of bad designs turned into good ones.

Now, Oliver is a veritable wizard, but no amount of magic can repair an incredibly flawed piece of content. He notes that up front, suggesting you need three things before you focus on the design details:

• Know what the primary goal of a design is,

• Make sure the content is relevant, and

• Be clear about the levels of information.

The piece goes on to present the two core concepts:

• Contrast establishes visual hierarchy

• Space amplifies visual hierarchy

with (as noted) plenty of examples.

I especially appreciate the “makeover approach” Oliver takes throughout the piece, and I think you will as well.

dstp

Photo by Bermix Studio on Unsplash

Along with fonts, I'm also a fan of utilities that “do one thing, and do it well”. dtsp fits this description perfectly.

dtsp is a Golang utility that does (up to) five tests that help answer a fairly common question: “How do you tell if a problem is caused by DNS?”. It does this by taking a URL or IP address, then combining several troubleshooting idioms into one, which is easier to just show than to explain:

$ dstp https://example.com/
Ping: 20.824666ms
DNS: resolving 93.184.216.34
SystemDNS: resolving 93.184.216.34, 2606:2800:220:1:248:1893:25c8:1946
TLS: certificate is valid for 353 more days
HTTPS: got 200 OK

You can also get the output in lovely JSON format:

dstp --out=json https://example.com/
{
  "ping": "24.993ms",
  "dns": "resolving 93.184.216.34",
  "system_dns": "resolving 93.184.216.34, 2606:2800:220:1:248:1893:25c8:1946",
  "tls": "certificate is valid for 353 more days",
  "https": "got 200 OK"
}

I use dstp as the first step in troubleshooting any apparent connectivity issues (this happens a bit when I forget to turn the work VPN off), and I think you'll find a comfy place for it in your toolbox.

Nickel

Photo by Marjan Blan | @marjanblan on Unsplash

Nickel [GH] solves the “configuration file” conundrum so well that I will be covering it in more detail in one of the M-F Drops next week. I just wanted to give supporters a sneak peek at something that may be able to save us all from YAML Hades, and possibly bring the JSON, YAML, and TOML communities together in perfect harmony (queue old school Coke™ commercial).

I'll let the Nickel devs explain:

Nickel is the cheap configuration language.

Its purpose is to automate the generation of static configuration files - think JSON, YAML, XML, or your favorite data representation language - that are then fed to another system. It is designed to have a simple, well-understood core: it is in essence JSON with functions.

Nickel's salient traits are:

• Lightweight: Nickel is easy to embed. An interpreter should be simple to implement. The reference interpreter can be called from many programming languages.

• Composable code: the basic building blocks for computing are functions. They are first-class citizens, which can be passed around, called and composed.

• Composable data: the basic building blocks for data are records (called objects in JSON). In Nickel, records can be merged at will, including associated metadata (documentation, default values, type contracts, etc).

• Typed, but only when it helps: static types improve code quality, serve as documentation and eliminate bugs early. But application-specific self-contained code will always evaluate to the same value, so type errors will show up at runtime anyway. Some JSON is hard to type. There, types are only a burden. Whereas reusable code - that is, functions - is evaluated on potentially infinitely many different inputs, and is impossible to test exhaustively. There, types are precious. Nickel has types, but you get to choose when you want it or not, and it handles safely the interaction between the typed and the untyped world.

• Design by contract: complementary to the type system, contracts are a principled approach to checking assertions. The interpreter automatically inserts assertions at the boundary between typed and untyped code. Nickel lets users add arbitrary assertions of their own and easily understand why when assertions fail.

The motto guiding Nickel's design is: Great defaults, design for extensibility.

Give it a look and watch for some more information and examples in an upcoming Drop.

Ride-By-Wire

I will never give up my road bike, but my spouse wanted to get back into cycling and also add some adventure along the way, so we picked up some trail-worthy e-bikes last year and they are quite magical inventions.

Some folks just came up with a crazy cool way to make them even better that I felt compelled to share.

This invention will hopefully further reduce pollution and congestion in cities, and I suspect us rural folk will find some good uses for the bikes it helps create as well.

FIN

Thanks for reading and supporting the Drops! ☮