Faruk At.eş

Archive for 2010

  1. January 19
  2. February 12
  3. March 19
  4. April 24
  5. May 11
  6. June 9
  7. July 7
  8. August 9
  9. September 4
  10. October 1
  11. November 2
  12. December 2

Showing 4 posts from

The Tech Behind the New Twitter.com

I’ve been lucky enough to have had the new Twitter.com experience since day 1, and whilst I’ve mostly ooh’ed and ahh’ed the design (on Twitter, aptly) I’ve been just as blown away by the engineering work that’s been done on it. This great write-up goes into lots of interesting details behind it. (also, I can’t help but be damn proud about the new Twitter using Modernizr, of course)

Design Thinking vs. Data Thinking

Cliff Kuang recently wrote that Google Instant Proves Google's Design Process is Broken, a largely applicable claim if not exactly proven particularly thoroughly in Kuang’s own post. This brought about some discussion at Hacker News—somewhat notorious for not being particularly UI or design oriented—wherein I attempted to explain that good design decisions do not necessarily test well with users. My response was kept simple and focused on only one example, USB, but I have some additional thoughts on the matter which have no place as a comment on some Hacker News thread.

Google’s design process—if you can call it that—revolves entirely around engineering-driven solutions and something I will call “data thinking”: present the problem as a mathematical formula like any other, come up with systematic solutions that attempt to solve the problem and its various “problem components” (think individual UI buttons, copy text, visual design and so forth), then employ testing until a final result is produced. We know this is their process from their own words, but the point was long made clear by Doug Bowman when explaining his departure from Google.

What’s pointedly missing from Google’s approach is the human factor: there is no empathy in the process. It lives or dies entirely by the “sword of data” (Doug’s beautifully apt words, not mine), and while that can be a recipe for success—Google is doing quite well in the market—it is rarely a recipe for beauty, taste or comfort. It’s a cold process, almost entirely devoid of any humanity, precisely because it produces results that lack a human touch. There is no personal identity in the end result, because “data” is not a person. I’m reminded of Star Trek: TNG and its truly literal example of this with the android named Data who starts out so devoid of a human personality it is almost eerie, but I digress.

This lack of empathy and human emotion creates products trademarked by a certain blandness which runs rampant through many of Google’s products. Not all of their products—the Nexus One is an example with a clearly more designed, more human touch to it, for instance—but many of their products nonetheless. But the blandness is not the only negative side-effect from this “data thinking”; it greatly reduces one’s ability to innovate.

Testing is a valuable component of any design process; it identifies problems and shortcomings, helps you tweak aspects towards better performance or usability, and so forth. But testing alone is not a process. It certainly should not be the entire process. Innovative solutions rarely test well—a point also made in Marty Neumeier’s recent talk at d.Construct—because innovation often occurs outside the box. Innovation happens when you step outside of people’s comfort zones, and try something they wouldn’t necessarily have thought of because it’s so different. People don’t always like “different”, and people in large numbers often like “different” even less (see also: politics, the slowness of shifts in society’s stance on topics such as ethnicity or gender discrimination, and so forth).

When relying too much on tests with groups of people, you reduce the chances of a different idea or solution to be accepted. If your design process is entirely testing-driven, you almost eliminate this chance altogether. Take, for example, Google Android. The first versions of the Android platform were tailored to the then-longstanding industry standard for smartphones, featuring a relatively small and horizontal screen atop a hardware keyboard with lots of fiddly tiny buttons. It no doubt tested well in Google’s data-driven test process, because it was familiar to everyone who had used a smartphone before it. It also very poignantly highlights that this test driven process prevented Google from thinking outside of the box, and resulted in a product hardly different from every other product of its kind.

Apple, who very heavily employ the process of Design Thinking, introduced the iPhone—which was as out-of-the-box a product as anyone could have imagined at the time. And what happened to Android as a result, eventually? John Gruber said it best:

The gaping chasm between that Treo-ish/BlackBerry-ish prototype Android device and the HTC G1 that went on sale a year later (let alone the Nexus One today) was bridged by ideas from the iPhone.

Google is perfectly capable of innovation; one must only look at their search engine and its history to see the truth of that. But by 2007, and perhaps even more so today, that sense of innovation has increasingly made way for testing and “data thinking”, a process that stifles truly innovative ideas to the point of fruitlessness, and delivers bland and emotionally vacant products in its stead.

Part of Wikipedia’s definition of Design Thinking reads as follows [emphasis mine]:

[…] the essential ability to combine empathy, creativity and rationality to meet user needs and drive business success.

If Data Thinking were a real term, it would perhaps best be described as “a combination of creativity, rationality and test results.” Of course, any self-important designer will argue that a complete lack of empathy in solving human problems is “inherently irrational”, but I think that Google’s solutions have been perfectly rational in all but an emotional way. Google is, in my eyes, the epitome of Data Thinking not being a necessarily bad process, but rather, a sufficiently capable process to succeed with despite being incomplete.

Data Thinking, I would thus posit, can get you as far as 80% of the way there when making a product or service, and for many people, 80% is enough. For many products and services out there, 80% is better than what there is now. But that last 20%? That final component that makes a product go from “great” to ”truly fantastic”? That takes Design Thinking.

Going for that 80% is not necessarily bad, but your product may well create disagreement and conflict between you and the people that expect or long for the full 100%. You can ignore it or embrace such conflict and let it help you improve your product, but whatever you do, just don’t try to fight it. Design Thinking is here to stay, and always has been.

Twitter, You’re DMing It Wrong

Ever since Twitter for iPhone was recently updated to become a universal app, sporting a shiny new iPad version along its side, one change has caused me a rather incomprehensible amount of frustration, incomprehensible in that I cannot figure out why this change was made. What I’m talking about is the handling of Direct Messages (DMs).

Before, in all of Twitter for iPhone, Tweetie on the Mac (the unofficial Mac desktop companion app to TweetieTwitter for iPhone) and Twitter.com on the Web, Direct Messages employed a simple ordering system: latest DMs were listed at the top, and—in the apps—the DM conversation with the latest message in it was also listed at the top. This was in line perfectly with everything else around Twitter: the stream itself shows the latest tweets at the top, Search shows the latest tweets at the top, and every Twitter client I’ve ever personally used shows the latest tweets and the latest DMs at the top, too.

So why the change? Who knows, really. There’s nothing on the blog about it, so people have come to speculate that it is to simulate the Messages (SMS) app by Apple itself, which shows the latest messages at the bottom instead of at the top. Since Twitter DMs are very similar to SMS and MMS, it stands to reason this may have caused the Twitter team to make this change.

But here’s the rub: there’s a very good reason why the Messages app shows latest messages at the bottom, and that reason does not apply in any way to Twitter for iPhone’s DM experience, nor to Twitter DMs themselves in some inherent way.

Let’s look at the experience with an SMS conversation in Messages: you start out with an empty screen, and as more things are said, the conversation builds from the top down with new items being added to the bottom of the stack:

This is not an arbitrary decision that Apple have made. The very obvious reason for this is when you start typing a new message. As you start typing, the keyboard slides into view from the bottom, pushing the conversation upwards but, because the order is newest-at-the-bottom, you see the latest thing that was said closest to the new thing you are writing. This helps you in composing your new message, but it goes further than that: when you send your message, your composition becomes a new chat balloon that floats itself to the bottom of the conversation, pushing it up a little again. This is both intuitive and natural, producing the least amount of movement on the screen while yielding the maximum results:

Now compare that to Twitter DMs:

There is no conversation. You don’t get to see what was said, and the new message you are composing is aligned at the top of the screen—after which it magically moves to the bottom, with the new Twitter for iPhone update. So one moment, you’re composing your message at the top, and once you send it, that message shows up at the bottom, opposite to your expectations, opposite to how it has worked for the past couple of years, and opposite to how it works in Twitter for iPad and on Twitter.com itself.

The experience therefore feels jarring, much like how, I suspect, the newest-at-the-top ordering would feel jarring if employed in the Messages app.

I'm reminded of something Steve Jobs or Jony Ive once said in an interview: a lot of people copy Apple, but for the wrong reasons. They just copy how it looks or works, but they never did the research and experimenting to understand why it works the way it works. As a result, they have a product that isn’t thought through as well, because they can’t explain the design choices they’ve made.

That's what Twitter for iPhone's DMs feel like to me now: copied from Apple, without understanding why.

In the meantime, there are links

For those who might be waiting on the extended information on product ideas mentioned in my previous post: they’re still coming, but not just yet. Meanwhile, some items of interest:

Sources and/or subjects for some of these items:
@cssquirrel, @fraserspeirs, @gesteves, @jurewitz, @laughingsquid, @McCarron, @sroucheray

Upcoming talks

Here on My own website

Subscribe to this site