Earlier today a new design for Elezea went live. This is about the 5th or 6th redesign since I started the site, but it’s the first one that I think deserves a moment to stop and reflect a bit. With this redesign, I feel like the site finally grew up to become what it always wanted to be. I try to stay away from meta posts because I understand they’re mostly interesting to me, and no one else, but I trust you’ll forgive me for doing it just this once.

I had two major goals with this redesign:

• To have a design that’s completely focused on the reading experience.
• To improve site speed and performance dramatically.

With these two goals in mind, I asked my friend Alex Maughan to help me with designing and building a custom WordPress theme to accomplish these goals. He did an absolutely stellar job, and I can’t thank him enough. This design makes me happy. Thank you, Alex.

But let’s talk a little bit about each goal.

A design focused on reading

There is one single thought that became the driving force for what I wanted to accomplish with this design, and that’s Jeffrey Zeldman’s quote from 1999 (I’m afraid the original post doesn’t exist on Adobe’s site any more, so I’ll have to link to Zeldman’s discussion of it):

Most of all, I worry about web users. Because, after ten-plus years of commercial web development, they still have a tough time finding what they’re looking for, and they still wonder why it’s so damned unpleasant to read text on the web — which is what most of them do when they’re online.

I discussed this issue in detail in an earlier post called Please let this not be the future of reading on the web, so I won’t rehash everything again here, except to say - yes, it’s damned unpleasant to read text on the web.

And yet, that’s (finally) changing as more and more sites strip away all the fluff - and make their sites responsive. Speaking of Zeldman, his own site is a very interesting experiment to try to rectify this issue. Other sites that are doing a great job at providing good reading experiences include Contents Magazine, the iA blog, and Marco Arment’s blog. So I wanted a site that provides an enjoyable reading experience, regardless of device or situation. With that in mind, here are some of the reasons behind the design decisions we made:

• A header that explains what the site is about (set the context), then gets out of the way once you start reading.
• A typeface that’s elegant and focused on readability - we decided to go with Adobe Garamond Pro. (Yes, Typography Is The Foundation Of Web Design)
• A color scheme that not only fits the logo, but also feels similar to the calming Sepia schemes that many reading apps (like Amazon Kindle and Instapaper) provide natively.
• A sidebar that sits off to the right - not in your face, but there if you need it - and is focused on what I consider the main calls to action on the site: subscribing to article updates. Everything else is secondary, as it should be.
• My favorite feature: a responsive design that scales down well to small screens, to ensure a consistently pleasant reading experience on all devices. No matter how prevalent responsive design becomes, I think I’ll always see it as a kind of magic.
• And finally, there’s an appropriate space for one of the well-designed ads from the User Experience Ad Pack. These ads are not only relevant to the stuff I write about, it also covers my hosting costs. I recently switched to the more expensive (but much more reliable) mediatemple, and I’m very happy so far.

The end result is, I hope, a site that’s focused on words, ideas, and readers. As it should be.

Improved performance

In a recent post I said the following:

I often wish I could move all my link-sharing off Twitter and onto this site, but I know that’s not really possible, because the readership isn’t quite there yet. But I much prefer not just tweeting a link, but also adding some thoughts, or even just trying to set the context so people can decide if it’s a link they would be interested in, or not.

I mentioned this to Alex, and said that if we can get the site to be extremely fast, I might be able to start moving all my link sharing here. He saw that as a challenge, and went to work… So what we have now is the following:

• The site is now only a fraction of the size it used to be. It should also have faster server response times from a PHP processing and DB query point of view, as there is much less server side processing required to generate the site.
• W3 Total Cache handles all the site’s caching.
• I use Amazon Cloudfront as CDN.
• I also run CloudFlare on top of everything, and I’m really happy with that service so far.

Ok, I think I’ve rambled on long enough. The TL;DR of this whole post is this. I’m really excited about this design, I hope you like it, and thank you Alex!

Angela Baldonero in Just Say No:

We’ve all seen the all-important and all-knowing executive team. The team that has all the answers and yet isn’t able to execute. I’ve seen too many executive teams where personal relationships and politics are the real business drivers behind-the-scenes. Business is done over cocktails, after hours and not in broad daylight. Personal agendas trump team goals. People smile and nod politely in meetings, then leave the meeting and corner the CEO to say what they “really think.”

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”1.

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.

---

1. Ok, maybe I just hang out with really weird people. ↩

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.