Closer To The Ideal

Darren Hoyt has a great post up about designing with social skills:

But interactive design should enable the largest possible audience to accomplish and experience things easily. Visual design snobbishness has to be calibrated for the masses. We know that websites shouldn’t make us think. What I’ve realized now that machines have completely taken over my life is that websites must also have great social skills.

Simply being “usable” isn’t enough, no more than nice cars should be merely “driveable”. Ideally, a website should spark an interesting conversation the moment it loads. It should usher you from page to page, telling great stories along the way. It shouldn’t come on too shy or too strong. It should look sharp without looking vain. No gradients or noise filters can replace social skills, just like an expensive haircut can’t give someone a better personality.

Kind of funny, kind of odd. Darren Hoyt notes a Republican candidate re-using his Obama theme:

Today Geoff Fox tipped me off to something ironic: the website for Republican congressional candidate Daria Novak is using a WordPress theme I designed back in 2008 for Obama supporters. What’s interesting is that soon after Geoff made the observation, Novak’s web team removed all references to Obama from the CSS and templates, even changing the name of the /theme/ directory.

Darren Hoyt has a great write up about Dribble:

Finding intimacy among groups of friends and colleagues online isn’t always about limited numbers. Sometimes it’s just a matter of finding the right people. But once you’ve found an intimate place, how long can it last?

At some point in 2008-2009 everyone I’ve met in my entire 35 years got a Facebook account. Instead of trusted recent friends, my circle expanded to acquaintances from high school. People who I never intended on re-establishing contact were now privy to my every silly status update. I got self-conscious and had to create filters so that certain people didn’t get certain updates. This idea of relationship-filtering will continue being an uncomfortable part of our lives as social media grows.

Currently, Dribbble feels pretty intimate. Among the nearly 1000 members, there are still clusters of friends that form little subgroups. Within your trusted circle, you can be yourself and post private/client work without worrying much about it.

This intimacy is important as many of us designers spend our time maintaining an airtight wall of professionalism on our personal/portfolio sites. We publish only the most pixel-perfect portfolio samples. We still use the royal “we” when describing the work done at our one-man design studios. The web allows us to contrive whatever identity we want for ourselves.

Dribbble is a nice escape. You can be loose and be yourself. It’s more personal. There is no veil of professionalism. Because it is private, people post wacky stuff they might not

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.

I am surprised to see how much corporate brands prefer either red or blue, and not much else.

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.

This is a great article about managing UI complexity:

Progressive disclosure is the most popular means of managing complexity. The idea is that clutter and cognitive overhead can be reduced by hiding less frequently used elements behind some avenue of accessing those elements, like a mouse click or a keyboard shortcut. It requires that the designer accurately determine which elements are frequently and infrequently used and to what degree.

Quite a bit of care needs to be put into the progressive disclosure hierarchy and the mechanisms used for disclosure. Poorly considered use of progressive disclosure can achieve the opposite of the intended effect by making the interface even more complex. As an example, Microsoft Windows has been trending towards removing the menu bar from individual windows and instead packing each function into the main interface (often using pull down menus), which has some issues.

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?

The most concrete way to lower risk, in regards to the creation of websites, is to start small and grow organically. During the design phase, this means you need to adopt an iterative process that demands, with each cycle, the creation of something real.

Boxes and Arrows:

An Iterative Process

While prototyping with XHTML isn’t tied to a specific design process, iterative development seems to effectively leverage its strengths. There are many reasons for this, but perhaps the most significant is that in both cases the prototype, and later the application itself, doubles as a specification. We’ll explore what that means in a bit, but first let’s walk through a suggested process for prototyping with XHTML.Let us start with an overview of the larger design process:In this (iterative) methodology, rather than design the entire application before starting to build it, one designs and builds a unit of the application and then uses what has been built to inform and serve as a starting point for other application units. As with other design methods, the design work begins with sketching, which plays a particularly important role relative to prototyping.

Sketching: A Freeform Question

The term ‘sketching’ refers here to any freeform exploration unconstrained by a specific technology. This includes production of wireframes, which in this model are reframed, as it were, from specification artifact to refined sketch. When thought of, and presented to stakeholders, as sketches, its more natural to discard your wireframes once the design has evolved beyond them. This is usually after a prototype equivalent has been produced. With the design team I work with, we’ve found that when prototyping with XHTML, wireframes often became superfluous, and it’s more effective to go directly from sketch to prototype.

Prototyping: A Concrete Response

Prototyping has a counterpoint relationship to sketching. To paraphrase Bill Buxton, while sketches ask a question—”Is this a good design idea?”— prototypes provide a response. By making the idea manifest, prototypes force upon it the concrete realities and user experience idiosyncrasies of the actual production technology and offer a crisp verdict on the quality of what you dreamed up in drawings.

The Prototype/Build Relationship

