Closer To The Ideal

Obviously I’m biased, since I’m trying to do a start-up in New York, but everything about this rings true:

Tumblr and Posterous are the two most prominent “tumblogging” sites, i.e. sites that make blogging more straightforward by making it easier to post media. Both were launched within six months. (Actually, Posterous was started later than Tumblr.)

But now Tumblr has been an Alexa Top 100 site for a while and is still growing strong. Meanwhile Posterous has about 4 times less uniques. Yet Posterous has everything to win: it’s a Y Combinator company with top-tier investors like Chris Sacca and Mitch Kapor. Its founders are experienced software engineers with computer science degrees from Stanford. How come it’s eating dust from a small startup started by a high school dropout?

The answer is as easy as it is counter-intuitive: Tumblr is a New York company and Posterous is a Silicon Valley company.

Or, to put it another way: Posterous is an engineered product, while Tumblr is a designed product.

Posterous is extremely well engineered. There’s nothing wrong with it. Every single thing about it is well thought out. But it’s not just that it’s less pretty (though it is). It’s just not designed as well as Tumblr is.

…In fact, everything about Posterous is nice. It’s very nice. I’m not here to bash Posterous, I think it’s a tremendous product and I wish them the best of luck.

But everything about Tumblr is better designed. I used the landing page as one example, but there are tons of features where Tumblr shines by its gorgeous design.

Meanwhile Posterous is typical of the Silicon Valley engineering mindset where everything is measured, ranked, weighted. It’s like Google. And having terrible design like Google is great if you have a technology edge. But if you’re in a market where what matters is design edge, that’s not enough. There needs to be great design, by which I don’t mean looks (though they’re important), but how it works for the end user.

…The first is that New York has truly come of age as a startup hub, with its own “style”, its own way of doing things, its own mindset, which can sometimes — not always, but sometimes — kick Silicon Valley’s ass.

Richard Ankrom’s art is also an example of the power of direct action to fix social problems.

An artist named Richard Ankrom had the same experience, and so he did what any fed-up Los Angeles driver would do: He began designing a simple directional tool to help drivers prepare for the 5’s poorly-marked, hairpin exit. He designed and sewed a Caltrans uniform, cut the shield-like “5″ shape as well as a “NORTH” from sheet metal, and affixed the reflectors to match the existing system. He even gave the signage a nice dusting of L.A. smog-sheen so it wouldn’t look glaringly new. And on August 5, 2001, in broad daylight, he hoisted a ladder onto Gantry 21300, walked onto a catwalk above one of the city’s busiest arteries, and installed his own freeway sign. This collage of six time-lapsed photos shows how he did it. There are more on Ankrom’s site.

Maybe Angelenos really are too busy text messaging against the steering wheel and applying mascara with the help of the visor mirror to truly pay attention to the view out their windshields. And perhaps we do have a bit of a bureaucracy problem with our state government. Either way, no one noticed it for nine months.

Ankrom eventually leaked the story to the Downtown News, stunning millions of duped commuters, and effectively coming clean to Caltrans. But Caltrans knew Ankrom was right. For eight years, the sign remained. Christopher Knight reviewed it for the Los Angeles Times as if it was a public art piece. A video and an exhibition were created of Ankrom’s work, and he was featured on pretty much every news outlet you could imagine, from local to international. And every time I saw the hand-applied NORTH 5, I felt like the ultimate L.A.-insider for knowing the story behind it.

To me, it was Los Angeles’s Single Greatest Secret—and it became my single favorite L.A. thing to share with people. Most people who lived here had never heard the tale, so like a cultural ambassador, I felt it was my duty to tell them. I worked it into a review I wrote for Print Magazine about a book on effective wayfinding systems. When giving people directions I would point it out like a landmark. (”Be sure to look at the sign as you’re heading north on the 110…no, no don’t go north on the 5, look at the sign.”) Anyone lucky enough to be in a car with me while heading northbound on the 110 would get the full narrative, which I had timed perfectly to a grand reveal as we sailed under the glittery, counterfeit characters.

