Links and articles about technology, design, and sociology. Written by Rian van der Merwe. Follow @RianVDM
Richard Seroter’s 10 Architecture Tips From “The Timeless Way of Building” is highly relevant to software development as well:
“Each building when it is first built, is an attempt to make a self-maintaining whole configuration … But our predictions are invariably wrong … It is therefore necessary to keep changing the buildings, according to the real events which actually happen there.” (p. 479-480) The last portion of the book drives home that fact that no building (software application) is ever perfect. We shouldn’t look down on “repair” but instead see it as a way to continually mature what we’ve built and apply what we’ve learned along they way.
Just as buildings need “repair”, software takes iteration to get right.
This is pretty fantastic. The new Sonos logo pulses like sound waves when you scroll up and down. Brand New comments:
There is no doubt this is a party.
Designed by Bruce Mau Design.
Melissa Dahl talked to some people to find out Why You Keep Mishearing That Taylor Swift Lyric:
“There’s a piece of what we understand that comes from the sound that comes in our ear,” but another piece of our understanding comes from our minds — from our expectations, in other words. It’s easy to see how this explanation applies to many misheard lyrics, specifically the most-often cited one from Jimi Hendrix’s “Purple Haze,” which contains the lyrics “Excuse me while I kiss the sky”; people often mishear that line as “Excuse me while I kiss this guy.” It makes sense: People are more accustomed to hearing someone talking about kissing some guy, less so the entire sky.
I recently realized that the web services I love and use the most are all run by indie developers or small companies. While I ponder what that means, I thought I’d do my little part to tell you about them in case you’re in the market for one of these things.
These are all services I’ve used for a while and have no intention of leaving. Unless they shut down. PLEASE SUPPORT THEM SO THEY DON’T SHUT DOWN.
- I use Feedbin as my back-end for RSS reading. It’s solid. It always updates fast, it never goes down, and it works with a pretty much any RSS reader you can think of. I tried Feedly, but it’s not for me. Too many gimmicks I don’t need.
- Speaking of which, I use Reeder as my front end for RSS reading. Beautiful UI, great integration with services.
- Anyone who’s paying attention knows that Feedburner is on its way out. So a while ago I moved my site’s RSS feed hosting to Feedblitz. It’s not worth linking to them — it was a terrible mistake. Shady “growth hacking” marketing techniques, impossible to work with on support issues, etc. Don’t do it. I have since switched to FeedPress and I’m really happy with it. I do think there’s still a gap in the market for a really good Feedburner replacement, but Feedpress does an admirable job for now.
- Pinboard is still the backbone of everything I do online. It’s basically my external memory. I don’t know how I would internet without it.
- Instapaper is not a one-person band any more, but it’s still my “read later” service of choice. I dabbled in Pocket for a while, but I keep coming back to Instapaper for the no-nonsense UI and focus on typography.
- When it comes to writing, my favorite tools remain MarsEdit (blog writing and editing), nvALT (text editor), and Marked 2 (Markdown viewer).
I really hope these developers continue to make enough money to focus on these fantastic projects. I also hope they know how many people they’re helping every day with the things they dream up. Thank you, to all of you.
Laura Sydell tells a great story in At 90, She’s Designing Tech For Aging Boomers (but when did NPR decide to go all Upworthy-like with their headlines?):
Addi says when Beskind is in a room, young designers do think differently. For example, Addi says IDEO is working with a Japanese company on glasses to replace bifocals. With a simple hand gesture, the glasses will turn from the farsighted prescription to the nearsighted one.
Initially, the designers wanted to put small changeable batteries in the new glasses. Beskind pointed out to them that old fingers are not that nimble.
“It really caused the design team to reflect,” Addi says. They realized they could design the glasses in a way that avoided the battery problem. “Maybe it’s just a USB connection. Are there ways that we can think about this differently?”
We need so much more diversity in the design community — not just in terms of gender and race, but age as well. Here’s a story that proves how valuable design diversity really is.
Jason Z. Resnikoff’s Seeing the Sixties and Seventies Through 2001 and Alien is a wonderful essay about his father’s experiences as a computer scientist growing up in the era of 2001: A Space Odyssey and Alien. Here’s a taste:
My father was so buried in computers that when he saw 2001 he very much liked HAL, the spaceship Discovery’s villainous central computer. To this day, he enjoys quoting the part of the movie where HAL tries to explain away his own mistake—the supposed fault in the AE35 unit—by saying, “This kind of thing has cropped up before, and it has always been due, to human error,” an excuse that more or less sums up my father’s considerably erudite understanding of computers. According to my father’s interpretation of the film, HAL wanted to become something more than he was. Becoming, always and ever becoming, is in my father’s eyes a worthy, nay, a noble way to go through life, always trying finally to be yourself, that most elusive of goals. The mission to Jupiter was a mission to take the next step in evolution, and HAL wanted to be the one to evolve. My father made this sound like a very reasonable desire, one that makes HAL the hero of the movie.
It’s a story about two iconic movies, but also about how we used to see the future. Turns out we won’t be space babies after all.
So I guess it’s quarterly “Designers should learn to code” day on Twitter. This appears to be the crux:
Good discussion today w/ friends who are "designers that code." It's no longer even a question of "Should designers learn to code?"— Nathan Smith (@nathansmith) January 20, 2015
Because that ship has sailed. It's more like… If you're a designer that doesn't code, you'll just be left behind. Not even a debate anymore.— Nathan Smith (@nathansmith) January 20, 2015
I have two questions.
1. What is a “designer”?
I don’t mean that in the metaphorical sense. I mean literally, how do you define design in this context? Is it visual design? User experience design? Product design? Content strategy, or any or all of the other things that make up well-rounded design?
Because here are the things I’m currently trying to get better at by reading books and practicing and writing and working it into projects:
- Usability testing and ethnography
- Information architecture across multi-platform experiences
- iOS native app design
I’m a little busy right now, so I’d like to know: which of these things should I drop to learn to code?
2. What does “left behind” mean?
Does it mean designers who don’t code won’t get hired in The Future? I don’t know about that. I spend a lot of time with designers. Some of them code, some don’t. Those who don’t specialize in something else that those who code aren’t good at, and that makes for stronger teams where work can be distributed more evenly and more effectively.
Let me put this another way: once every designer can code (since it’s “not even a debate any more”), who’s going to make sure we build the right things? Who’s going to discover user needs, create IAs that work for target personas, and design scalable holistic systems that work across devices and contexts?
What I mean to say is this:
- Heaven help us if we become a community of executors at the expense of all the planners out there. We need both.
- It’s really, really dangerous to tell people they’ll be “left behind” if they don’t become part of a homogenous group of people all focused on the same thing. That has never worked out well for anyone, in the history of mankind.
So go forth, follow the design thing you’re most interested in. If that’s coding, awesome. If it’s how to best understand user needs and translate that into design systems, go do that. As long as you do it well, you won’t be left behind.
The Economist tries to answer the question Why is everyone so busy? and it doesn’t tell a pretty story about ourselves. It starts with the economics of it:
When people are paid more to work, they tend to work longer hours, because working becomes a more profitable use of time. So the rising value of work time puts pressure on all time. Leisure time starts to seem more stressful, as people feel compelled to use it wisely or not at all.
This part makes us sound like terrible human beings, but it’s hard to disagree with:
The explosion of available goods has only made time feel more crunched, as the struggle to choose what to buy or watch or eat or do raises the opportunity cost of leisure (ie, choosing one thing comes at the expense of choosing another) and contributes to feelings of stress. The endless possibilities afforded by a simple internet connection boggle the mind. When there are so many ways to fill one’s time, it is only natural to crave more of it. And pleasures always feel fleeting.
And of course we tell ourselves that one day it will be different:
Writing in the first century, Seneca was startled by how little people seemed to value their lives as they were living them—how busy, terribly busy, everyone seemed to be, mortal in their fears, immortal in their desires and wasteful of their time. He noticed how even wealthy people hustled their lives along, ruing their fortune, anticipating a time in the future when they would rest. “People are frugal in guarding their personal property; but as soon as it comes to squandering time they are most wasteful of the one thing in which it is right to be stingy,” he observed in “On the Shortness of Life”, perhaps the very first time-management self-help book.
This is a long article and I know you’re busy, but try to make time for it…
The core challenge with remote work is not how it is defined right here and now. In fact that is often very easy. It usually only takes a single in person meeting to define how things should be split up. Then the collaboration tools can help to nurture the work and project. It is often the case that this work is very successful for the initial run of the project. The challenge is not the short term, but what happens next. […]
If I had to sum up all of these in one challenge, it is that however you find you can divide the work across geography at a point in time, it simply isn’t sustainable. The very model you use to keep work geographically efficient are globally sub-optimal for the evolution of your code. It is a constraint that creates unnecessary tradeoffs.
Projects often start off ok, but then start to unravel as every small miscommunication and missed messages add up to a much bigger problem. I find this stuff fascinating not just because I work at Jive (where we don’t use email at all), but because we’re seeing such an explosion of remote work everywhere as our tools keep getting better and better.
Steph Yiu’s post Still figuring it out: communicating remotely with lots of people is another good one to read, since she walks through all the tools they use to get their work done. Our setup at Jive is very similar, except that we use our own tool where they use P2 (their WordPress intranet theme).
Adam Greenfield reminds us that the “smartness” of technologies comes from the people who use it, not the technology itself. From The smartest cities rely on citizen cunning and unglamorous technology:
It’s simply that in both these cases, the sustaining interactivity was for the most part founded on the use of mature technologies, long deglamorised and long settled into what the technology-consulting practice Gartner refers to as the “trough of disillusionment”.
The true enablers of participation turn out to be nothing more exciting than cheap commodity devices, reliable access to sufficiently high-bandwidth connectivity, and generic cloud services. These implications should be carefully mulled over by developers, those responsible for crafting municipal and national policy, and funding bodies in the philanthropic sector.
I like the term “deglamorised” very much. It’s a reminder that our goal as designers isn’t to make cool stuff—it’s to help people do great things with the stuff me make.