Search This Blog

Tuesday, December 27, 2011

How To Explain To Clients That They Are Wrong

How To Explain To Clients That They Are Wrong:
Smashing-magazine-advertisement in How To Explain To Clients That They Are Wrong
 in How To Explain To Clients That They Are Wrong  in How To Explain To Clients That They Are Wrong  in How To Explain To Clients That They Are Wrong

Spacer in How To Explain To Clients That They Are Wrong
GIFs of spinning @s on the “Contact us” page. Common usability mistakes for the sake of visual appeal. Splash pages. Fancy search box. No whitespace. Music on page load. Home page banner of a jigsaw-puzzle globe with a piece missing. Sometimes you just know that what a client is requesting is wrong and that you have to find a way to tell them. But how?

Is The Client Wrong?

Before getting into how to explain to a client that they’re wrong, ask yourself, “Is the client wrong to begin with?” Just because you don’t approve of the direction they’re taking or of a request they’ve made doesn’t necessarily mean it is not a step in the right direction for the project. To be able to answer this question effectively, you need to train yourself to be completely objective and humble when dealing with client requests.

First of all, appreciate one critical thing: the client probably knows their target audience a lot better than you do. Just as Web professionals quickly learn personality types among their own clients, your client interacts with their target audience on a daily basis and knows what makes them tick… and that may be just what makes you cringe.

You can begin to establish if the client is wrong simply by exploring why the client is making such a request and what the business case for it is. It could well be a situation in which they spoke to many people in the target audience demographic, and they all said that they were more likely to click an animated Flash banner link than a static one, or that they felt more engaged by a website that had stock images of smiling people everywhere.

It could be that the picture of the jigsaw-puzzle globe with a piece missing actually sums up the client’s sales pitch quite well and that similar messaging has proven to win over potential customers in the past.

Creative-way-to-show-a-missing-piece in How To Explain To Clients That They Are Wrong
Image source: Lady Madonna

Of course, when faced with such a situation, a good Web professional would understand the business driver and suggest alternative solutions that convey the same message and achieve the same goal but that are unique, original and creative.

Whatever the case though, always keep an open mind. Don’t assume the client is wrong before seeing the evidence. One guarantee in this business is that the more you design and develop websites, the more often you’ll find yourself in situations where, six months after a project’s launch, you hear that the most positive feedback from users wasn’t the cool bit of JavaScript you implemented using groundbreaking technology, but rather something that you considered boring and unoriginal but that excited the client during development. We deliver websites for the client’s target audience, not our peers in the Web community: sometimes painful to swallow, but always true.

That scenario aside, let’s put our cool hats on again and assume that the request for the jigsaw-puzzle globe has come in, and that it clearly has nothing to do with the client’s business, and that it has made you curl up in a corner of the room, banging your head against the wall, muttering “Why? Why? Why?”

What approaches can you take to explain to the client that, in your professional opinion, they’re wrong?

Speak The Client’s Language

One of the most common problems, especially among freelancers, is an inability to speak the client’s language. Being able to speak in a way that relates to the client’s business sense is crucial at all stages of managing a Web project, but never more so than when challenging a client’s decision.

If you’re trying to explain to a client that a rotating banner (or any other feature) may not be the most effective use of their budget, rather than say something like, “I just don’t think it will work,” or “I’m not sure you have the budget,” ask instead how they think implementing it will benefit their business, generate more quality leads or increase conversions.

Always emphasize the main goals, or KPIs (key performance indicators), of the project. You’d be surprised by how often such a question will result in a few seconds of uncomfortable silence, as the client realizes that they want the feature because they think it looks cool, when in fact they can’t connect it to a KPI.

Building a website or Web application should be treated in the same way as growing a business:

  1. Know what you want to achieve.
  2. Define some measurable KPIs or goals.
  3. Develop a plan.
  4. Begin executing the plan.
  5. Evaluate every decision along the way to make sure it supports a KPI, thus taking repeated steps towards achieving the project’s goals.

By maintaining this approach, you will also radically change the client’s opinion of you, from that of a creative hippie-type to a business-savvy Web designer or developer whom they should listen to if they want to stay focused on the purpose of the project.

Buzzword-bingo-board in How To Explain To Clients That They Are Wrong

Being able to speak the client’s language will undoubtedly help greatly when the time comes to tell the client that they’re wrong. Beyond using Buzzword Bingo words with confidence, you need to be able to back them up with valuable advice drawn from your area of specialization.

Establish Yourself As The Expert

One of the most important ways to make the ordeal of explaining to a client that they’re wrong as stress-free as possible for both parties is to establish yourself as the Web expert. If you do this, the client will completely trust you and your recommendations without a moment’s hesitation. Perfick!

But even if you are a Web expert, the position is not always easy to establish, because it usually only becomes apparent over time, after you’ve gotten a few successful decisions or projects under your belt with the client. It doesn’t help either that many clients still regard creative digital agencies and freelancers as either kids living in their parents’ basement or shady professionals out to take them for every last penny.

Though a challenge, you can establish your credibility quickly using a few methods, some of which are relatively simple to do.

Be Professional

Before they’re convinced that you’re a digital professional and that they should trust your recommendations, you must first demonstrate your professionalism by doing the basics well:

  • Be punctual at meetings and teleconferences.
  • Always speak in a professional manner.
  • Deliver pre-sales paperwork on time.
  • Present all documents and images on professionally branded templates.
  • Use correct grammar and punctuation in emails.

Be-professional-with-the-client in How To Explain To Clients That They Are Wrong
Image source: Ha-Wee

You’d be surprised by how quickly clients pick upon deficiencies in these basic business skills. Their perception of you and your recommendations will be immediately affected. Unless you come across as the consummate professional early on, shaking off this reputation will be difficult.

Don’t Be Shy About Citing High-Profile Clients

You could well be a digital guru who has spent years working in the industry and earned the respect of the Web community, but most clients won’t understand what this means. They have never heard of websites such as Smashing Magazine or magazines such as .Net, and they probably won’t grasp the gravitas that comes with being a speaker at Web conferences such as SXSW.

However, all clients tend to respond when you say you have worked on a high-profile brand website. When clients hear that you’ve been hired by a big name that they’ve heard of and whose products they perhaps use, they sit up like a meerkat and think they’ve hit the jackpot. Simples!

Client-meerkats in How To Explain To Clients That They Are Wrong