When prototyping with XHTML, especially in an iterative model, the build and prototype become very intertwined. If you’re prototyping a new application or product, the XHTML prototype is essentially a rough draft of the actual application. However, when updating the design of an existing application, the production version can serve as the starting point for the prototype of the new solution.

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.

You can set up a website for free. And Google has spent over $10 billion on its website. So it is safe to say that most websites cost between $0 and $10 billion. How much will your site cost? There is no way to be certain ahead of time, but we can offer some advice.

 All websites fall into two categories:

 1.) they offer content

 2.) they offer a service

 Examples: A blog about computers offers content. A site that lets you put dates into a calendar is offering a service. Many of Google’s websites offer a service: email at Gmail and spreadsheets at Google Docs. If you have an already existing company and you’d like to put up a few pages describing (or selling) your products/services, then you are envisioning a content site. If you’d like to do a magazine style site, then you are still considering a content site.

Price Ranges

 Different kinds of projects have different price ranges. We can only offer very rough guidelines as to the kinds of prices we’ve seen for previous projects. Talk to us about the specifics of the project you are thinking of and we could probably offer you a better idea of how much you need to be prepared to spend.

 1.) A personal or company blog, set up using a free service: $0 (or whatever value you place on one hour of effort). But to keep this going and acquire traffic will probably cost thousands of dollars, at least in terms of your time.

 2.) A small company site that has 5 to 10 pages describing the products/services offered by the company. $500 to $2,000 depending on how prepared you are, and also on how clear in your own head you are about what you want. Disorganization and changing your mind are both expensive.

 3.) A company site describing the products/services offered by the company, and operated by software that allows the staff at the company to continually update the content on the site: $2,000 to $20,000.

 4.) A company site that both describes products/services and also offers some kind of software service. For instance, a real estate firm might allow users to look up listings based on zip code or a manufacturer of skateboards might allow users to design their own skateboard, mixing and matching those variables that can be customized. $10,000 to $40,000 depending on the complexity of the software to be developed. 

 5.) An online store that sells digital downloads of songs or videos: $25,000 to $100,000 depending on the variety of prices/royalties you want to support with your suppliers and how much marketing you want to do. If you want original technology for handling the songs or videos, you might easily burn through another $50,000 on computer programming.

 6.) A company wiki so the staff can document a particular kind of information – perhaps support information for your customers, or technical info for use by your sales people, or a human resources directory aimed at answering common staff questions. This should be on the low end of $2,000 to $30,000. The biggest variable is whether you need some special, custom feature. If you can use unmodified, off-the-shelf software, you can keep things quite inexpensive. But as soon as you get into custom programming, the cost will sky-rocket.

 7.) An online magazine/blog meant to dominate a particular niche: $25,000 to $100,000. For instance, you might want to cover fishing in Alaska. You’ll probably want to establish commercial relationships with 6 or 7 avid fishermen who are also known to be good writers. They might each post something once a week. You might spend $50 or $100 a week on each of them, depending how much news they can commit to delivering. You should also hire a lawyer to create an agreement you want the writers to sign.

 8.) An information resource that, to succeed, must be the best: $500,000 to $5,000,000. One fellow came to us and said “I have $20,000. I’d like to build America’s largest database of foreclosed properties.” We replied: “This is obviously a great idea and, if you can pull it off, the site will surely be a great success. But you should really go out and raise $1 million to get started. You’ll need a team of programmers working constantly to get data into your database, you’ll need a lawyer to work out multiple deals with your sources of information, and you’ll need national marketing. You’ll probably need $2 or $3 million over the first two years, but you probably should not even start unless you can raise $1 million.” The other possibility is to start small and build a database of foreclosed properties for a single metropolitan area. If the site is successful, it should be easy to raise the money to go national.

 9.) An online social network for some demographic niche, for instance, new moms, or hockey fans: $20,000 to $500,000. You can keep costs low by using off-the-shelf software, but you will probably want to customize the look and feel of the site, for the purpose of branding. The more services you offer (upload photos? upload videos? search for other users in the same geographic area?) the more expensive the programming will be. If your target demographic niche is risky (perhaps you want to run a site that offers services to recovering drug addicts) then you’ll want to hire a lawyer to write an air-tight Terms Of Use agreement. Lawyers are expensive, so this will drive up your start-up costs. Also, you’ll need a budget for marketing or you’ll never acquire any traffic.

 10.) A completely original idea for a software service that no one has ever thought of: price unknown. There is a rule in software design that the more original the idea, the harder it will be to accurately estimate the cost of the project. Robert L. Glass has written several books on why this is so. Check out his book “Software Runaways: Monumental Software Disasters”.

 Below are some guidelines about factors that will effect the cost of your website.