Edward Tufte has argued that graphics should be information rich. A good graphic is one that people can spend 10 minutes exploring. If you ever go to one of Tufte’s workshops, he ambushes the audience with a graph that shows the history of Rock and Roll, which artists did what albums when. The room falls silent as people start looking at what music came out when they were a certain age.

“Do you hear that?” says Tufte. “Do you hear that silence? That is what you want whenever you present a graphic to a live audience. It means the graphic is genuinely interesting.”

Tufte is deeply critical of the newspapers. His books are full of horrendous examples of bad graphs that the newspapers publish.

To give credit where credit is due, the New York Times published a fantastic graph the other day, “The Unemployment Rate For People Like You“. This a graph that you can spend several minutes exploring, thinking about people who are similar to you, and people who are different.

Someone I’m working with asked me to look at SlideRocket, to see if we should be using it. SlideRocket describes themselves like this:

SlideRocket is online presentation software that provides for every part of the presentation lifecycle. SlideRocket integrates flexible authoring, intelligent asset management, secure delivery and analytics tools in a single on demand application. SlideRocket allows you to quickly create stunning presentations, store, organize, tag and search your assets, collaborate with your colleagues, securely share your presentations in person or online and measure the results, all in one integrated environment.

If you listen to their video, they talk about how great it is to have all of your assets on the web (or the “cloud”, as they prefer to say), so you’ll never run the risk of forgetting it at home.

One thing that occurs to me is how similar this is to what Phillip Greenspun was describing in 1999:

Interesting things can happen when you do something as simple as move an application from the desktop to a server. For example, at a small company once we had the idea of building a server-based replacement for PowerPoint. We wanted something simpler that we could edit from any Web browser. Once the slides were in the database, however, we realized that this could be used for collaboration. User A could authorize User B to edit a presentation and the two of them could authorize User C to give that presentation at a remote site.

Only after talking to people from PowerPoint-oriented organizations did we realize how revolutionary the system, which we called “WimpyPoint”, could be. Suppose Jane Executive went on vacation for three weeks. Upon her return she wouldn’t have to start calling colleagues to find out what had been going on; she could look at the WimpyPoint server and ask to see all presentations created within the last three weeks. When all the work of an organization is presented within PowerPoint it is a terrible waste to have that work locked up in monolithic files.

Once again, I am impressed with how clearly Phillip Greenspun understood the Internet, earlier than most other people did. He foresaw the declining importance of desktop apps:

What people need and, with the ubiquitous Internet, can finally get, are collaborative Web-based applications. Web-based apps let people use computers without becoming mired in system administration. Web-based apps help people collaborate. Web-based apps can weave an individual’s contribution into a larger work produced by many people over the decades.

The future is WimpyPoint, not PowerPoint.

If Web-based apps are so great, why aren’t we all using them now? Desktop apps serve one user at a time and tend to be copies of systems from the ’60s and ’70s. Web-based apps serve thousands of users simultaneously and oftentimes are based on completely new service ideas. Thus Web-based apps require programmers with great skill, imagination, and taste.

If Greenspun’s thinking has a fatal flaw, it is the relentless way he discounts the importance of visual information. He is one of those people who has a strong preference for text. There is nothing wrong with that, of course, but he consistently mistakes his personal preference for some kind of universal truth about communicating information:

You’re building a database. You’re modelling data from the real world. You’re going to have to write computer programs in a formal language. You have to design a user interface for that computer program. If you had an MBA then your natural first step would be . . . hire a graphic designer. After all, this computer stuff is confusing. Databases frighten you. What you really need is something that will look good at your next meeting. Graphic designers make pages that look good. You can always hire a programmer later to actually make the forms work.

…If you despair of learning how to do anything productive, what you might have learned from this chapter is that you should work with the programmer and user interface designer to build the site that fits your publishing model before bringing in a graphic designer to make it pretty.

This particular joke (that all graphic designers are stupid) pervades Greenspun’s work. I find it about as funny as I find “All women are dumb” or “All blacks are lazy” type of jokes. The history of innovation reveals this as a reliable pattern: those who understand the importance of a new technology often have some blindspot that keeps them from being the one who fulfills the potential of the new invention.