While some Web folk aren’t always comfortable selling themselves, and while big brand experience is not always proof of ability, it almost always resonates with clients and makes them see you as more credible. This reinforces your position as an expert whose advice should be heeded. After all, if big brand X thought you were good, you must be, right?

Sometimes, of course, no matter how much credibility you demonstrate, a client may choose not to listen to your recommendations. But perhaps they’ll listen to others…

Back Up Recommendations With Evidence

How often in life have you volunteered your point of view to someone for months, only to be beaten down each time; and yet when someone else comes into the picture and says the exact same thing, their advice is seized upon as revolutionary. This is human nature and happens just as much when explaining to clients that they’re wrong.

If a client is, for whatever reason, unpersuaded by your arguments, you might want to consider going all CSI on them and producing evidence that backs up your recommendations.

This evidence can come in many forms. For example:

  • Blog posts from world-respected Web experts.
  • Statistics from large usability studies.
  • Well-known cases where the same thing was tried and had negative results.

Five-second-test in How To Explain To Clients That They Are Wrong

This kind of evidence is obvious. But sometimes, the less obvious kind can be just as effective:

  • Guerrilla usability testing, by asking the client to obtain feedback from employees within the company.
  • Using free tools like Five Second Test (or dozens of other tools) to flash test designs.
  • Submitting designs to communities dedicated to providing design feedback, for example Feedback Army.
  • Feedback from customers with whom the client has a good relationship.
  • Setting up a poll on the website that presents both ideas.
  • Web analytics from the current website.

Common points of contention will be which browsers to support, which screen resolutions to optimize for and where to put the fold. But no matter the debate, backing up your point of view with trusted third parties can sometimes tip the balance in your favor and improve how the client perceives your dedication, enthusiasm and passion for getting it right.

Sometimes, Being Direct Works

When all else fails, you could always tell the client flat out that they’re wrong. This is always a risky move, because clients will react differently. Some will appreciate it, while others will find it disrespectful or personally insulting. But if you feel strongly about it and you’ve tried every other method, being direct might do the trick.

Personally, I’ve been in situations in which I’ve had no alternative but to tell a client that their request is “naff.” To my surprise, despite the ferocity with which the client initially defended their opinion, they backed down immediately and thanked me, saying that this is what they were paying me for: to be strong and stubborn and to tell them things like this. However, merely saying that something is naff and nothing more is not ideal; you have to offer an alternative solution.

Use this approach with caution. Take into account your rapport with the client, and be passive in your tone of voice. Also, choose your method of communication wisely; for example, being so direct by email is usually a big mistake because of the possibility of misinterpretation.

Clients-sometimes-get-angry in How To Explain To Clients That They Are Wrong
Image source: Darren Hester

If possible, be direct with the client face to face or by telephone. This allows you to deliver the message directly and set the right tone. You will also be able to observe the client’s body language or hear their response instantly and then quickly adjust your approach if needed. Generally, if a client turns green with fury, their nostrils emit a trace of steam and their clothes rip at the seams, you may want to back down and move swiftly to the next item on the agenda… or call an ambulance because they may be ill.

Of course, sometimes no matter what you say or do, a client will overrule and insist that you follow their request. You know what? That’s okay. It happens. That’s life.

But that doesn’t necessarily have to be the end of the debate!

Know When And How To Admit Defeat

Occasionally you’ll try every known method of explaining to a client that they’re wrong, and nothing works. They’ll continue insisting that you design or develop whatever they want or else they’ll go to someone who will. And yet you feel with complete sincerity that they’re making a mistake that will have a negative impact on their business. This is never a good situation to be in.

Know-when-to-give-up in How To Explain To Clients That They Are Wrong
Image source: Great Beyond

There really are no hard and fast rules on what to do in such a situation. Each case should be treated on its own basis. But with experience comes the instinct of knowing when to admit defeat and do as you’re told.

This feeling is never nice, but sometimes that’s how it is. And if you have to sit in the corner and be quiet, do it professionally and politely. Under no circumstances should you throw your toys out of the pram and give the client attitude. Simply explain to them that you have put forward your recommendations and given your reasons. At the end of the day, it’s their business and their decision. It stings, but you’ve done all you can, and your dignity remains intact. But don’t give up yet!

Treat Defeat as an Opportunity

Saying that good entrepreneurs view every defeat as an opportunity is almost a cliché these days. But it’s true, and these situations are no different. There’s admitting defeat, and then there’s pretending to admit defeat! Once you’ve been beaten down by a client, accept it, get over it and think positively about how you can turn defeat into a win/win for everyone.

For example, suggest to the client that if they choose to press ahead against your recommendation, then your next recommendation will be to implement some custom Web analytics to monitor the outcome of the decision.

Testing-your-recommendation in How To Explain To Clients That They Are Wrong

For example, if a client insists on giving the home page banner a small call to action that, in your opinion, is difficult to read or not prominent enough, persuade them to let you implement some A/B testing: one month with their banner and one month with your proposed solution, and let the statistics do the talking. No client on earth would continue to insist on their solution if yours delivered a better return on investment.

If you’re thinking, “What the heck is A/B testing?” even better! This is an ideal opportunity to learn a valuable skill while getting paid and giving your client excellent service!


Explaining to a client that they’re wrong is never easy. It could blow up in your face and damage what was a good relationship. But everyone is wrong sometimes, and clients are no different. Always start by asking yourself if the client is, in fact, wrong. Or are you trying to impose your opinion (based on a narrow Web-only view) on what is ultimately a business decision that affects the client’s entire strategy, both online and offline.

If you conclude that their direction is still misguided, open a dialogue with them in language they relate too: business language. Rather than say it won’t work, ask them what goals or return on investment they think the direction will help achieve. Establish yourself as the digital expert from the moment you make contact with the client by conducting all aspects of your work with professionalism. Do everything you can to position yourself as someone who has the experience to suggest alternative solutions. And where possible, back up your recommendations with third-party material and user feedback.

If all else fails, be direct with the client. But know which clients you can be direct with and when you will have to back down. Finally, don’t let being overruled be the end of the debate. Suggest testing periods, and let the Web analytics do the talking. All clients respond when they see important metrics go up rather than down!

What are your favorite ways of telling clients that they’re wrong?

Related Posts

© Sam Barnes for Smashing Magazine, 2009. | Permalink | 91 comments | Add to | Digg this | Stumble on StumbleUpon! | Tweet it! | Submit to Reddit | Forum Smashing Magazine
Post tags: ,

How Do You Deal With Overstressed, Irrational Clients? An Entrepreneur’s View