How does a site acquire traffic?

 If you are considering a content site, then the site’s most urgent need, and one of your biggest expenses, will the be the effort to acquire traffic.

 Rule #1: a content site, to be successful, needs new material everyday.

 Rule #2: do not underestimate how utterly demanding it is to provide new material daily.

 Rule #3: if you do not yet have the amount of traffic that you want, re-read rules 1 and 2.

 Rule #4: if you find yourself wanting to ask something like “Does the word ‘daily’ include the weekends?” then re-read rule 3.

 Rule #5: providing text-based content is cheaper than providing video, therefore, even if you are focused on video, your site will need at least one writer to provide high-quality, professional content that can act as filler between the videos. Or you need a big budget.

 Rule #6: flows of traffic on the web have become increasingly rigid and hard to change, therefore more effort (and expense) is needed to acquire an audience.

 Rule #7: it is extremely difficult to transfer an offline audience to an online destination. Even authors like Lee Stringer, who’ve spent months on the New York Times best-sellers list, attract little attention when they blog online.

 Rule #8: when you hire a writer who has an already existing online audience, you usually capture a substantial portion of their readership.

 Rule #9: the previous two rules imply that hiring an online writer who already has traffic is a better way to capture traffic than hiring an offline writer, even if they are a star. Sites focused on sales will generally want to aggregate news relevant to whatever is being sold.

What drives software development costs?

 If you are considering a software site, be aware of what drives the costs of software development.

 Rule #1: the more customization you need, the more expensive things become

 Rule #2: the bigger the project, the more customization you’ll need

 Rule #3: when programmers invent things from scratch, the number of bugs increase, and the amount of time that will have to be spent beta-testing

 Rule #4: if you want original technology, then your programmers will need to invent things from scratch

 Rule #5: to control risk, all programmers must live by the “Hit By A Bus” rule, which is, if they are hit by a bus and killed, with a project only half-done, another programmer should be able to easily take their place

 Rule #6: the more original the technology, the harder it will be for other programmers to understand the code (creating possible violations of the “Hit By A Bus” rule)

 Rule #7: cost, risk, complexity and understandability (of the code) can be controlled by the use of a software “framework”. Some of the popular frameworks for web development include Ruby On Rails and Symfony (written in PHP)

 Marketing

There are two main approaches to marketing a site:

1.) The Big Bang (hire a PR agency, buy lots of ads, make a big splash)

2.) Slow and Steady (produce quality material/service, rely on word of mouth)

Slow and Steady is always more cost effective than the Big Bang approach, so the Big Bang approach  should not be pursued unless you have money to burn and you are in a great hurry.

Success

The success of your website will depend on two things:

1.) Clarity

2.) Discipline

In some ways the web is a revolutionary new medium with new potentials and new dynamics, but in many other ways running a website is exactly like running any other kind of business. You must have clarity about what you hope to achieve, and then you must have the discipline to stick to your plan. You should be able to describe the goal of your website in one sentence (and if you can’t, then how will your visitors ever understand what the site is for?). If you are unable to sum up your goals when you are speaking with us, there is a good possibility that you haven’t yet achieved clarity (but we would love to talk to you about your idea – we may be able to help you achieve the clarity you’ll need).

An entrepreneur is in trouble if their description of their idea for a new startup comes out as a confused run-on sentence, such as this: “We’re going to be an agency that puts ads into videos and we’re also going to be funding new video artists with our ad money, because we believe in the possibilities of nurturing these new talents, and we’re going to be an aggregator that accumulates the best new talent in video and our software will offer unique technology to advertisers, such as the ability to keep track of exactly how long each viewer watches each ad.” And yes, this is similar to something that was actually said to us. There are at least 4 different business ideas in that sentence, which is at least 3 too many. (If you have an existing business with many divisions, it is fine to have a site that reflects the diversity of those divisions, but a startup needs to be more focused.)

Clarity controls costs. If you are unsure of what you want to do, you will probably change your mind half way through the project, and that will lead to additional expense.

Imagine you hire a carpenter to build a deck on the back of your house. You tell the carpenter that you want the deck to be 10 by 20 feet, and to be built of oak. The carpenter goes out and buys the needed wood. Now you change your mind, and you tell the carpenter that you want the deck to be 8 feet by 18 feed, and to be built of mahogany. The carpenter has to charge you for all the oak that they bought. Changing your mind is expensive!

When it comes to home renovations, people have an easy time understanding why changes drive up costs. However, for some reason, when it comes to the web, people lack this understanding. It is true that the web is a fluid medium, but still, once work commences, the time invested needs to be paid for. If you hire a web design firm and tell them “I want a simple site that lists the services my company offers” then they will start to build one kind of website. If you change your mind and say “I really need a site where everyone in my company can document their work, so I can track what they are getting done” that is a completely different site and needs completely different code. The work on the first site would be thrown out (but you would need to pay for it) and work would begin on your second idea.

Assumptions to Avoid

Many of our clients have started web projects with (sometimes unconscious) assumptions that, in the end, caused them unnecessary anguish and expense. These are the twelve most common mistaken assumptions that we’ve seen:

