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.

Rondam Ramblings advocates generating websites from a programming language, rather than having anyone hand code the HTML:

IMHO, no one should ever write any HTML by hand. HTML should be considered exclusively as object code, except for the most simple of quick-and-dirty hacks. The idea that HTML can (or even should) be considered source code is the root of many evils on the Web. The right way to create web pages is by building higher-order abstractions in a programming language (preferably functional ones, but I’m not dogmatic about that).

Nowhere is this clearer than when it comes to forms. Even CSS advocates concede that it’s OK to put form elements in tables. They say it’s because “forms are a kind of tabular data, and that’s what tables are for”, but this just begs the question of how one can tell if a particular set of data is tabular or not. (Apparently, the criterion is: it’s tabular data if it’s completely hopeless to make it not look like crap when layed out with CSS.) But the trouble with forms goes far beyond layout.

This makes design lead development impossible, assuming that the designer does not know the programming language being used. Rondam wants to make a distinction between the source code that one would write in the C language and the object code that a complier would generate from that source code. Since people do not usually argue over the object code that a compiler generates (no one but a compiler writer should care), then (according to Rondam) no one should care what kind of HTML is generated by the software that you create.

Of course, the assertion that HTML should be the object code generated by a compiler falls apart when you are doing design lead development. With design lead development, there is no question that the HTML is the source code that everything else depends upon.

As to why design lead development is important, there are the old arguments: an experience rich design produces good results with users which makes them enjoy using your service, and therefore they come back to use it more.

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

This sounds like a great service:

2. Upload the image at www.fivesecondtest.com and plug in your email address.

3. Email the URL for the 5-second test (shown on the subsequent page) to anyone willing to give you some quick feedback. If you have a decent amount of followers, post the link to Twitter and/or Facebook and ask for volunteers.

4. Sit back and relax.

When a user clicks the link, she sees a page that explains how the test works and what to do. When she clicks the button to start the test, your uploaded image displays for 5 seconds, then disappears. The user is then asked to enter everything she can remember about the image (via 5 input fields on the next screen). When she clicks “Done”, she sees a Thank You page and an email is sent to you that contains all of her responses.

Once you have replies from a few users, you’ll spot the trends. Are they noticing the most important things in your design? If not, tweak the design and run another test.

Our biggest project of the last 8 months has been The Second Road. This site is built on top of the framework that I started developing back at Category4.com (which they released as open source). We had a big roll-out on May 29th, which we completed and clarified much of the functionality. The site just got a nice write up in the local paper:

Often it is late at night, when there is neither a 12-step meeting to attend nor anyone awake to phone, that the craving for a drink is strongest.

And it is times like these when Ginger Bauler goes online to reach out to others recovering from addiction, finding solace in their tales of success and providing encouragement for those trying to break the shackles of dependency.

Bauler, who used to manage a research laboratory in Charlottesville, writes a blog about her struggles with alcoholism and her quest for sobriety on The Second Road — a new online support community for drug and alcohol addicts started by Charlottesville residents.

Writing about her battles enables Bauler to become “accountable” for her recovery, she says. And meeting and keeping in touch with those dealing with similar experiences gives her strength.

“I develop these relationships with total strangers, but with whom I’m completely connected because of this disease,” said Bauler, who has become a managing editor of the site.

The Second Road is the brainchild of local documentary filmmaker Melissa Shore, who partnered with Chip Ransler, owner of a digital publishing firm, to launch the site in November. By late May the social networking site had 225 members and more than 1,400 different people had visited it in a recent 10-day stretch.

Each member of The Second Road has his or her own profile page, similar to sites such as Facebook and MySpace, where they can post information and display customized features. The site also includes a series of blogs, chat groups, a “sharing wall” for inspirational quotes and testimonial videos from recovering addicts.

Shore, who grew up watching family members battle addictions, noticed that there was a gap in services for people in recovery and a need for round-the-clock services.

People in recovery do not always have access to meetings or counseling services, and some may have no one to turn to in times of crisis, Shore realized. That is especially true in rural communities, where social services either might not be readily available or are far away.

“There are hours of the day when you can’t or don’t feel comfortable reaching out for help,” Shore said. “The beauty of the Internet, of course, is that it’s 24-7.”

The site has won praise from many in the local mental health community as a vital tool to help round out recovery services.

“The concept is absolutely brilliant,” said Jeff Gould, administrator of the Charlottesville/Albemarle Drug Court. “This type of online recovery network is just perfect for people who can’t get to meetings.”

