Eric Spiegelman writes about the virtue of brevity in email:

Long emails are, more frequently than not, the worst. When you send someone an email, you make a demand on their time. If you use more words than necessary, you waste their time. Sure w’re talking maybe a fraction of a minute, but given the number of emails the average person sends in a day those fractions add up pretty quick.

This makes intuitive sense, and anyone who gets a lot of email would agree. I’ve even tried to adhere to the Five Sentences philosophy for a while — with not much success.

But there’s something in me that wants to resist this move to get rid of all the “fluff” in email. Sure, it makes you less productive if you have to read through a bunch of stuff that’s not relevant — but I wonder if there’s a danger that the way we talk in email will spill over to the way we talk to our friends and family. Just like “LOL” jumped from text messaging and IM to enter our vernacular in all kinds of weird forms like “For the lulz”¹.

Patrick Rhone recently wrote an article called Twalden (it’s worth reading just to discover why he chose that title), where he discusses why he’s taking a break from Twitter:

Ultimately, I don’t know if what Twitter has become is for me, or the people I care about, or the conversations I wish to have. The things I want to know are “happening” — like good news about a friend’s success, or bad news about their relationship, or even just the fact they are eating a sandwich and the conversation around such — I wish to have at length and without distraction. Such conversations remain best when done directly, and there are plenty of existing and better communication methods for that.

The phrase at length and without distraction really stuck with me. When’s the last time you had a discussion at length and without distraction? It seems to become rarer and rarer these days. I’m not trying to draw a causation effect between short, get-to-the-point emails and the general distractedness of our everyday conversations. I’m just saying that it’s probably ok to say “Hi!” and “Thank you” in emails every once in a while, because it’s nice to be nice.

I love Frank Chimero’s explanation of the book design decisions he made for The Shape of Design. From an interview with FontFont:

Many of the design decisions were also influenced by the affordances of ebooks and their readers. The cover was designed to be very iconic so I had a design system which could transition to each reading environment. The page size of the printed book was chosen to be similar in size to what would be experienced on an iPad or Kindle. The illustrations are two-color, because I knew I could make them look good on a Kindle, iPad, and in print.

Basically, I wanted to design a system that was flexible enough to keep its identity intact as the words went from place to place. I think it is possible to craft books in a way so that no reading environment is obviously inferior to another, whether printed book or ebook. Each piece has to shine on all the other parts to make a better whole.

Carina Chocano takes a fascinating look at the neurological component of curation sites in Pinterest, Tumblr and the Trouble With ‘Curation’. It includes my new favorite German word:

If a rat is rewarded for choosing a rectangle over a square, it will learn to respond to “rectangularity” and start to favor rectangles in general. So maybe we are like the rats, and what w’re seeking while idly yet compulsively cruising Pinterest is really just the reliably unpredictable jumble of emotions that their wistful, quirky juxtapositions evoke. Maybe that is our rectangularity.

Ther’s a German word for it, of course: Sehnsucht, which translates as “addictive yearning.” This is, I think, what these sites evoke: the feeling of being addicted to longing for something; specifically being addicted to the feeling that something is missing or incomplete. The point is not the thing that is being longed for, but the feeling of longing for the thing. And that feeling is necessarily ambivalent, combining both positive and negative emotions.

(link via @iamFinch)

Matthew Butterick recently did a TYPO Talk in Berlin that completely blew me away. In Reversing the Tide of Declining Expectations he discusses how we have come to expect way too little from design, with the consequence that most design on the web is complete crap:

And that’s really what I mean tonight by declining expectations. This idea of what happens when we defer to technology, instead of standing on its shoulders. What happens when we choose convenience over quality. Eventually, w’re going to forget what quality was like.

One of the most interesting parts in Matthew’s talk is where he challenges the conventional wisdom that design is about solving problems. He believes that “solving problems is the lowest form of design” — here’s why:

Because what does design want from us, as designers? Does it only want a solved problem? I think it wants more. I think it wants us to take these items that are sort of mundane or boring on their own—like an annual report, or a website shopping cart, or a business card—and it wants us to fill them up. Fill them with ideas, and emotions, and humor, and warmth. Really everything that’s in our hearts and minds. Design wants us to invest these items with our humanity. And the problem that we’re solving—that’s really just the context where that happens.

I don’t want to quote from the talk too much, because you really have to experience the whole thing — it is such a great reminder to have the courage to create better things.

You can watch the video or read the transcript.

(transcript link via @jbrewer)

Michael Lopp discusses Apple’s famous secrecy in the context of the “One More Thing” keynote moments during the Steve Jobs era. As usual, he nails it:

The best stories, the ones we love, have a surprise ending. Since Steve returned to Apple, an essential part of the keynote was the anticipation of the unexpected, and that means aggressive and invasive secrecy. Not because they don’t want you to know, but because they want to tell you a great story.

His point is that “it’s not secrecy, it’s theatre.” Great article.

Michael Mulvey points out an interesting distinction between Microsoft and Apple in Very Soft, his response to the news of Microsoft’s first ever quarterly loss:

The thing is, Microsoft has never been a consumer-focused company to begin with. Windows was designed for businesses, not people. Microsoft got in good early in the enterprise market in the 80’s and 90’s and that trickled down to peoples’ home computers. “I have Windows at the office, I might as well get it for home.” That left Apple out in the cold until Steve Jobs came back in 1998.

Contrast that with:

Windows PC spread from the office to the home. In the past 10 years we’ve seen the opposite: Apple products are going from the home to the office.

This is true. As BYOD (Bring Your Own Device) policies become more prevalent, corporate IT departments are finding that many of those devices are iPhones and iPads, and they just have to find a way to deal with that. It goes even further, because these devices are “gateway drugs” that end in employees dumping Windows PCs in favor of Macs (see How the Editor of Windows Magazine Became an Apple Fanboy for a good example). And before you know it you have a groundswell revolt against Microsoft Office for Mac, and a loud push to switch everything to iWork and Google Docs.

It’s a difficult situation for Microsoft, because the shift is mostly driven by masses of individual contributors — not executives. And it’s a situation that Windows 8 is not guaranteed to fix.

When the news hit that Sparrow has been acquired by Google, you could almost hear the collective sigh from those who use and love this wonderful iOS and Mac OS X email client. Many people (myself included) took to Twitter to voice our disappointment with this move, especially about the fact there there will be no additional development on the app:

We will continue to make available our existing products, and we will provide support and critical updates to our users. However, as w’ll be busy with new projects at Google, we do not plan to release new features for the Sparrow apps.

The response from many others was that we should just get over ourselves:

Sparrow doesn’t owe you anything. You paid, you got software. They can sell and/or kill it if they want. No right to complain. Sad, true.

— Matt Gemmell (@mattgemmell) July 20, 2012

Matt is right, of course — Sparrow doesn’t owe us anything. The Sparrow team did everything right: they had a great idea, they worked hard on it, and they executed well. That’s why Sparrow is a great app that serves a real need, and why it’s so successful. This is how software development should work: make a great product, and sell it to people for money. The Sparrow team deserves enormous credit for doing that.

But the issue is not that we think Sparrow “sold out.” I don’t think any of us would have turned down Google’s offer if we were in their shoes. The Sparrow team deserve their success, and it’s their software — they can do with it whatever they want. It’s also a great strategic move by Google. If the Sparrow team end up making Gmail better, Google wins. If they don’t — well, at least they’ve eliminated a competitor, and they still win.

We need to reframe this argument. The real issue is much deeper than this specific acquisition. The real issue is the sudden vulnerability we feel now that one of our theories about independent app development has failed.

You see, for a long time we’ve chanted this refrain wherever we could: If you’re not paying for it, you’re not the customer; you’re the product being sold. We point to Facebook and Delicious and ad-supported sites and lament the fact that we’re all just a set of eyeballs being sold to advertisers. So we came up with a solution. We decided that we don’t want to be free users any more. We decided that we want to pay independent developers directly so that they can have sustainable businesses and happy lives.