What Greenspun offered is an example of extreme minimalist design. It is functional, but confusing. He seems to have thought that if a page was minimalist enough then its purpose would automatically be clear. Any talented designer can explain the problems with that kind of reasoning.

SlideRocket offers some things that were less practical back in the 90s. The spread of broadband Internet connections allows people nowadays to expect video and other rich media. This could be described as the Web 2.0 version of WimpyPoint, but I assume Greenspun would disagree with the comparison. SlideRocket is built using Flash/Flex/Air. Greenspun was extremely critical of Flash. I assume he has been surprised (as I was) to see Flash evolve into Flex, which is, after all, a reasonably solid programming environment.

Still, SlideRocket strikes me as the modern version of what Greenspun had begun to see 10 years ago: the movement of presentation software to the web. I think it is curious how certain ideas (forums, email, chat) keep getting re-invented, over and over again, every few years, and yet, these re-inventions keep offering some real (if incremental) innovation, something that updates the basic idea and brings it into conformance with all that is now known, all the best practices that our growing experience with this new medium allows us to understand.

I’ve had the good fortune to work with some truly great designers. These are people who are understand the client’s needs, who understand the users, and who naturally develop web sites that feel intuitive to the people who use the site. Long ago I learned that, when working with such designers, it was important to empower them with the code they needed, but to otherwise stay out of the way. In particular, such designers need access to the HTML of the site. When I hide the HTML away inside of PHP functions, I’m limiting the ability of these maestros to perform.

This has implications when working with a framework like Symfony.

A lot of computer programmers would add an image to a Symfony template by using one of the image helpers:

<?php echo image_tag(’banner.jpg’) ?>

But what if the designer needs to add a CSS class to this? What if they are working late at night, and they are unable to reach me? Or they are working in the middle of the day, but it is a day I’m spending away from my computer?

The designers I work with can read PHP code fairly well. And they can look up the image_tag helper and figure out its syntax. But this is a big waste of their time. It takes them further into the world of programming than they should need to go.

When creating URLs in a Symfony project, it is important to use helpers. The helpers take care of figuring out what the right URL should be for things like images. The helpers allow us to develop on one machine and deploy to another server when we go live, and even if that other server has a completely different directory structure, we don’t need to change any links, because the helpers take care of all that for us. However, managing the URLs is the only thing that the helpers should do.

So we do not do this:

<?php echo image_tag(’banner.jpg’) ?>

Instead we either do this:

<img src=”<?php echo $sf_request->getRelativeUrlRoot() ?>/images/banner.jpg” />

or we do this:

<?php sfLoader::loadHelpers(array(’Url’)); ?>
<img src=”<?php echo public_path(’banner.jpg’) ?>” />

This way the URL is managed by Symfony’s helpers, but the rest of the IMG tag is still free for the designers to work with. If a designer needs to add a CSS class, they don’t need to call me on the phone and get me to do it, and they don’t have to start researching Symfony helper tags, instead they just add the CSS class like they always have:

<img class=”header” src=”<?php echo public_path(’banner.jpg’) ?>” />

This is an important bit of project management. It allows for a correct separation of concerns – the designers get to focus on design, and the programmers can focus on the programming.

One of the tough calls to make, when managing a project, is figuring out how much time should be devoted to talking things over. If you are the manager, there are two mistakes that you might make:

1.) You cut off conversation too soon, before the designer has had a chance to defend their idea, or before the client has had a chance to fully articulate their dissatisfaction, or before your programmer can explain why one option would take more time, and therefore more money. You force a decision to be made before all the facts are in. Possibly you kill the conversation just as people are warming up to what would be a brilliantly creative set of insights, if only you allowed more time.

2.) You allow the conversation to go on too long. After awhile, people begin to repeat the same points they made 4 hours before, or perhaps the day before. Your team begins to fear these conversations, which seem to be endless swamps of unproductive debate. The team craves action, decisions, movement, they want to finally be building something, but instead you keep pushing for more information, another round of opinion gathering.