How Do You Deal With Overstressed, Irrational Clients? An Entrepreneur’s View:



As an entrepreneur who has been on the client’s side of the design and development process, I’d like to discuss the thought process of the client, as well as some effective ways to interact with them. For example, why do they ask for Shakira music on the home page? And how do you respond to that?

I was recently referred to Sam Barnes’ piece on Smashing Magazine “How to Explain to Clients That They Are Wrong.” The article was well written and made a lot of sense to me, but there are two sides to every story, and I’d like to add value to the argument by responding from the client’s point of view.

For the most part, Sam did a great job of discussing how to evaluate and act on poor decisions made by clients. What he missed, however, was the impact that the nature of the relationship between clients and creatives has on how decisions are made by both sides. By “creatives,” I mean anyone involved in the design or development of a website or application. Understanding this relationship will enable you, and your clients, to make better decisions about the product.

What’s On the Line For Us

Before getting into the decisions that entrepreneurs make, let’s look at some of the factors that motivate these decisions. Setting the scene will shine a light on the thought process of entrepreneurs and give you a better idea of how to deal with them.

You’ll notice I use the terms “entrepreneur” and “client” interchangeably. Even if your client works within the confines of a corporation, as opposed to at the top of a new venture, it would not be unusual for them to act in an entrepreneurial capacity. And even if they aren’t entrepreneurs, but middle men who were assigned the project, chances are they will still behave accordingly.

Formal design reviews
How do you deal with clients who often come up with weird, irrational requests? Image source

First, let’s think about the person you’re working with. They believe in an idea. They believe in it so much that they’ve left a paying job for it. They’ve worked nights and weekends for it, alienated their spouse, friends and family for it. They’ve begged, borrowed and stolen for the opportunity to pursue it. They’ve put everything on the line for their idea, their vision. And you know what the most important part of their vision is?


It’s not them. And to be honest, it never really was. The first question investors ask after hearing someone’s idea is, “OK, who’s building it?” Your client knows that their creative team is the only thing that can make their idea a reality.

You’re the most important piece of their puzzle, and, despite what they tell themselves, what they know about you before starting the project is often limited.

So, how did they find you?

Clients turn over every stone in search of a designer or developer, because, by that time, the necessity of a good creative team has settled in. Entrepreneurs might look harder than others because of the pressure of their particular situation, but the importance of a good creative team is lost on no one. And this isn’t like finding a lawyer, a doctor or even a girlfriend.

It’s way harder.

The Leap of Faith

There are three gigantic problems with the process of finding a creative team. First, the client has probably never done this before. Secondly, finding a creative team is tough. Products such as will help, but because clients generally don’t speak your language, assessing the strengths of a firm and how it would mesh with their product is difficult. When the team I picked told me they were experts in Ruby on Rails, my first thought was, “Is that a train or a restaurant?” Thirdly, and by far the most important point, for those of us not in the Web design or development community, feeling comfortable with our evaluation of creatives is impossible.

This is a relatively young industry, one with very low barriers to entry. Heck, my designer took his first client when he was 13. There are very few, if any, metrics we can use to evaluate a creative team. We can look at its past work, speak with the head of the team and maybe get some sort of sample or mock-up, but for the most part, we are flying blind. There are no requisite degrees, certifications or guarantees. If you go to a physician who hasn’t finished college, you probably wouldn’t be willing to let them operate on you. A developer who hasn’t gone to college could build you the next Foursquare.

The Search

In our search for a creative team, we come upon cousins and uncles of acquaintances, people who have designed investor-relations websites for Fortune 500 companies, people who wait tables but build iPhone apps on weekends. We have absolutely no idea what to think of all this.

First-time clients especially don’t understand how hard their product is to create, or how long creative design takes, or even if you’ve done this sort of work before. It’s all Japanese to them, and it’s an enormous leap of faith. All we can do is look at some of your prior work and decide whether we like it. In what other sphere of life would you make a decision this important on a gut reaction? (Wait, don’t answer that.) It’d be like grabbing someone at the grocery store and asking them to marry you because you both have Fruit Loops in your carts.

Even when we look at successful companies in our fields, their success is not always commensurate with the development or design of their products. Take Craigslist: great business idea, poor design; but it doesn’t matter because the content is great. On the other hand, Flipboard’s design is fantastic, and that’s enough to make the product successful, even although its functionality isn’t really revolutionary.


Grasping For Control

With reservations and doubts lingering in the back of the client’s mind, in steps the creative team. You start pumping stories into Basecamp, PivotalTracker or some other product-management system that the client’s never heard of, and suddenly they are on your turf. Now the client works when you work, and often sits quietly on their hands when you don’t. The product goes when you say it goes, and their input is limited. Worst of all, we flat out don’t understand what you’re doing.

This is extremely hard for people who are used to complete control. Your client has gained so much momentum to get to this point that, when the creative team takes charge, the ground drops from under them like they’re some unfortunate cartoon character. This reversal of control is jarring.

This would be fine if the entrepreneur was working with a lawyer, an accountant or even a bank. But early on in the life cycle of a company that depends on a creative team for its success, nothing, and I mean nothing, is as important as the creative team. And our control over the success of this phase is so limited. That’s why we make uninformed suggestions like, “Let’s make that @ symbol spin,” and “I think users would like some Shakira playing when they land on the home page. I know I would.” Because we’re grasping at straws.

We are trying to hold onto our vision, because suddenly it’s in your hands. We may know what we want, but we often don’t know how to do it, and we have trouble expressing it. I’ve often found myself telling my developer things like, “I want a magic search box that pulls information from the Facebook API [I learned that term a few months ago, no big deal], Twitter and Foursquare and spits out relevant people based on our compatibility algorithm,” only to have him respond, “… Yeah. Let’s start by allowing users to log in with their Facebook account.”

I know how I want the product to feel to the user, but I have no idea how to get there without my team’s help. Saying, “I want it really simple, easy to use and elegant” is not helpful. Grasping at some visual element that we comprehend is sometimes the only bullet in our gun.

So, How Do You Deal With Overstressed, Irrational Clients?

Now you have an idea of the sometimes fragile psyche of the client. The question is, how do you handle us when we say we want Shakira?