1.) I (the client) should be all things to all people.

2.) Feature fetish: “The more features I add, the more popular my site will be.”

3.) If I build it they will come (also know as, “If I have a clever idea, I won’t need a marketing budget, because the site will get mentioned on TechCrunch/Oprah/popular blogs/the local newspaper”).

4.) If one person offers a single piece of off-hand, poorly thought-out, casual feedback, we will immediately re-design the entire site to comply with their feedback. And then tomorrow, when someone else offers some casual, poorly thought-out feedback, we will do the same. And then the next day…

5.) The idea for my site is unique, therefore completing it quickly is urgent. If we are not the very first site that uses this idea, then we will fail. My idea is so good that others will soon imitate it.

6.) Things that move or blink grab my attention, therefore if everything on the page moves or blinks, we will have a truly attention getting site.

7.) Text is boring.

8.) The more unusual and unique the interface, the more interested people will be.

 9.) Websites are fluid so any problems that arise can probably be fixed in a day or two.

 10.) If my site starts off with a narrow focus, then its prospects for growth will be limited. People will pigeon-hole it and I won’t be able to add new content subjects later.

 11.) I can spend my money at an unsustainable rate because 6 months from now my site will be bringing in a huge profit.

 12.) I have no experience on the web, but I have uniquely creative ideas, which I think will be enough for me to build a successful online business.

Disorganization

Disorganization will cost you. If you hire a web design firm to build a site for your company, then they will need certain things from you, such as the company logo, and a description of what you are selling. If you are weeks late delivering these things, you inflict delays on the web design firm. Often, the contract you sign will specify some kind of penalty for the delays you cause. A common penalty is to have your project moved to the bottom of their priority list – which could delay your web site several months (this is how client lateness was handled when we worked at Category4). While there is some text and images that the web design firm can provide on their own, there is usually some core material that only you can provide – a description of what you sell being a good example. Have your images and text ready.

Brainstorming

A gold rush mentality has come to shape expectations of the web. Many people now have the mistaken idea that if they can simply come up with an idea creatively unique enough, they can attain great wealth on the web.

Organizations, like people, can suffer pathologies, and the one we’ve seen most with web ventures is what we call “the endless brainstorm”. While it is fun to engage in a brainstorming session, and while this can be a vital tactic to maintain the innovativeness of an existing business, constantly seeking a new idea can be a waste of resources for a venture that has not yet launched.

We once watched, with a certain degree of horror, as almost $1 million dollars were spent on what turned out to be a year long brainstorming session. Many good ideas were hatched during that year, and each idea was pursued for a few weeks, then abandoned once the first difficulties were encountered. The entrepreneur in this case wanted to find an idea so unique that he would face no competition in the field – but this is not the way the business world works. Generally, any good idea will attract multiple efforts, so competition is to be expected no matter what the basic idea is.

We have a friend who worked at AOL during the early days, and who has since worked with several startups, both successful ones and failures. One of the many good pieces of advice he gave us was: “In a startup, ideas are a dime a dozen. Anyone working at a startup will have 2 or 3 great business ideas a week. The greatness of the idea doesn’t matter. All that matters is execution.”

One of the most common confusions that arises from brainstorming is the desire to build a site that offers both unique technology and unique content. In our opinion, a small firm (less than 25 employees) can either create great content or it can create great software, but never both.

Population dynamics

For the last 3 or 4 years we’ve had clients come to us and talk about building up sites using content contributed by users. This can be a great strategy, but you will find it tough to elicit the kind of participation you seek, so if you are targeting a narrow niche, be aware how the population dynamics will work against you. Not long ago a potential client came to us and said “I’d like to build a video site focused on my hometown of Charlottesville, Virginia, and I’d like most of the content to come from users.” We put together the following estimates to demonstrate the difficulties he would face during the first 6 months of the project.

500,000 people

In the whole extended region (Charlottesville and the surrounding 7 counties), there is only about 500,000 people.

250,000 people

Since your project is focused on video, only those people with broad band connections to the Internet will be able to view your site. And only about half the population has broad-band access to the Internet.

200,000 people

It is reasonable to assume that very small children and many senior citizens will be unable to use your site. Therefore, at most, your target audience will consist of 200,000 people.

20,000 people

If you have some really amazing marketing, maybe 10% of the target population will come check out your site during the first six months.

10,000 people

Assume you’ll have a 50% bounce rate, meaning half the folks who visit you may never visit you again. That is standard. That takes us down to 10,000 people.

100 people

Do you want users to contribute material? That is a high level of interaction, and most sites only get that kind of response from about 1% of their audience. That takes you down to 100 people. Can you engineer your business model to work with 100 active users?

Humility