Beth Elliott, a retired social worker who advises the site’s creators, says that members are using The Second Road to implement the treatment plans they develop with counselors, through making lists and blogging about their successes and missteps.

These are articles that I’ve often spoken of, and often copied the URLs to emails that I’ve sent to others, so I shall record them here, so in the future I shall only need to point people here.

The illusion of agreement:

“We should build a house!”

“Yes! A house!”

But what kind of house do they mean?

The interface as a spec: including stories inline:

Sometimes designing the static states takes more time, and doesn’t quite represent reality, as well as a brief note about how the functionality works. The key is to make this note in context — right next to the interface element its describing. The combination of real visuals and a brief contextual note shrink the chances of misunderstanding to near zero.

Designing an interface: from sketch to screen

The screen mostly followed the sketch, except for the controls in the upper right and the description field. That’s fine, because at step two those details Didn’t Matter. Coding the real thing, I found room for all three of those pieces in the top-right, and that worked better.

Thinking and sketching took me 10 minutes. Creating the real screen and updating the code can take two or three hours. That lopsided pattern, with short make-believe-time on the left and long build-time on the right, is always a good sign that you’re making progress. Ideas and paper are necessary, but they’re destined for the trash bin. So burn through them and focus on the good stuff.

Robert Hoekman is the author of Designing the Obvious, which all web application designers should read.

In a recent post he talks about the right way to listen to feedback from one’s users:

I have also long maintained that once you have a product available, you should then plug in and start listening to your audience. In doing this, however, I’ve said you should pay attention to the overwhelming trends – the requests that bubble up to the top over and over again – and not the idiosynracies of individual or small niches of users.

He then quotes a statistic from the Opera web browser development team that shows that a feature that users had frequently requested, and which has been implemented, is never used.

He concludes:

Clearly, even paying attention to trends can be risky. I’ve seen this myself in a couple of situations. It seems that a large number of people can all have the same wrong idea….

Our job as designers is to interpret and define problems, and to create solutions. Very often this means ignoring everything you hear and paying attention only to what you see. When you pay attention to what people actually do instead of what they say they do, you can devise solutions that exceed their expectations.

Instead of building exactly what they ask for, figure out why they’re asking for it. Then find a solution that solves the real problem.

I have occassionally heard designers respond to criticism with the words “I did exactly what you asked me to do” This response, it seems to me, can arise for only two reasons:

1.) The organization for which the designer works has no real respect for design. The designer is not empowered to do actual design work. Instead, the designer is told to follow orders or be fired.

2.) The designer does not understand the actual work of design. The designer needs to spend more time listening to the client/boss so they can figure out the why of a request, rather than the what.

There is no easy fix for #1, which is an epidemic sapping potential economic value out of millions of businesses worldwide. However, for #2, all that is needed is greater design education.

Some fellow posted a commerical notice to the comp.lang.php newsgroup. For a mere $79 per developer, you can get a PHP framework that does all the same stuff as the free, open-source PHP frameworks. And it has all the same problems, too. In an old post on the Category4 weblog I was ranting about the problems that stem from generating HTML from inside of PHP code. When a PHP framework generates HTML and CSS from inside the PHP code, then programmers end up working on problems that designers could solve much faster. Consider this problem, which the PHP Developers Kit offers as an example of all the wonderful things you can do if you use their $79 framework:

The workhorse of PHP Kit is the container class . It is a box containing other objects, like text, links, paragraphs and even other containers. It is under CSS control so you may create a container using several dozen options, like background color, border style, border color, font size and font color.

Note: the containers above displayed correctly in Microsoft IE when displayed inline (left to right). However, Mozilla Firefox version 1.5.0.4 displayed them left to right but with no width or height except for the width of their borders. When displayed as block (one above the other), Mozilla displayed their size correctly. The display property (inline or block) is not suppose to effect an element’s assigned width and height.

So, um, you really should be able to control these containers from your code, but when you run into a problem, such as different browsers interpreting your CSS differently, you (the programmer) are stuck solving it. The designer, who specializes in CSS, can not solve your CSS problem for you, because they don’t know how to edit the PHP code that generates the CSS. Ideally, all CSS issues should be the domain of your designers, not your programmers, but when all the CSS is controlled by PHP code, then solving this problem is shifted from the designers to the programmers. This leads to workflow problems – in too many web design shops the programmers have too much work to do and the designers too little, and frameworks such as this are to blame. This is bad economics – to the extent that your programmers are paid more than your designers you should be trying to shift work from programmers to designers.