The philosophy is perfectly summed up in Don’t Be A Free User, a great post on the Pinboard blog:

What if a little site you love doesn’t have a business model? Yell at the developers! Explain that you are tired of good projects folding and are willing to pay cash American dollar to prevent that from happening. It doesn’t take prohibitive per-user revenue to put a project in the black. It just requires a number greater than zero. [“¦]

So stop getting caught off guard when your favorite project sells out! “They were getting so popular, why did they have to shut it down?” Because it’s hard to resist a big payday when you are rapidly heading into debt. And because it’s culturally acceptable to leave your user base high and dry if you get a good offer, citing self-inflicted financial hardship.

This is why I am a paid subscriber to services like Pinboard and Instapaper. It’s also why I paid for the both the Mac OS X and iOS versions of Sparrow. I believe in this philosophy. I believe we should pay people for the things they make, so that they can make it even more awesome.

But with Sparrow’s acquisition the cracks in the philosophy starts to appear. Marco Arment (creator of Instapaper) posted his response to the deal in Talent acquisitions:

If you want to keep the software and services around that you enjoy, do what you can to make their businesses successful enough that it’s more attractive to keep running them than to be hired by a big tech company.

But… that’s what I did. I paid full price for every version of the Sparrow app I could find. I told everyone who would listen to buy it. I couldn’t have given them more money even if I wanted to. So, as a customer, what more could I have done to keep them running independently?

This is the core of the disappointment that many of us feel with the Sparrow acquisition. It’s not about the $15 or less we spent on the apps. It’s not about the team’s well-deserved payout. It’s about the loss of faith in a philosophy that we thought was a sustainable way to ensure a healthy future for independent software development, where most innovation happens.

Jon Kolko’s Iteration and Variation is a great article on some of the dangers of iterative design, and how to avoid them. Jon’s main point is that iteration solidifies ideas:

Once this broad stroke has been created (drawn, wireframed, coded, etc), further iterations assume the basic framework as fact. The initial iteration acts as a constraint, and becomes rigid: I’ll refine details and extremities, review and change aspects of the idea, but the idea itself has come to life. […] Each further iteration serves to solidify details, and they become taken for granted: they become facts.

One way to avoid getting stuck on the wrong path is through variation:

Variation is a way of adding a sense of objectivity to design exploration. Variation is an exploration of alternatives. […] Where an iteration moves an idea forward (or backwards), a variation moves an idea left or right, and is not productive in a typical engineering sense: the expectation is that all of the variations (except one) will be rejected. But variations act as provocations for what-if scenarios.

My immediate thought was that even though this approach sounds great, it just won’t fly in most software development processes — especially if the process involves Agile methodologies. Today, Joshua Porter got to the core of why UX and Agile are often difficult to integrate in Is design building interfaces or solving problems?:

But if you view design as “problem solving” then all bets are off. In this case it may take an hour or a week to figure out a solution to a design problem — It depends on the problem and the tenacity of the designer. This makes the initial design phase more unpredictable because your first decent guess is almost always wrong or inelegant (as usability testing often shows). And this makes it more difficult to schedule — and it’s why design doesn’t fit into fixed-time sprints very well.

And that’s the thing. Problem solving involves not just iteration, but also lots of variation. This often requires time to get it wrong a few times, which doesn’t fit comfortably with the concept of release dates. See, the problem with integrating Agile and UX is not that designers want to hang on to “slow and heavy documents,” “big upfront design”, or whatever you want to call it. The problem is that each iteration further solidifies the chosen path, and there is no time to stop and ask if you’re going in the right direction.

This is, of course, where Lean UX comes in:

We are, in this model, not doing research before or after the product is made but throughout the product design and delivery process. While in an Agile UX model, Building is Designing is Building, in a Lean UX model, Building is Research is Building

My biggest concern about this, from a practical point of view, is if it allows for enough leeway to test/research different variations, or if it just streamlines the iteration process to get you to the local maximum faster. I don’t know the answer to that, but all I can say is that I’m glad I’m not the only one struggling with these issues.