It is difficult to find the right balance. I suspect we all have our preferences about what we consider the right level of conversation versus action.

Over at 37 Signals they’ve posted an extended chat that Jason Fried and Ryan Singer had about adding a new feature to Basecamp. It is useful to see how such a well known and successful team works through their design issues.

(14:42:41) Jason Fried: What are some of the pushback points we’re anticipating?
(14:43:02) Ryan Singer: “i use milestone attachments for [some crazy custom reason] and this doesn’t apply to me”
(14:43:30) Ryan Singer: possibly: “i want dates on my to-do items, not the lists themselves”
(14:44:12) Ryan Singer: i don’t think the first point is a problem
(14:44:18) Ryan Singer: there are always people who bend the interpretation
(14:44:51) Jason Fried: What if the date thing said “On or before March 14”
(14:44:59) Jason Fried: I think the ridigness of it may be a problem.
(14:45:03) Jason Fried: And this could soften that a bit
(14:45:05) Ryan Singer: a bit long, but i like that idea
(14:45:52) Ryan Singer: hm kinda long
(14:46:08) Ryan Singer: becomes harder to interpret too

I know that in such conversations I tend to defer to the designer, and I tend to want to reach a conclusion quickly. Probably because I’ve been in so many, many meetings where someone else forced the conversation to go on for many more hours than was needed, I tend to play the role of the person who is willing to reach a quick agreement. Ryan Singer reminds me of myself, in this portion of the chat, where he seems willing to go along with the “Due by” language, even though he initially disliked it. He seems eager to reach a final agreement.

(14:46:35) Jason Fried: After seeing this the issue I have is the rigidity of it.
(14:46:42) Jason Fried: This list IS DUE on this date
(14:46:45) Jason Fried: Well, not really
(14:46:57) Jason Fried: It’s part of a milestone that is due on this date.
(14:47:07) Jason Fried: So I’d like to see if we can figure out how to present that reality a bit better
(14:47:15) Ryan Singer: good point
(14:47:18) Ryan Singer: ok
(14:47:41) Jason Fried: how about
(14:47:47) Jason Fried: “Due by 14 February”
(14:47:49) Ryan Singer: “Milestone: 14 February”
(14:48:03) Ryan Singer: nice that Due by is shorter
(14:48:05) Jason Fried: Milestone may work. Ties it into the feature.
(14:48:07) Ryan Singer: shorter is better for this flag
(14:48:12) Ryan Singer: even “Milestone: 10 Feburary” is quite long
(14:48:13) Jason Fried: Due by is less rigid than “Due on”
(14:48:15) Ryan Singer: doesn’t hold together as well
(14:48:16) Ryan Singer: yeah
(14:48:37) Ryan Singer: Due by looks pretty good. screenshot coming

But Jason Fried won’t be rushed into a decision. Instead, he keeps the conversation going, even though Ryan Singer was willing to go along with “Due on”.

(14:55:14) Jason Fried: Due is good, but it’s an opinion 5 years after the fact.
(14:55:20) Jason Fried: That’s why I’m pushing back a bit.
(14:55:30) Jason Fried: We’re not introducing attachments today
(14:55:37) Jason Fried: If we were I’d feel better about it.
(14:56:15) Ryan Singer: i think if we don’t go with “Due..”
(14:56:26) Ryan Singer: it would be better to explore moving the link below the title into the list description area
(14:56:30) Ryan Singer: and actually naming the milestone or something
(14:56:41) Jason Fried: right like…
(14:56:54) Ryan Singer: like “For Ship v1 of the Home Page, 14 Feburary”
(14:56:57) Jason Fried: “This to-do list is attached to a “milestone name” which is due on 14 Feb”
(14:57:23) Jason Fried: I feel like we don’t lose anything with that direction.
(14:57:27) Jason Fried: And we gain clarity