Sam’s points are all well taken and, for the most part, right on. But they are directed at a rational, faceless client. The overview is good, but implementing it in real life would be difficult. So, here is the perspective of a client with a face. The following five actionable tips should drastically help your client relationships.

  1. Show us.

    This one is the most important. It’s very hard for us to visualize our idea. We know how we want the product to feel, but we don’t know how to get there. We would certainly recognize that Shakira isn’t the answer if you showed us this on our website — or on a comparable website if building our mistake would be too time-consuming. Usually, if the client was savvy enough to get to this step in the process, they would know what works and what doesn’t. And if they don’t, their idea is hopeless anyway.

  2. Tell us.

    This one wasn’t in Sam’s points. Good entrepreneurs are flexible and can adjust their vision to meet the reality of the situation. If we want something, but you think it would take too long and not be worthwhile, tell us. Suggest a workaround if you want, or just ask us if there’s another way. Entrepreneurs are usually great at creative solutions; we make our living by avoiding barriers. But we can only avoid barriers if we know what they are.

  3. Explain the rules of the game.

    If you’re building a basketball, you know what you can and can’t do. You could probably make one that’s bouncier or more durable than competing products. But you couldn’t make one that goes in the basket every time. You know your limitations, but sometimes we don’t, and creativity is only able to flourish inside the box of reality. Because we don’t know the rules of the design and development game, we often don’t know what’s possible. More often than not, we’ll assume that something isn’t possible when it actually is. The head of my creative team had a good solution for this: he created a folder of ridiculous ideas that I wished could be part of the website, and I dumped stuff in there from time to time. More often than not, he’d ping me saying, “Hey Brian, that’s possible. Let’s try it out.” Being creative is difficult when the canvas is blank. If you can give us a line to start with, some sense of what you are capable of, it’ll help us enormously on the creative side.

  4. Be confident and enthusiastic.

    Everyone appreciates an expert. Sam touches on this, and it’s extremely important. When I told my designer that I was considering profile pages that end users could design, he said something like, “Well, it certainly worked for MySpace.” Point taken. Demonstrating your expertise puts clients at ease and instills trust in your decision-making abilities. Also, don’t be afraid to occasionally ask for forgiveness rather than permission (as long as the change is not customer-facing). It will reaffirm that we made the right decision. Nothing is more invigorating than someone who believes in your vision.

  5. We can’t act like locals.

    Clients aren’t completely oblivious to their mistakes, either. They know that some of their suggestions are absurd. They know that they don’t understand this stuff one-tenth as well as you do. They know they’ve stepped into a subculture that they couldn’t possibly fit into. It’s like when you go on a ski vacation and try to act like the locals. No matter what you do, you won’t be one. And we hate that we are an outsider in your world. That manifests itself in a number of ways: weird suggestions, holding firm on an irrelevant point, demanding certain color schemes that probably don’t matter (but sometimes do). This will still happen, but now that you know where they’re coming from and how to assuage them, you should hopefully have a more effective connection with clients. On the flip side, expect to be treated with the same level of suspicion and hesitation when you step into our world. Sam urges you to speak the client’s language, to set goals in business terms. Be very careful with that one. Misusing one business buzzword can waste your credibility, just as one suggestion for a spinning @ symbol will make you wary of any other design ideas. Discussing markets that you have exposure to but aren’t immersed in can have adverse effects. Know that we are all tourists. Which leads to the final point.

The Odd Couple

In writing this article, I realized how odd the relationship is between creatives and clients. Without my creative team, I would have no shot at getting my company off the ground. I rely on them 100%, but I have no clue what they do, how they do it or if the work they do is reasonably priced. This forces me to try to speak their language, to attempt to enter their world by learning quickly, and to try to maintain control of a vision that they are responsible for bringing to life.

Creatives, on the other hand, rely on clients only somewhat. They don’t live and die by each project, as clients do. Their work is in great demand; many of the firms I considered are growing quickly in this recession.

However, bits and pieces of Web design and development work are slowly being fragmented and commoditized, and for the same reasons that evaluating designers and developers is difficult: the barriers to entry are low. This opens the door for 99Designs to pick off clients, especially vulnerable entrepreneurs. These services leverage the crowdsourced model by matching designers who have little or no experience with clients who don’t understand the nuances of the craft well enough to be able to tell. This pushes creative firms to differentiate themselves through means that clients can understand. Business acumen is an incredibly helpful skill for creatives to have, and something 99Designs can’t offer.


So, we’re left with two groups, each possibly operating in unknown waters, working to create a product that requires both of them to be firing on all cylinders in order to succeed. That being said, do business-savvy creatives exist? Heck, yeah. I’ve got them helping me build my company, and it makes all the difference in the world. Do design- or development-savvy entrepreneurs exist? Probably. I’ve got a Mac — does that count?

The goal is to establish a working relationship between the two parties that leverages the strengths of each to quickly and effectively create a product and bring it to market. The tips above should help those working on the creative side. I’d be interested to hear a designer or developer’s take on what I should be doing to get the best out of my creative team. After all, we’ve got to have more in common than liking Fruit Loops for this thing to work.

Go easy on us poor entrepreneurs. I realize we make dumb suggestions sometimes, but it’s just an attempt to maintain some control over a process that we occasionally feel we’ve lost control over. And consider the business decisions that clients make from both sides. We’ve had a lot of practice with this stuff.

Related Articles:

You might be interested in the following related articles:


© Brian Scordato for Smashing Magazine, 2011.

What Makes for a Bad Startup Idea?

What Makes for a Bad Startup Idea?:

Earlier today, I received an email from SpeakerGram, announcing that it was shutting down. The service helped speakers manage their inbound speaking requests:

“We have decided to shut down SpeakerGram. While we are thankful for the support that our users have given us, we have changed our focus to a new product, and need to shift the balance of our energies towards that effort.”

This kind of thing happens to startups all the time. It’s just not something the media reports on because most of these startups don’t reach the name recognition that makes them big stories.

But why was SpeakerGram the wrong idea? Why do thousands of ideas end up in the deadpool? And what makes for a great idea that captivates the masses?

I’ve heard, seen, analyzed and written about thousands of startup ideas over the years, and while the reasons most of those ideas die varies, there are a few consistent themes that I’ve noticed typically signal a doomed idea.