No one can accurately predict where the stock market will be in 2 years (otherwise they’d already be a trillionaire). For almost the same reason, no entrepreneur can fully know where their startup will be in 2 years: there are simply too many variables. It is important that innovators be humble about the limits of their knowledge. A fantastic insight in one area can carry you a long way, but it will have to adapt to the millions of small facts that will arise, almost daily, and shape the history of your insight as it passes from concept to reality. If you launch a startup, the odds are against you from the start, and you’re only hope of success is to remain open minded about what might work.

If your startup eventually succeeds, it will likely be for reasons you did not initially predict. You must proceed with the attitude of a scientist conducting an experiment, and when you get back the results, you must not argue with them, but rather, you must adjust your mental model of the world. When Sir Alexander Fleming saw that mold on some bread crumbs was keeping bacteria from growing in a petri dish, he said “Astounding! That mold must be producing some substance that kills bacteria! Perhaps that same substance can be used to kill bacteria in humans?” How many of us would be dead right now if he had rejected the evidence, and said simply “That’s impossible! Mold can’t hurt bacteria! Everyone knows that!” Over the previous 60 years, two other researchers had already noted the lack of bacteria in the presence of certain types of mold, yet they failed to reach the conclusion that Fleming did. An entrepreneur would do well to emulate Fleming’s open mindedness.

Peter Drucker, perhaps the greatest business guru of the 20th Century, once remarked that innovators are often disappointed by the manner in which their innovations become popular. In his 1985 book, Innovation and Entrepreneurship, Drucker relates the story of Alfred Einhorn, who invented Novocain, which then became popular with dentists as a local anesthetic. Einhorn held a contempt for dentistry, since it represented such a small niche of medicine. He felt that Novocain should be used by surgeons for all forms of surgery, and so he waged a campaign against the use of Novocain by dentists. In the end, his innovation was successful despite him, rather than because of him. According to Drucker, this pattern, where a product or service is undercut by the entrepreneur who is trying to promote it, is extremely common.

When I first read Drucker’s book I found it hard to believe that an entrepreneur would actively sabotage their own innovation. However, having now spent several years working with startups, I’ve seen that it is, indeed, a common pattern. Many entrepreneurs starts websites at least in part because they consider themselves uniquely creative and insightful, and they want the whole world to see them as they see themselves. The website they launch proves them wrong: their insights are proven false, what works in the end is something unexpected. For instance, in 1992, when Bo Peabody launched Tripod, he was thinking that the site would offer content aimed at college students. His idea failed. The company was saved because some of the programmers at the company had started a side project that allowed anyone to create their own web pages. This then became the future of the company. In his book, Lucky or Smart, Peabody says it is important to be smart enough to know when you are getting lucky. And then, you have to be willing to accept that luck. This takes humility. What’s needed in an entrepreneur is emotional resilience, the kind of strength that allows for openness to the unexpected.

Twice now I’ve seen an entrepreneur sabotage their own website because it became successful for what they felt were the wrong reasons. This emotional resistance to success is nearly always inspired by one of two factors:

1.) The success is with a small niche. The startup was suppose to grow till it was larger than Google, and success with a small niche is, therefore, extremely disappointing. The niche might be big enough to potentially generate several million in revenue, but it won’t ever be enough to catch up with Google.

2.) The success is of a conventional type and, therefore, the entrepreneur regards it as boring. Perhaps the site was suppose to pioneer an altogether new style of interaction among humans, and instead the part of the site that becomes popular is of an old type – for instance, the blog on the site becomes highly successful. The entrepreneur is then disappointed, maybe even angry, to be the owner of a boring success.

Here then, are some fatal traps to avoid. Without open mindedness about the type of success you may encounter, your startup is doomed. And without humility about the limits of your knowledge, your startup is doomed.

Equity

Except for when we were working at Category4.com, every client we’ve worked with has offered us equity in their business. So far, we’ve always turned these offers down. If you have an idea for a web startup, and you’d like our help, I imagine that you too might be thinking of offering of us equity. You’d be injuring your own best interests if you did so. Offering equity means that you’d like enter into a business partnership, and business partnerships are a bit like marriage. Suggesting such a union to people you’ve just met is a lot like proposing marriage on a first date. First of all, it suggests desperation. There is nothing wrong with that in itself – we’ve all read stories in Inc magazine of a venture started with too little money but which succeeds against the odds. However, second of all, and much more seriously, it suggests that you are not thinking very clearly.

A business partnership means that we need to take an interest in every aspect of your business, including all of the flaws. This can be brutal. This is not a good way to make friends.

Recently, an older gentleman approached us with an ambitious idea that he could not finance himself. He already had a successful operation providing hospitality services to movie companies that film on location in Latin America. His idea for a web startup was somewhat related. He suggested that we take equity in the new startup, as a form of payment. We explained to him that a partnership was a bad idea because we hardly knew each other. If we were to take his offer seriously, we’d have to interview his staff and find out if anyone disliked him, and if so, why. We’d have to find out if any of his key people were planning to leave soon. We’d have to talk to his customers and find out if they liked him or hated him. This should not be any of our business, yet if we formed a business partnership it would be, literally, our business.

