On Design as Information

Or what a coffee cup can teach you about data structures.

XLVIII

2024.05.26

Some things are designed well enough that they just explain themselves.

The handle on a cup of coffee contains information without explicitly needing to communicate it, just like a good website or data structure does.

Bells & Coffee

Coffee. I love coffee. Perhaps too much! Or so I’ve been told.

Coffee mugs are cool. I have a few I’m particularly fond of, but am nearly 1,000 miles away from them as I write this. So, I’ll share some ‘local’ coffee mugs:

Now, what sticks out about coffee mugs, quite literally, is the handle on the side. That and the material are perhaps the defining characteristics of a coffee mug.

The overall design screams: “Pick me up, HERE!” ‘Here’ is the handle. Unlike a typical cup that is relatively uniform all the way around the circumference and communicates that it is quite indifferent to how it is picked up, the coffee cup has instructions baked into the designed.

While there is no explicit warning label or sticker saying “Hot, do not touch,” across the rest of the mug, that notion is, to some extent, implied. Even if it doesn’t necessarily say why you shouldn’t grab the cup like you would a normal cup, it does scream that the handle is there for a reason.

That’s good design.

Another example of intuitive design is the bell sometimes found on a bike handlebar. Again, there is no instruction manual or sticker that says, “Use your hand to make noise with me when you need to,” but you should be able to extrapolate that pretty easily. The bell, after all, is right next to your hand.

If, for some reason, the bell was hidden under the seat of the bike, it could still very well serve the same purpose—alerting others of your presence. However, it would not be anywhere near as intuitive as it is given its placement by your hand. If the bell was below your seat, you might ask, “Why is there a bell below the seat of my bike?” And someone might say, “To help you alert others that you are coming and on a bike!” To which you would reply, “Oh! That makes sense. But it might be difficult to use!” To which the other person would say, “Oh, yes, it is!”

So, because the bike creator poorly decided on the bell placement in our fictitious example, you would need instructions on how to use it. And, you probably wouldn’t enjoy using it very much and might just shout at people as an alternative. But, if the bell was by the handle, as it is, you’d quite quickly understand it’s function without much explanation.

The design of the thing should contain information about the thing. If the coffee cups handle went right to left instead of up and down, it might be a little bit less obvious what the purpose was.

Usable Web Apps

The design of a thing presents information about it. On a web apps, this should be no different.

You can have a very bare bones, html page that presents information and perhaps allows for some functionality. But, if you have a lot of information, how do you make it processable by a human without feeling like they are just reading a book?

As I discussed last week, we’re working to make our Ultima Mercury product more intuitive and easy to use. So, one very nice example that someone on the team smarter than me came up with was swapping the word “LinkedIn,” which was hyperlinked text to the person’s LinkedIn page, with a little icon reminiscent of the LinkedIn logo. And by reminiscent of the LinkedIn logo, I mean to say that it is the LinkedIn logo.

While the LinkedIn logo contains pretty much exactly as much information as the word “LinkedIn” did, it is able to convey the same amount of information with fewer pixels. And, since it freed up some space, it allowed us to add in more information, whether or not the user is connected with the contact, in roughly the same amount of screen real estate.

And, if you ask, what if our customer doesn’t know what the LinkedIn logo looks like? Well, then, they probably would not be in sales to begin with. Even if that were a problem, we are now on the side of convention, which is to include a social media logo clickable to a person’s account on the corresponding site.

A separate complaint we have right now is that the user has to scroll to the bottom of the page to see the emails we’ve generated for a contact in a drop down menu. To make matters worse, they’re stored in no obvious order. Meaning, the first contact displayed might have the last email in the stack. So, it’s not at all intuitive, creates the friction of scrolling up and down between the contact info and the email, and does not allow them to immediately connect the email being sent to the information we’ve provided about the person they’re sending it to.

So, we’re going to remove the email generation drop down menu from the bottom completely and add in a pop up next to each contact that shows the generated email and allows you to send it directly from there. All the information needed to evaluate, edit, and send the email will be provided right next to where you’re sending the email.

Not only does this make the product easier to use, it also implies which information is connected to which intended action.

We’re going to put the bell next to the handle bar, rather than underneath the seat.

Implied Data

The same principle of design containing information applies to code and data structures. In general, the better the design of the data, the less complex the code to interpret and process it must be.

Let’s say you like to pay for box delivery subscription services. You know, like a monthly “Wine Box” or a monthly “Cheeses Box.” But, there’s maybe a hundred such services you are interested in, and you have three different ‘relationships’ with each of these box providers. For simplicity, we’ll assume that, before you get a subscription, you always get the discount trial box.

1) There is no relationship.

2) You have gotten a discount trial box.

3) You have a subscription.

How could we design a data structure to contain that information for each of say, a 100 box providers? A straightforward option could be storing it as a series of boolean true / false values:

{
   "wineBox": {
      "noRelationship":true,
      "discountBox": false,
      "subscription": false
   },
   "cheeseBox": {
      "noRelationship":false,
      "discountBox": true,
      "subscription": true
   },
   "bookBox": {
      "noRelationship":false,
      "discountBox": true,
      "subscription": false
   }
}

This is okay, but really, it’s way more complex than it needs to be. “noRelationship” is implied by both “discountBox” and “subscription” being false. So, we can nix the first field altogether:

{
   "wineBox": {
      "discountBox": false,
      "subscription": false
   },
   "cheeseBox": {
      "discountBox": true,
      "subscription": true
   },
   "bookBox": {
      "discountBox": true,
      "subscription": false
}

If we have 100 box providers, we just reduced our data structure by a 100 lines. Woohoo! When we go to interpret this later, it’s pretty clear that if “disocuntBox” is false and subscription is also false, then we have no relationship with this box provider, or at least no relationship yet.

Realistically, though, if we’re willing to trade the boolean values for a string, in this case just a word, we can reduce the code even more:

{
   "wineBox": {
      "subscriptionStatus": ""
   },
   "cheeseBox": {
      "subscriptionStatus": "subscribed"
   },
   "bookBox": {
      "subscriptionStatus": "discountBox"
}

Here, we have something that we originally captured with three fields per box provider stored with one field. This is an easy example because each option implies something about the other options. If you input:

1) Nothing, we know there is no relationship, implying no subscription or discount box received.

2) “discountBox”, we know that you do have a relationship with the box provider but are not yet paying for the whole subscription.

3) “subscribed”, we know that the implied data “noRelationship” is false and “discountBox” is true.

In this way, the data structure intuitively contains more information than it explicitly does, just like the bell, the handle on the coffee cup, the LinkedIn button, or moving an email sending box.

Well designed things implicitly contain information in their design, from coffee cups to data structures.

This idea is closely related to a few other topics I am circling, including the interplay pointed out by Assembly Theory between a living entity inherently being information of a certain complexity that can produce more information, as well as the notion of data as the code. More on that later.

In the meantime, thank you to everyone who has given their lives on the field of battle.

Live Deeply,