Here’s the short list:

  1. The idea is too narrow: It simply addresses too few people and too small of a market. In SpeakerGram’s case, the issue is that there are just so few people that actually need something to manage their speaking engagements. It’s a very small group of people that engage in significant public speaking.

  2. The idea isn’t fully formed: Many startup founders just come up with an idea, jot it down and start building. The problem is that they haven’t thought the whole thing through before building. Will people actually use it? What are the idea’s flaws? Will it survive against the competition? Don’t start building until you’ve really thought about and addressed these questions.

  3. The idea doesn’t evolve: Ideas need to evolve as the market evolve. If the idea or the team is too rigid, then the project starts to suffer and can’t pivot fast enough to survive.

  4. The vision isn’t ambitious enough: This, above all, is what kills a startup. Big ideas derive from a big vision. Radical product changes are easier to implement if they fall within an ambitious vision that the founders are willing to fight for.

Great ideas take years, not months, to emerge. Facebook wasn’t a billion dollar idea when it launched at Harvard. It became a billion dollar business when it launched the single most important feature in the history of social networking: News Feed.

Very few entrepreneurs nail the idea on the first try. That’s why VCs always say that they prefer to invest in “A” teams with “B” ideas instead of “B” teams with “A” ideas. The “A” team will eventually get its act together and throw for the game-winning touchdown, while the “B” team will get a few first downs before settling for a field goal or fumbling the football.

My advice to anybody with a great startup idea: think it through first. Make sure you ask the hard questions, go through all the scenarios and have a bold vision that can carry the team to the finish line, even when the original idea doesn’t catch fire. A little patience before you jump into the building process will save you from building a product that nobody wants.

Image courtesy of Flickr, Twenty Questions

Sunday, December 25, 2011

FW: Introducing dJAX Adnetwork Package for OpenX



Feed: OpenXservices
Posted on: Sunday, July 03, 2011 1:40 AM
Author: admin
Subject: Introducing dJAX Adnetwork Package for OpenX


A complete adnetwork Setup is possible with simply purchasing a complete package for OpenX. dJAX Adnetwork contains well versed modules and plugins to setup a complete Adnetwork using OpenX. OpenX has been highly successful and it has been used in many advertising platforms and Adnetworks.

Recent addition to OpenX like mJAX mobile ads Plugin has been a huge success as that can simply turn an existing OpenX into a mobile adnetwork.

Mobile ads plugin is also included in dJAX Adnetwork Package. Apart from this, it also contains various innovative ad formats, targeting options, reports & statistics, etc.

Complete details to setup a complete adnetwork can be found here.

View article...

Friday, December 23, 2011

How to Ace the Short, Impromptu Speech

How to Ace the Short, Impromptu Speech:

This article is part of the 12 Days of Ask Six Minutes.
This event is over now, but you can send your questions anytime.

Several readers sent in questions related to impromptu speeches, including Matthias K.:

I’m pretty comfortable when I have days or even weeks to prepare a speech, but I REALLY struggle when I’m asked to speak at a moment’s notice. Do you have any tips for impromptu speaking?

In this article, you’ll find a set of tips that will make you shine the next time you are asked to speak on the spur of the moment.

Impromptu Speech Scenarios

Impromptu speaking may not be as glamorous as prepared speaking, but it is an equally vital skill simply because there are so many scenarios where you find yourself speaking without more than a few moments of preparation. It’s no surprise that “impromptu speaking sessions” are found within Toastmasters meetings, college communications courses, and public speaking seminars.

Consider just a few situations where you find yourself speaking off the cuff:

  • The scheduled speaker is unavailable (or late), and you’ve been asked to fill in.

  • You are sitting on a panel answering questions from the audience.

  • You are fielding questions after your own talk (yes, your Q&A session is impromptu speaking)

  • You are being interviewed on television, radio, webinar, or telephone.

  • You are invited (at the last moment) to say a few words at a company gathering

  • You are asked to provide a brief status report for your project at a department meeting

  • You are motivated to join the debate at the parent association meeting for your child’s school.

  • You decide to give an unplanned toast at an event with family or friends.

It’s also worth noting the irony that the better you are at giving prepared speeches, the more often you will be invited to speak with no time for preparation at all. Your friends and colleagues will recognize your speaking skill, and when they need “someone” to say a few words… you’ll be that someone!

Winning Strategies for Impromptu Speeches

Although you may only have a few seconds to prepare for any particular impromptu situation, you certainly can prepare yourself to be ready when called upon.

Here are a few strategies you can use:

Anticipate situations where you may be called upon to speak. For example, if you are attending an engagement party for a close friend or family member, there’s a reasonable chance that you might be asked to speak. Similarly, if one of your close colleagues is scheduled to speak (e.g. your boss, your peer, or your report), it’s also reasonable to assume that you will find yourself speaking. As you head to the event, do a few mental exercises, trying to guess what you might be asked to speak about, and how you would respond. Even if your guess isn’t accurate, it’s amazing how those prior thoughts will help you think on your feet when you are asked to speak.

Wrap your response around a simple template, or framework. If you practice this a few times, you will find that your mini-speeches are much more polished and coherent. A few easy frameworks include:

  1. P.R.E.P. (Point. Reason. Example. Point) – Start off by clearly stating your point. Share the primary reason (or reasons, if you have more time). Then, share an example (preferably in story form) where your main point or reason is supported. Finally, conclude by summarizing your central point again. The template works well in many situations, and is easily adapted.

  2. Issue, Pros vs. Cons, Conclusions - Start off by framing the issue. Talk about the benefits, and then talk about the drawbacks. Conclude with your recommendation.

  3. 5W – In this pattern, you cover your topic by addressing the Who, What, When, Where, and Why elements. For example, if you’ve been asked to speak briefly about a fundraising initiative, you could talk about [1] who started it, and who is involved now; [2] what the goals are; [3] when it started, and the schedule for the future; [4] where does it take place; and [5] why are you involved. This template works nicely, largely because the “why?” comes last, because this is often the most critical information.

Want to learn more?
Dazzle your audience by leading the perfect Q&A session.

Turn your impromptu session into a Q&A session. In situations where you are asked to fill in when the schedule speaker is absent, it may not be wise to launch into a 45 minute impromptu speech. Even the most accomplished speakers are prone to meander in that situation. Instead, reframe the session as a Q&A session, which breaks it up into a series of very small impromptu speeches that are probably easier for you to answer individually. Plus, the content comes directly from the audience, so you are guaranteed to deliver what they are seeking.

Use personal stories. Storytelling is an essential skill for prepared speaking, but it is equally useful for impromptu speaking as well. Stories are emotional, real, and interesting. If you stick to personal stories, you’ll find that it is much easier to speak (even without preparation) because the events happened to you.

Avoid the tendency to go on, and on, and on. Craft a coherent message, and then be quiet. Rambling on will only weaken your overall speech. If you must fill more time, shift into a Q&A.