As it turned out, we were lucky not to form a partnership with this person. We later discovered he was struggling with issues arising from a past history with alcohol, and even though he’d been sober for 20 years, he was still exhibiting some of the behaviors that had sabotaged him before. Incidents such as this are the main reason we are wary of taking equity. But here is the thing – you should be wary too. What about our flaws? What about the stuff we get wrong? If you are offering us equity when you hardly even know us, then you are trusting us too much. And, to us, that indicates that you are not thinking clearly about the risks that your venture will face.

People should know each other at least a year before they think about forming a partnership together. Web startups routinely break this rule, and I suppose that is fine if the company is built to be flipped – that is, you assume that you’ll cash out in a year anyway, so you don’t have to worry about other people’s flaws -  there won’t be enough time for those flaws to come back and haunt you. However, as a general rule, business partnerships should be for people who know each enough that they can trust each other. Even in those scenarios where the company is built to be flipped, you’ll find that having one wrong person on your team, as an equity holder, can significantly hurt your chances of selling the company.

Contact Us

 We have worked on sites that had budgets under $1,000. We have worked on sites that have cost $250,000. We have long associations with a network of professionals which allows us to quickly assemble an agile team with exactly the skillset needed for the construction of your website. Whether your site needs graphic designers, computer programmers, videographers, writers, marketers, photographers or system administrators, we can bring together the talent you’ll need. We can even give you some rough guidance about which situations you’ll need a lawyer for. We are especially able to help web-focused startups whose initial 6 month budget is between $10,000 and $100,000. We can also help with existing sites that have so far failed to attract an audience.

 For every rule we’ve written here, we can think of three qualifiers. If you’d like to hear how the subtleties might apply to your web project, contact us. We are willing to meet once for free, to give you our honest feedback about your idea.

 434-825-7694

contact@teamlalala.com

Darren Hoyt has a great post up about “the empty handed client“:

But what happens when a client has nothing to submit — no photos, no taglines, no logos, no text, no identity? …Obviously a project can begin without all the materials, but it’s far from ideal. In the absence of photos and text, you can help the process along by quizzing the client about their industry, business philosophy or desired audience. In this sense, you’re getting a feel for “content” even without materials.

In response to it, I posted a comment about classic mistakes that clients make. I’m reposting my comment here:

If my client is empty-handed, unsure even of the idea of their site, then I feel the best option is to talk to them, to help them clarify their thoughts. Sometimes I feel like a therapist, listening as the client pours out their hopes and dreams and fears and worries.

We’ve acquired 3 new clients this summer. In all 3 cases, I was brought in at an extremely early phase, before the basic idea of the site was decided. I do not mind sitting in on brainstorming sessions. So long as the client can pay me for the time I spend at meetings, I enjoy helping them avoid mistakes.

For instance, one mistake is the behavior pattern I would describe as “too much brainstorming”. If I’m in meeting with the client for the 3rd time and the meeting is still a pure brainstorming session, I warn the client that they are at risk of wasting a lot of money on simply trying to figure out what they should do. I once saw a substantial fortune wasted on what turned out to be a 2 year long brainstorming session.

I’m sympathetic to the argument that the opposite is also true: it is crazy to risk a vast fortune on an idea that you have not thought about carefully, so a prolonged period of testing the permutations of an idea can certainly be justified if the project seems likely to be huge. So, as I said, I don’t mind sitting in on the brainstorming sessions, so long as the client can pay me. I feel especially helpful when the client suggests something that I know, from previous experience, is a terrible idea. Certain thought patterns are traps, they always fail, yet they are quite common among clients considering their first web project. Among those traps:

1.) If I (the client) build it they will come (also know as, “If I have a clever idea, I won’t need a marketing budget, because the site will get mentioned on TechCrunch/Newsweek/The New York Times”).

2.) Feature-itis: “If I add in all the good features from all the popular sites, then my site will be as popular as all those other sites combined.”

3.) I can/should be all things to all people.

4.) If one person offers a single piece of off-hand, poorly thought-out, casual feedback, we will immediately re-design the entire site to comply with their feedback. And then tomorrow, when someone else offers some casual, poorly thought-out feedback, we will do the same. And then the next day…

5.) Flash is more dazzling than anything that HTML can offer, therefore our whole site should be built in Flash.

6.) Things that move or blink grab my attention, therefore if everything on the page moves or blinks, we will have a truly attention getting site.

7.) Text is boring.

8.) Images are always better than text.

9.) I (the client) am over the age of 35/40/45/50 therefore people will think I’m out-of-date and too old to be starting a web business. I will prove my youthfulness by only using the most bleeding-edge technologies.

