Design Icon

Design

140 Stories
All Topics

Increment Icon Increment

What the history of HTTP status codes can tell us about the future of APIs

Darius Kazemi writing in Issue #14 of Increment magazine:

HTTP status codes are largely an accident of history. The people who came up with them didn’t plan on defining a numerical namespace that would last half a century or work its way into popular culture. You see this pattern over and over in the history of technology.

Because technology isn’t immune to historical contingency, it’s important for us as engineers to remember that long-lasting technical inflection points can occur at any time. Sometimes we know these decisions are important when we’re making them. Other times, they seem perfectly trivial.

The Changelog The Changelog #410

Bringing beauty to the world of code sharing

Carbon is an open source web app that helps you create and share beautiful images of your source code. Whether you’ve used Carbon personally or not, odds are you’ve seen its dent on the universe of social code sharing. Mike Fix has been maintaining Carbon for a few years and he’s embraced the project as an opportunity to experiment and practice working in public.

On this Maintainer Spotlight episode, we chat with Mike about building Carbon, growing its community, sustainability models, and why he loves the world of open source.

The Changelog The Changelog #399

Shipping work that matters

We’re revisiting Shape Up and product development thoughts with Ryan Singer, Head of Product Strategy at Basecamp. Last August we talked with Ryan when he first launched his book Shape Up and now we’re back to see how Shape Up is shaping up — “How are teams using the wisdom in this book to actually ship work that matters? How does Shape Up work in new versus existing products?” We also talk about the concept of longitudinal thinking and the way it’s impacting Ryan’s designs, plus a grab bag of topics in the last segment.

Stephanie Morillo stephaniemorillo.co

UX design is more than visual design

Stephanie Morillo

In my own observations and conversations with developers and marketers, UX design is often conflated with visual design or user interface design, when in fact both of these are sub-disciplines within the field of UX design and are not representative of the totality of UX. I’ve been involved in conversations where talk of updating a “page’s UX” has meant adding visual design elements to a page. Anecdotally, I’ve seen calls for “UX designers” in open source when the need was for brand assets like a logo. (In this case, you would look for a visual designer.)

In this short post, I’ll cover some basics of UX design for developers who are interested in understanding what UX is and how it differs from other forms of design.

Design growth.design

101 cognitive biases & principles that affect your UX

This list is deep and (of course) the UX is well-considered. The author provides definitions of the biases as well as real-world examples of them in action.

Every time users interact with your product, they:

🙈 Filter the information
🔮 Seek the meaning of it
⏰ Act within a given time
💾 Store bits of the interaction in their memories

So to improve your user experience, you need to understand the biases & heuristics affecting those four decision-cycle steps.

Design github.com

BlurHash – a very compact representation of a placeholder for an image

This is a very cool idea and the use case is described perfectly by the authors:

Does your designer cry every time you load their beautifully designed screen, and it is full of empty boxes because all the images have not loaded yet? Does your database engineer cry when you want to solve this by trying to cram little thumbnail images into your data to show as placeholders?

You give BlurHash an image and it gives you back a short string (20-30 chars) that represents the placeholder image. Store the string and send it along with the other data for the object and your client can decode the string into a placeholder image while the real image is loading over the network.

Design gilli.is

Why designing for open source can be so difficult

After being involved with design and open source projects for many years, I’ve noticed a few common reasons why designing for open source projects can be very difficult. Open source projects (especially FOSS) face a lot of issues that more conventional projects don’t because they lack a clear business model, the structure, and the incentives that for-profit proprietary projects have.

This is a hard problem due to many of the factors outlined in the post, but one worth solving.

0:00 / 0:00