Go easy on yourself. We all want to speak perfectly every time, but demanding perfection from yourself in an impromptu speech is setting the bar too high. The audience (probably) recognizes that you’ve been thrown in at the last minute, and they will understand.

Your Turn: What’s Your Opinion?

Do you have any proven strategies for mastering the impromptu speech?

Please share in the comments.

Similar Articles You May Like...

Have a Question?

Contact me anytime,
or find me on Twitter: @6minutes
Follow @6minutes

Andrew Dlugan

Andrew Dlugan is the editor and founder of Six Minutes. He teaches courses, leads seminars, coaches speakers, and strives to avoid Suicide by PowerPoint. He is an award-winning public speaker and speech evaluator. Andrew is a father and husband who resides in British Columbia, Canada.

Author of this article: Andrew Dlugan

Category: Ask Six Minutes, Delivery Techniques, Speechwriting

Article tags: , ,

© Six Minutes, 2011. |
Permalink |
26 comments so far

The Smashing Guide To Moving The Web Forward

The Smashing Guide To Moving The Web Forward:



Many of us rely on open source tools, technologies and standards to help improve the work we do on a daily basis. None of this would however be possible without the hard work, commitment and dedication that others, just like you, have invested in giving back to the Web community over the past two decades.

Modernizr, HTML5 Boilerplate and jQuery are just a few examples of well known projects which were born from a desire to put something out there that could help others on the Web do more. These projects evolved because developers started using them and thought, “Hey, I could do something to help make this better. I bet it could save someone else’s time if I shared this with the world.”

Web standards like CSS3, HTML5 and the foundations of the Web as we know them would also not have been possible without people (just like readers of this post) spending time researching use cases, writing proposals, implementing features and catering to existing and future requirements that could be used by everyone. When you think about it, both standards and open source projects have had a large hand to play in the Web as we know it today.

In this article I’d like to talk about how you can help give back to the Web and a new project that seeks to make this process easier: If you’ve ever thought about contributing to the community but weren’t sure just how, I hope this serves as a good starting point for your journey.

Why Help Move The Web Forward?

In most cases, developers and designers that contribute back do so because of an inherent passion or desire to either improve an open source project, Web standards or the quantity of educational material freely available online.

What you get back from this is (in my opinion) worth every minute of effort.

Contributing to open source projects, you can learn more about the intricacies of programming languages, libraries and standards implementations than you probably could if you were just been a passive user. This can help you gain a better appreciation for how the Web is built, but also improve the quality of the development work you do as a part of your job.

Whilst not the reason most people do it, open source involvement can also often lead to more fulfilling jobs (and occasionally more pay). Demonstrating you have passion (and skills) in a focused area can help highlight you to recruiters at companies where those skills are highly valued.

Finally, involvement can help improve your knowledge, whether it’s simply writing tutorials about standards for others, actually being involved in submitting patches or feature implementations to browser vendors and libraries or contributing to discussions in standards mailing lists (which I’ll discuss in greater detail shortly).

“For me, open source is not about giving back, but its more about being sociable with the developers you admire. I really like forming small groups to work on projects and challenges together, or just like-minded folks that chitchat and passively learn new skills regularly.

The community has given me back great friends and I think we’ve all found more ways to be fulfilled by the work we create.”

 —  Paul Irish, HTML5 Boilerplate, Modernizr, jQuery team


1. What can you do and how much time can you contribute?
Before we look at what you can do to contribute back to the Web, ask yourself three very simple questions: What are your strongest skill-sets? How you might these be used in an open source project? How much time and effort would you like to contribute to giving back?

Understandably, a lot of us have full-time jobs and it can be tricky sometimes trying to fit in extra side-projects into our schedules. The great thing about the Web is that there’s never too little or too much time that you can spend moving it forward.

10 minutes is enough to help someone stuck on a Web-development problem and an hour here or there is enough to greatly improve existing open source projects. If you have the desire to give back, anything is possible.

2. Pick a project or Web standard/specification you would like to work on
Once you have some rough ideas of much time you can contribute, you’ll need to decide on the project, standards group or area you would like to help with. The good news is that there’s a great new initiative to help with this called (MWF), driven by some of the talented people that brought us HTML5 Boilerplate.

MWF is a project that aims to make it easy for anyone to get started contributing to the open source community.

Whether you’re just diving into Web development, or are have been doing it back since tables were cool for layout, there are a number ways for you to give back to the community. MWF makes it easy to help anyone find ways to contribute back to the Web platform by giving you a list of ideas, resources and guides to get you started.

Not sure what projects to look at or where to find lazy-Web requests you can get done in an afternoon? Not a problem. The site breaks down almost all aspects of open source contribution and even separates things based on your level of experience. Regardless of whether you’re a CSS wizard, a JavaScript ninja, or a C++ hacker wanting to play with WebKit there’s something on MWF that everyone can help with.

Don’t see a project that applies to you on there yet? Don’t worry. It’s being updated everyday and other members of the community can submit pull requests to add new things to it. You may also find it helpful reviewing what libraries and technologies you regularly use personally, whether it be a CSS feature like psuedo-selectors or a JavaScript library like Modernizr or jQuery. Beyond the basics, you may have some insights or ideas for how these could be improved in some subtle way.

Do you feel the implementation of a particular feature isn’t quite as usable as it could be? Are there circumstances where a solution just doesn’t give developers everything they need? The learnings you’ve obtained whilst using things on a day to day basis are something you can share with a project to help improve it.

Take a look at each week and if you’re up for it, consider committing to getting a small task done that can push the Web forward.

3. What would you like your role in the project to be?
Most open source projects (and standards groups) have a number of key areas that they require assistance with. In no chronological order these are:

  • Core development

  • Discussions / Mailing lists

  • Documentation

  • Bug submissions triage

  • Operations

  • Testing

  • Site & UI Design

  • Developer Evangelism

  • Support

Depending on the project there may also be areas such as ‘specification writing’ that are necessary in order for features to be discussed before they are implemented.

Core Development

Core development generally involves development of a core set of features, fixes or rewrites for JavaScript libraries, and browser feature implementations or patches when it comes to Web standards.

Whilst beginners won’t generally be directly discouraged from trying to get involved with core development, it’s more often intermediate and advanced users of libraries or features that are better equipped to optimally implement code that is efficient, performs well and passes unit tests.