Concentrating all of the important design work into the hands of the programmers is also bad for morale – I’ve worked in shops where the designers had no work to do because they were waiting for the programmers to finish a bit of PHP/CSS template code. It is demeaning and embarrassing for the designers to have no work. I’ve seen them try to make busy work for themselves and they always look a little embarrassed and ashamed. A well-run web design shop will strive to avoid this.

Designers are focused on communicating with other humans, programmers are focused on communicating with machines. One’s users and clients suffer when the actual power to design is taken away from designers and given (even accidentally) to programmers. It is a rare programmer whose insight into user behavior matches that of a highly skilled designer. An intuitive sense of the user experience is the most important skill that a good designer brings to their work. If all the real design power is in the hands of the programmers, one’s websites and web software are likely to be less intuitive than what might have otherwise been achieved. By contrast, a framework that maximizes the power of the designers is a framework that maximizes the chances of a great user experience being achieved.

Again, let me repeat (as I said in that previous post), frameworks like this (I mean the one I’m criticizing) are fine for the individual freelancer who does all their own programming and design work. But these frameworks are harmful to web design firms that work on large sites and who, therefore, need programmers and designers to work together. As soon as you have a division of labor, you need a framework that facilitates workflow, rather than blocks it.

The last time I wrote on this issue (back when I still worked at Category4) a fellow named Matt responded:

While I generally agree on your view of no html in your php, I think there are exceptions. It’s really about choosing what for when and where. For example, form elements being generated by code is acceptable to me. Even as a designer, I would think that looking at a page with a few php/template tags would be better than a page with lots of html; it’s still code. Less control, but as long as the code is doing what you want then there is no worry. And you could always either override/extend the classes generating the code or hack it…. I think that my point is that one could continue to mull over what to use and prematurely optimize resources to the point of getting nothing done.

I’ll say again, if an individual is doing both the programming and the designing, then putting HTML into the PHP might speed things up for them, but as soon as the jobs of programmer and designer are split, then anything that robs designers of their power is likely to lead to work-flow problems. And those cost money, time, morale and sometimes management focus. They also limit the ability of the designers to achieve a great user experience. Matt suggests that form code can be generated by PHP code, but if you do that, you will very likely get cookie-cutter forms. Forms are the single most important area for designers to innovate a great user experience, but the ability of designers to innovate is wiped out if the HTML is generated by PHP code.

As to “you could always either override/extend the classes generating the code or hack it”, only a programmer can do this. Designers can’t do this on their own. If the designers need this done, then they need to wait on the programmer to do it. And then, once again, you end up with a work-flow problem that damages the productivity of the firm. Either the firm’s profits will be reduced or the costs must be past along to the client, driving up what they must pay for the project.

As to “one could continue to mull over what to use and prematurely optimize resources to the point of getting nothing done”, I’m sorry I haven’t stressed this, but the opinions I’m expressing have grown up on me slowly over the last 5 years. In 2002 I started work on a PHP/MySql content management system and I made every mistake that I’m now critical of. Back then, I wrote functions to simplify my forms, such as:

textInput(”author”);

All the HTML was in the function. It’s exactly what I’m now critical of. So what I’m expressing in this post isn’t premature optimization. It’s way-overdue optimization. I’m looking back at the mistakes I’ve made over the last 5 years and I’m trying to express what I’ve learned so others might now avoid making the same mistakes I’ve made.

Earlier tonight I found myself writing the following email (one of several) to a designer I’m working with. I was trying to explain why I favored “design lead development”.

Dear wwwwww,

I think another way to think of your job, for the next 3 weeks, is to figure out what assumptions people are making, and draw those assumptions out with Photoshop mock-ups. What are JJJ, MMM, CCC and I assuming? We’re relying on you to attack those assumptions, as much as possible, and make things visually explicit.

I guess another way to approach this is for you to ask, what do you feel ignorant about? What questions would you like to ask about this project? In an ideal world you would never use words to ask any questions, but instead you’d use a Photoshop mock-up to ask every question that you’re curious about. I’m not sure if that is an attainable ideal, but it’s worth keeping in our heads. Ideally you’d speak to us in Photoshop, not English.

Of course, this is merely my opinion. If you disagree with me, I trust your judgement about how to proceed.

– lawrence krubner