10.) Bleeding edge technologies are always more interesting than older technologies such as text.

11.) Users prefer cutting-edge technologies over older technologies such as text.

12.) The more creative/unusual the interface, the more interested people will be.

13.) If my site starts off with a narrow focus, then its prospects for growth will be limited. People will pigeon-hole it and I won’t be able to add new content channels later.

14.) I can spend my money at an unsustainable rate because 6 months from now my site will be bringing in a profit.

15.) I have a lot of money right now, therefore I am a genius web entrepreneur (the money may have come from inheritance, good luck selling a house at the peak of the housing boom, or perhaps thrift at a younger age – none of which confers the business skills needed to run a business, online or off).

I could go on. I’ve seen many mistakes, and I’ve seen a few successes, or, at least, glimpses of successes. When a client comes at me empty-handed, I talk to them until an idea takes shape and seems concrete enough that construction can begin.

I do think it is wise to try to get to something concrete as fast possible (as per 37Signals). It might be impossible to get the whole idea mapped out quickly, but sometimes small parts of it can be made solid. I think it is wise to have the graphic designer try to put visuals on anything that can be agreed upon as unlikely to change.

I also liked an earlier post that you (Darren) wrote, over at Sitepoint, about working toward a single mockup for the front page (rather than offering 3 different versions of the front page). I do think that getting the front page into a concrete form greatly helps getting the whole project solid.

This looks like a good site. I’ll post a link so I can remember to go back and check it out later.

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.

The often interesting robert hoekman, jr:

Our Stories should be an experience rich site. It should offer an engaging environment that compels users to explore and connect emotionally to the storytellers. But it doesn’t offer this at all. Instead, it offers what looks like any other Google design. It’s plain, minimalist, and it’s focused entirely around the information and not the experience.

Google apparently thinks it has hit upon the secret formula to all successful websites – simple, minimalist designs that offer information in a concentrated form. In reality, this formula only works for certain classes of sites, of which the original Google website was the par exemplar. Google fails when it attempts to build a site that needs a philosophically different approach. As Hoekman explains:

 If Google’s goal here was to create emotional connections, they should definitely have considered something other than the business-as-usual, sterile design work that has become Google’s signature. Granted, some of the site’s pages are geared towards showing people how to conduct interviews for the site, and those pages are probably best left alone, but the main attraction here is an environment of storytelling, not another Google search results system.

…Design is meant to communicate content. With the right design, you can always meet your goals much more effectively. If you want emotional connections, design something that encourages them. If you want people to take action, design to encourage action. Don’t let your usual design style get in the way of doing something great.

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.

Yet another example of bad web programming. I was researching the subject of cancer and followed a link on a government site that gets me to this page:

I think its fine to print debugging information to the screen when a website is under development, but on a live site, I think the error messages should try to be more helpful. Perhaps the error message can suggest the average speed it takes the site’s sysadmins to fix problems of this time. Or the error message can suggest that the visitor go get the page out of the Google cache. Even the cutesy error message that Stikipad used was more reassuring than this.

Back on September 24th, I decided to put my Netflix account on hold. I knew I was facing a stretch of time when I was going to be too busy to watch movies. Apparently Netflix only allows you to put your account on hold for 90 days. Nevertheless, the form that I was presented with allowed me to choose any date in December, so I chose December 31st, as you can see here:

Upon submitting the form, I got the following error message:

This is, of course, an example of bad user interface design. They should not allow me to choose a date which they themselves forbid. It is confusing that their form should offer a date which is, in fact, not allowed.

The framework I wrote auto-generates forms based on the definition of a table in the database. These forms are usually quite ugly. The advantage of these auto-generated forms is that they speed the initial set up of a site – I simply define some database tables, based on what the client has told me they want, and the framework auto-generates the form.

On the TSR site, we are still cleaning up the rough edges. Laura Denyes, the lead designer on this site,  is transforming the rough and ugly forms. After enhancing the clarity and improving the use of space, we hope to leave the user with a better experience. You can see Laura’s work in this before and after image:

My friend gets her ass whooped.

Well, maybe “broken” is too strong a word. The CSS failed to load. Which happens sometimes. Which is part of why semantic markup is important. How much does the user experience survive the lack of style sheets? This from the front page of Old Navy:

Just curious, but does anyone know some common reasons why the CSS files might fail to load?

Also curious about the marketing. The front page of the site is aimed entirely at women. Do women buy clothes online more than men?

I was helping a client move their site from GoDaddy to another web server. I logged into GoDaddy and found the MySql database and made a backup. Then I got sidetracked for 15 minutes. When I started working again, I got this error message (screenshot below). GoDaddy is right to log me out after 15 minutes of inactivity, that much is good security. But they tell me where I am suppose to go in the text, without providing a hyperlink. I can only get out of this page by hand editing the URL in the address bar. Badly done.

