Recommended articles

On a housing bubble in the early 2000s:

A combination of deregulatory economics, a heavily commercialized and materialistic culture, and the public thirst for excess post-‘70s energy crisis made the ‘80s a perfect time for conspicuous consumption. During this decade, a heavy emphasis was placed on luxury and the display of personal wealth, which, of course, was reflected in our houses. Mixing this shiny new materialistic culture with the economic reforms of the 1990s created a perfect storm for a housing bubble to form in the early 2000s.

On a total "beigeification":

Beigeification was part of a larger shift that happened during the early 2000s. After centuries of the home being primarily a place or a space, during the 2000s it was seen as primarily an object or, more specifically, an asset. At a time where mortgage speculation made our houses disposable and impermanent, beige slipped happily onto the walls of millions of Americans, who wanted easy ways to make their house “worth more” at the behest of HGTV and other media, who treated the home as a thing to be changed, or disposed of on a whim. Beige was not a harbinger of the clinical, minimal design that is so popular now; it was the harbinger of a bubble. When houses stopped selling, our design aesthetics immediately changed, streamlined by a tight wallet.

A good test of a design principle:

I think it was from Cennydd that I heard about a really good test of a design principle: is it reversible? In other words, could you imagine the exact opposite of the design principle being perfectly valid in a different organisation or on a different project? If not, then the principle may be too weak to be effective. […] “Make it easy to use” would be an example of a weak design principle. It’s hard to imagine a situation where “make it hard to use” would be a reasonable guiding principle.

On a recent invention of the whole concept of "progress":

The idea that humans should and could work consciously to make the world a better place for themselves and for generations to come is by and large one that emerged in the two centuries between Christopher Columbus and Isaac Newton. Of course, just believing that progress could be brought about is not enough—one must bring it about. The modern world began when people resolved to do so.

On a departure from the beliefs:

The respect for classical texts started to fade away in Europe in the 16th century and went into a meltdown in the 17th, when more and more of the ancient certainties were questioned and then found to be incorrect. If the classic authorities could be wrong about so many things, why would should they be trusted about anything?

On a rise of skepticism:

Worse was to come: After 1600, Europeans developed scientific instruments that allowed them to see things the ancient writers could never have imagined. No wonder they began to feel superior: Ptolemy had no telescope, Pliny had no microscope, Archimedes had no barometer. The great classical writers may have been smart and well-educated, but European intellectuals thought of themselves as equally intelligent and better informed—and thus able to see things the ancients could not. Hence, everything must be tested with real evidence, not on the say-so of authorities who had lived 1,500 years earlier. The motto of the Royal Society, which was founded in 1660 in London, was in nullius verba — “on no one’s word.” Skepticism was the taproot of all knowledge. Even the Bible itself began to be examined critically, not least by Baruch Spinoza, who cast doubt on its divine origins and saw it as just another text.

And finally on progress itself:

Progress, as was realized early on, inevitably entails risks and costs. But the alternative, then as now, is always worse.

On what differentiates technical debt from a bad code:

The thing that separates technical debt from the rest of the hacky code in our project is the fact that technical debt, by definition, is something that we knowingly and strategically entered into. Debt doesn’t happen by accident: debt happens when we choose to gain something otherwise-unattainable immediately in return for paying it back (with interest) later on.

On bad code:

Where technical debt is knowing that there’s a better way, but the quicker way makes more sense right now, bad code is not caring if there’s a better way at all. […] Technical debt often represents ability in judgement, whereas bad code often represents a gap in skills.

Harry makes a very good point in this post. I myself and my colleagues been bitten by this so many times that we decided to add a note on looking out for inappropriate shorthands to our CSS style guide.

This is an interesting peak into the world of Instagram-as-a-business-tool, covering costs and tools of "influencers". On hipster-friendly lifestyle content that should be added to the main topic:

Another difficulty was that I’d been told to post at least one piece of “lifestyle content”—that is, a picture of something other than myself—every day. In general, pictures of people get more likes than anything else, but the idea was to create a sense of variety and to avoid boring my new audience. [ ... ] Alexander introduced me to Alisha Siegel, a wedding photographer by trade who also sells stock images to influencers. Siegel could offer me as many perfectly framed lattes, hipster hotel lobbies, and urban sunsets as I wanted. I bought 20 for $400, which brought my total tab for photography services to $2,000.

On the cost of sponsored posts:

By the end of Week Two, I’d reached 600 followers, or a threefold increase. Saynt told me he thought that if I kept it up, I could be at 10,000 by the end of the year, which would be enough to command maybe $100 per sponsored post.

For a completely different angle also see Wired's story Like. Flirt. Ghost: A Journey Into the Social Media Lives of Teens — it's amazing how differently social media is used by those two audiences.

While researching options for a mobile-friendly navigation in a new app I am working on, this article became very helpful with its results from a quantitative usability testing that Nielsen Normal Group conducted.

Golden words on “mobile-first” approach:

Obviously, there’s a general principle here: if a design technique is intended to span platforms X and Y, then an uncompromising X-first approach will make Y an afterthought and harm users on Y. As explained in our course on Scaling User Interfaces, to design for X and Y, you need to consider the strengths and needs of both and adapt the two versions of the website accordingly.

Two main (and expected) findings on a hidden navigation:

1. It is significantly less discoverable.
2. It decreases user experience both on mobile and on a desktop.

Their recommendations at the end of the article for both desktop and mobile navigations make a lot of sense and tested with time. See also their checklist of 15 guidelines on menu design.

An interview with Geoff Teehan from Teehan+Lax fame, currently a Product Design Director at Facebook. I've been a fan of his work for a while, and in this interview he talks about his current role at Facebook, design leadership, how Teehan+Lax got started and eventually closed, his daily routines, and much more.

Not really an article, but an interesting chart explaining how personas, jobs to be done, and customer journey maps get used together at Cooper. I was interested in combining JTBD and personas for quite some time and this is definitely a realistic approach.

One of the most sane articles I ever read on code refactoring, writing maintainable CSS, and visual regression testing.

On a definition of “legacy code”:

In his 2004 book, Working Effectively With Legacy Code, Michael Feathers describes a different definition of ‘legacy code’. He defines it as code that is not covered by tests. That’s it. If you think about it for a moment, it makes sense. It applies to old or new code. It focuses on maintainability and understandability. Code without tests is hard to change with confidence.

On visual regression testing:

Visual regression testing tells you that something has changed. The tests themselves do not describe how we expect the system to behave. When a test fails, we still have to interpret the visual diffs to identify both what the expected layout is, and how our implementation differs from it. It’s really a more consistent, sensitive and faster version of manual cross-browser testing.