“I love open source. I’ve been hooked on jQuery since John Resig accepted my first patch in January 2006. It’s been at the center of several profitable projects that I’ve built. Contributing to both jQuery’s code and documentation just seems like the right way to pay that forward.”

 —  Dave Methvin, jQuery team

If you’re interested in getting involved with core development, I suggest spending time familiarizing yourself with:

  • The build/setup instructions for the open source project you wish to contribute to

  • How the project is structured so you can later experiment with making patches and running tests

  • The project contribution guide. Most open source projects these days are hosted on GitHub. This means that filing patches is usually as straight-forward as filing a pull request, but make sure to follow the project’s guidelines on doing this. At jQuery, we require developers to file a ticket in our bug tracker to accompany pull requests but it’s a subtle step that we cover in the contribution guide.

  • Where current contributors congregate to discuss issues, features and patches — with Web standards or libraries this could be a mailing list or an IRC channel. Mozilla has dedicated channels for people wishing to contribute to the MDN as do jQuery and many, many other open source projects.

“Whether you’re contributing to existing projects or open-sourcing projects of your own, giving back to the community is a great way to learn about Cool New Stuff™.”

 —  Mathias Bynens. jsPerf, HTML5 Boilerplate

Discussions & Mailing Lists

Standards Mailing Lists

We all know that Web standards are important. They help ensure the code we write works across different technologies, for people of different abilities and most importantly across all browsers. If you have an interest in pushing the Web forward by getting involved with the standards process, there are a number of different mailing lists you can subscribe to (and participate in) should you have particularly strong feelings about the direction particular technologies or features should be taking.

These mailing lists include public-html, public-webapps, es-discuss, www-style, public-fx and WHATWG. I recommend spending time familiarizing yourself with how contributors to these lists approach discussion as you’ll want to ensure your posts are read rather than ignored – specifically, research proposals, read spec wikis where available and ask other posters for their input offline if you’re unsure about anything.

Note: Chapter 2 of Mark Pilgrim’s HTML5 book contain an excellent discussion of how standards get pushed through mailing lists. It also covers some of the evolution of standards through history and is a recommended read for those interested in grasping how the process works. You can read it for free online here:

The jQuery Standards Team

While many of us would like to see change, the reality is due to time restrictions and lengthy formal processes we’re not always able to participate in standards discussions, get involved with writing specifications and contribute to meetings about the future of features. This can sometimes make it difficult for Web developers to have a voice.

Another problem is that for those that do get involved with the process, it can often feel like participating on a particular thread in standards mailing lists has a limited impact because the Web community is so fragmented. There’s also a lot of assumed knowledge required of existing discussions, decisions and historical context that can make it a little more challenging to get involved.

The jQuery project have set out to try changing this. They want you to have a voice in how the future of the Web is shaped which is why they created the jQuery Standards team. The standards team listens to suggestions or feedback you may have about current specs and if there’s sufficient interest in making changes related to your concerns, they’ll file tickets on your behalf in the appropriate format.

For more information see:

Code/Project Mailing Lists

Mailing lists for code projects (e.g jQuery, Dojo) tend to work quite similarly to those for Web standards. The only real differences are that discussions can sometimes be more fast-paced and generally target the resolution of features or fixes being targeted for a specific library rather than something as broad as a standard.

You don’t have to be someone that implements library code to be able to get involved with these discussions, but it does help having a good level of familiarity with both the library, alternatives to it and the general space being worked on. As per my early suggestion, spend a little time analyzing the best way to jump in with suggestions or ideas to increase the chances of having a positive impact on the conversation.


When most developers think about getting involved with open source, their first thought is usually about writing code that can one day be used by many others.Whilst it’s true that implementations are of course important, documentation is an equally if not more important part of the release process.

Think about it: when you first learn about a new specification that’s been implemented or about some new framework that’s just been released, your first port of call is to look at the documentation or the getting started guide so you can figure out just how to use it. Without this documentation, most projects (and indeed, specs) would be nowhere near as popular or widely used as they are today.

The great thing about documentation is that (unlike full-blown patches or implementations), your contributions can be as small or as large as your time permits. I’ve seen developers contribute simple one line changes to documentation whilst others have provided the equivalent of complete chapters of written docs because they wanted to make it easier for others to understand how everything works. If you’re good at writing, consider giving docs a try.

Writing docs is also a great way to increase your knowledge about how to use the software or tool you’re writing it for. If you feel comfortable using a particular project, consider looking at the bugs files on their trackers. This can offer insight into what confuses users and you can try writing out documentation for such workflows or actions that are unclear.

The barrier of entry is a little lower than core development and there are many well known open source projects that could use your help in this area.

Bug Triage (Issue Moderation)

Most open source projects (including frameworks like Modernizr and browsers such as WebKit) have their own issue or bug trackers. These are typically used as a central location where users can submit issues, feature requests and track the progress of what’s currently being addressed. As projects become more widely used, the number of issues received incrementally grows and there becomes a need for these issues to be moderated. Reasons issues may need to be moderated include being:

  • Invalid
    In many cases, users will simply submit issues with a project or specification without spending enough time debugging their solution. Sorting the invalid tickets from the valid ones makes it easier for core developers to focus on addressing the important ones.

  • Duplicates
    The issue may have been previously submitted. This is easy to discover as the majority of trackers have their own search options.

  • Patch welcome
    Where an issue is acknowledged but is beyond the scope (or time-constraints) of a project to patch itself.

  • Won’t or Can’t fix
    There are issues users may submit which a project may admit is a valid problem, but which may not be currently possible to fix, either due to the direction the project is taking or the broader implications it may have on a codebase.

Moderators are usually required to help narrow down issues to a list of (valid) confirmed issues and feature requests. The great thing about being involved in bug triage is that you’re regularly required to evaluate code samples and establish why a bug may or may not in fact be, valid.

“Contributing to the development of open source software, such as jQuery and Popcorn.js, is my way of ensuring that the future is awesome – in both the things people create and the tools that they’ll use to create them.”

 —  Rick Waldron. jQuery team, Popcorn.js

You’ll often find yourself writing short solutions that address the problem as a workaround and the knowledge you build up from these can greatly help avoid the same problems if you run into them in other projects or at work.


Larger open source projects often have to deal with millions of requests for downloading their library every single day. Even when offering a CDN-hosted version (like we do at jQuery), they still have a large quantity of requests coming in to access their sites, documentation pages and official tutorials. None of these would be able to cope under strain without the hard work that experienced ops people have to offer.