If you read the whole transcript, you can tell these two are getting warmed up as the conversation continues – they are thinking hard about this problem, and they are getting deeper and deeper into the nuances. I relate to this chat quite a bit, as it reminds me of so many of the more productive meetings I’ve been in.

Finally, an hour goes by, and Jason Fried keeps pushing them until they arrive at what they both agree is the perfect answer:

(15:20:08) Jason Fried: In the app we say “Attach to…” so I wonder if we should repeat that here.
(15:20:18) Ryan Singer: i would rather change the language in the other places
(15:20:23) Ryan Singer: “Attached to” looks weird here
(15:20:28) Ryan Singer: and it doesn’t fit with the normal expectations of what an “attachment” is
(15:20:36) Jason Fried: K. We don’t want to change the language elsewhere so we’ll consider that one a no go.
(15:20:39) Jason Fried: Umm…
(15:20:46) Jason Fried: “Related to” works for me.
(15:20:47) Jason Fried: Cause it is.
(15:20:51) Ryan Singer: actually the edit dialog says this:
(15:20:55) Ryan Singer: “Does this list relate to a milestone?”
(15:20:58) Jason Fried: Perfect
(15:20:59) Jason Fried: Done
(15:21:02) Ryan Singer: done

A very interesting post by I Am El Gringo:

For the time-constrained, I submit to you the results of my highly scientific research:

• Yahoo: Minimal Use of tables. I found a picture of Hugh Downs horizontally aligned with it’s caption in a table
• Google Home Page: Not only does Google use tables for it’s iconic home page, it embeds styling in the <td> tags. The horror.
• YouTube: Uses tables for of layout of videos
• Windows Live: Uses tables for footer layout
• MSN: There is one table, but it’s only for stockquotes which is tabular data
• MySpace Semantically pure. MySpace. Whoda thunk it
• Facebook: Does form layout with tables
• Blogger: No tables anywhere on the front page
• Orkut All tables all the time
• Rapidshare: A table with a single <td> for header placement. And again a single <td> table for the central “browse” section. Tsk tsk
• Microsoft: Navigation bar is a table. What did you expect? Unicorns and rainbows?
• Google India: It’s the same Google layout. I wonder if they used copy and paste for the template?
• Ebay: Tables, tables every where
• Hi5: Tables for every thing, pretty much. BTW, I didn’t even know this site existed until last week. Alexa rank 14!?
• Photobucket: Tables for photo gallery layout
• AOL: AOL’s layout is semantically pure! Friggin AOL?
• Google UK: Same GOOG layout. I’m now sure the copied an pasted their html
• Amazon: Now that’s just silly
• IMDB: They used tables for their 3 column layout. What! No CSS framework?
• Imageshack: Semantically pure as the driven snow.
• Finally, even though it’s not on Alexa’s top 20, log in to your Gmail account and look at
  the use of tables

My Hypothesis: Pure CSS design == overcompensation

So, the five companies that use CSS are the web powerhouses–MSN, MySpace, Blogger, AOL and Imageshack. MSN, MySpace and AOL have been maligned for years throughout the web savvy community. My hypothesis is that these companies are overcompensating for the crap that they’ve taken thoughtout the years by designing their site in pure CSS.

Other companies that have more web street-cred like Google and Facebook don’t really have to worry about how the web design community sees them. This leads to things like Google making extensive use of inline styling on their homepage instead of putting it in their stylesheet. I’ve never heard anyone claim that the Google folks are slouches at the web design/development thing. Why is that?

I had to look this up and it was harder to find this image than I thought it would be, so I figured I might as well share. A real masterpiece of the power of graphic design to mediate personal or political disputes. In this concert poster from 1965, it was important that neither Joan Baez nor Bob Dylan appear as the featured artist, so Baez’s name appears on the left, but lower, and Dylan’s name appears on the right, but higher. For Western speakers/readers the left comes before the right, but higher comes before lower, so to have visual elements that mix these visual cues is a good way to give both elements equal visual weight.

Does anyone remember the name of the graphic artist who did this poster? I’ve a Joan Baez biography somewhere but it is buried in a box because I recently moved. I need to look the artist’s name at some point.