Yet another story about a badly programmed website, with really bad error messages.

I went to pay my monthly cell phone bill. Just last month, SprintPCS instituted a new policy, requiring stricter passwords with more letters and numbers in them. So I was forced to change my password. Perhaps I was also in a hurry, as I did not write it down in the usual place.

Today, unable to remember the new password, I clicked the link they offer for “Forgot your password?” I came to the screen you see in the first image.

I typed in my “username”, which is simply my telephone number. When I hit the submit button, I got, in response, a blank white page with the text “Error: 500″. That’s it. Nothing else. Just that text on a blank white page. You can see it in this second image:

I offer this anecodote as one more small piece of evidence for the case that most web sites are horribly programmed and poorly tested. I don’t mean to pick on SprintPCS, since there are many sites that are just as bad, but this just happens to be the broken website that I interacted with today.

Mind you, the above incident happened this morning, around 11 AM, and now it is 11 PM. I just went back to get screenshots. Twelve hours later, the problem is still there.

I sent SprintPCS an email about this. I have not yet heard back from them. I’ll update this post if I do hear from them.

UPDATE: wonderful response time. I just got this, on the 17th. The irony:

Date: Mon, 17 Sep 2007 14:08:18 -0500 [02:08:18 PM CDT]

From: Sprint Customer Solutions <ecare@cc.sprintpcs.com>

To: LAWRENCE@KRUBNER.COM

Subject: Re: Subject: ID # 20070914212929 (KMM38317571I123L0KM)

Hello Lawrence Krubner,

Thank you for contacting Sprint.

A ticket has been submitted in reference to the difficulty you are experiencing logging into your account online at Sprint.com. The ticket number is 16880851.

A follow-up call will be made to you within 36 business hours.

Thank you again for contacting Sprint. We appreciate your business.

Mary O.
E-Care
Sprint
“Where our customers come first!”

Refer someone to Sprint and get $25.

So after 3 days, they send me an email in which they promise to contact me within 3 days. Then they close with “Where our customers come first!” Hate to think how we’d be treated if we came second.

A very nice point by Robert Hoekman:

We hold up usability as laudable because, sadly, most companies still have serious trouble putting their pants on correctly when it comes to usability. They need the gold stars.

Anyone in the interaction design or usability profession worth his salt knows that usability is a single piece of a very large “experience puzzle”. You need a strong value proposition to get users in the first place. You need a compelling product or service. You need good customer service when things go wrong. You need marketing prowess. You need something that makes you different, and better, than everyone else in your space.

For a product or service to be great, you need all these things. But you also need a usable touchpoint. A strong value proposition gets people interested in your product, but once you have their attention, a high level of usability helps motivate people to keep using it. A low level of usability deters people from using your product.

danah boyd has a new essay about class dynamics and how they divide the people who use MySpace from the people who use Facebook. Everyone has linked to this essay, including such major media outlets as the BBC. One thing that jumped out at me was her idea that even the design of the site, the look and feel, were reflecting cultural values that arose from class divisions. (In the following excerpt, she uses the word “hegemonic” when referring to culturally middle class people, and “subaltern” when referring to culturally working class people.)

Most teens who exclusively use Facebook are familiar with and have an opinion about MySpace. These teens are very aware of MySpace and they often have a negative opinion about it. They see it as gaudy, immature, and “so middle school.” They prefer the “clean” look of Facebook, noting that it is more mature and that MySpace is “so lame.” What hegemonic teens call gaudy can also be labeled as “glitzy” or “bling” or “fly” (or what my generation would call “phat”) by subaltern teens. Terms like “bling” come out of hip-hop culture where showy, sparkly, brash visual displays are acceptable and valued. The look and feel of MySpace resonates far better with subaltern communities than it does with the upwardly mobile hegemonic teens. This is even clear in the blogosphere where people talk about how gauche MySpace is while commending Facebook on its aesthetics. I’m sure that a visual analyst would be able to explain how classed aesthetics are, but aesthetics are more than simply the “eye of the beholder” – they are culturally narrated and replicated. That “clean” or “modern” look of Facebook is akin to West Elm or Pottery Barn or any poshy Scandinavian design house (that I admit I’m drawn to) while the more flashy look of MySpace resembles the Las Vegas imagery that attracts millions every year. I suspect that lifestyles have aesthetic values and that these are being reproduced on MySpace and Facebook.

I should note here that aesthetics do divide MySpace users. The look and feel that is acceptable amongst average Latino users is quite different from what you see the subculturally-identified outcasts using. Amongst the emo teens, there’s a push for simple black/white/grey backgrounds and simplistic layouts. While I’m using the term “subaltern teens” to lump together non-hegemonic teens, the lifestyle divisions amongst the subalterns are quite visible on MySpace through the aesthetic choices of the backgrounds. The aesthetics issue is also one of the forces that drives some longer-term users away from MySpace.

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.