“Being involved in operations has not only given me the opportunity to contribute and sharpen my skills with git, writing tests and streamlining processes, it’s also allowed me to meet some incredibly talented people and make fantastic friends. Contributing to open source has made me better. Period.”

 —  Dan Heberden, jQuery team

Operations (ops) also take care of some of the smaller day to day tasks like granting permissions for new contributors wishing to access different parts of a site, setting up scripts to help automate and streamline tasks and generally ensuring the visible public face of a project stays online. If you have strong ops skills, feel free to reach out to projects (both small and large) as they likely wouldn’t mind some more assistance, either now or at some point in the future.


Implementations of new browser and library features require an extensive amount of testing prior to being released. This covers everything from ensuring 100% unit test coverage is reached, tests are written (or provided) for any patches submitted and where applicable, tests are run across all browsers, environments and devices your particular project targets. If you’re a stiffler for ensuring code is stable prior to being pushed to end-users, you may be interested in helping out with testing efforts. Speak to current contributors to the project to find out their current need for members looking specifically at this area.

Site & UI Design

Did you know that at projects like HTML5 Boilerplate and jQuery, there are dedicated designers that just focus on ensuring site layouts and UI components look at best as possible in every browser? Every open source site or group, from the W3C to JavaScript libraries generally have front-facing websites and it’s often the case that if a redesign or site maintenance isn’t already in the pipe-line, they could use your help.

“Working on open source projects means you have the skills of several people to tap on. It is a great place to learn Web development, creating workflows that work for collaboration. Moreover, it’s safe – it’s not like you’ll get fired for testing things out. The projects I contribute to are directed towards problems I struggled with myself and wish other designers had.”

 —  Divya Manian, HTML5 Boilerplate

Before you approach a project about helping them with any design work, talk to the members to see what their plans are or what they’d ideally like someone to work on. They may ask you to present a mockup of concepts you may have to establish if they’d like to get you involved with their current design team or in taking on your ideas for one of their next versions. A good to strong knowledge of HTML/CSS and a little JavaScript is always useful to have, but even if you just design in Photoshop that’s another piece of work someone else in the community could take further.

Evangelism & Support

The role of technical evangelists varies quite a lot in open source projects. Its goals can include:

  • Supporting developers in the community by providing assistance, answering questions and making it as easy as possible for developers to solve problems they may be running into (doing so via IRC, Twitter or forums is quite common).

  • Working with developers in the community to help understand why particular standards, browsers, libraries or tools should be used and can make developer’s lives easier.

  • Writing tutorials, creating screencasts and building demos that help educate others.

  • Generally speaking on behalf of the project at events to further enhance awareness about the project’s goals and offerings.

  • If you enjoy helping people solve problems or have a passion for writing (but aren’t a big fan of writing documentation), consider giving evangelism a try.

Share Knowledge, Share Experiences and Build New Things

Beyond assisting with the goals of a specific code project or standards working group, there’s a an array of other useful things you could be doing to help push the Web forward.

Many of the most popular open source projects today once started out as tools and workarounds that a developer or designer worked on to satisfy a personal need. If you love hacking on code, please consider sticking your work up on GitHub and sharing it with the rest of the world. There may be many others (just like you) that your work could end up helping or inspiring it’s a great feeling knowing that you’ve saved someone else from dealing with the same headaches you once had to yourself.

Note: GitHub offer a regular free class on the ‘basics’ that you can sign up for. You can also get a free copy of ‘Pro Git’ that covers most of the fundamentals.

Although I’m involved in open source projects, my biggest contribution to the Web is still in my day to day technical writing. Teaching through this medium is a great learning tool and you’ll often find yourself learning more as you write and research about the topics you’re conveying.

Remember that your words can be a very powerful tool for pushing education on the Web forward. For this reason I encourage you to consider writing about what you do and learn — write tutorials, create demos, post gists, write essays.

“After being repeatedly nudged by people to start writing about changes to WebKit and Chromium, which I had been monitoring for a long time already, I wrote my first article back in August 2010.

To date, 64 articles have been published and many more people are aware of and get involved in the implementation of cutting-edge features at both projects. I myself am now part of the Google Chrome and WebKit teams, focusing on improving both the browser as the Web, doing that which I love to do.”

 —  Peter Beverloo, Google Chrome team

Don’t be afraid to make mistakes (because that’s how we all improve). It’s absolutely okay for you to not be a complete expert or authority on a topic. Share what you do know because it has the potential to help many other developers and designers out there. Reach out to others in the community if you don’t know something — ask questions and prompt conversations.

Contribute to the MDN
For those interested in getting involved with writing, it’s okay if you don’t have your own blog. Almost any designer or developer with HTML, CSS or JavaScript skills can also contribute back to the Web through the MDN (Mozilla Developer Network).

The Mozilla Developer Network, also known as MDN.

The MDN is a community of developers building resources to improve the Web, regardless of what browser or platform you’re using. Anyone can contribute to it as the entire site is a wiki (just like Wikipedia). There are sections that detail specs, pages that are just tutorials and others that are just guides to quirks that are useful to be aware of when using particular browser features.

“When I learned about Web standards not much was available out there. The Mozilla Developer Network was one of the first resources I kept going back to when I was stuck. The reason why it still is that way is that it is a living resource that anyone is invited to edit and keep clean.

It is pretty rewarding to be part of this and knowing that what you put on the Web is part of something that by definition is there to keep the Web free, open, and make it easier for the next generation of Web makers not to have to make the same mistakes we did to build something good for the Web.”

 —  Christian Heillman, Mozilla

To give you an example, here’s a page I fleshed out during one of the MDN sprints with (reliable) links to get started with learning Web development: Introduction to Web development. Simple, right? It’s nothing more than an organized page of links, but prior to the new learning section on the MDN site being launched, it helped developers and designers get started with basic fundamentals when they were unsure where to look.

Mozilla evangelists regularly hang out in #mdn on (IRC) and are always happy to help new contributors get started if you have any questions. Consider giving it a try!


That’s it for this guide. I’ll be sure to update it if there’s anything I’ve missed out on, but I hope it inspires others to consider giving back to the Web platform. Remember to check out if you’re interested in picking a task you can start working on today. Together, we can help move the Web forward.

Further Reading

With special thanks to Divya Manian, Nicolas Gallagher and Paul Irish. Images courtesy of the 56 Geeks project.

(vf) (il)

© Addy Osmani for Smashing Magazine, 2011.