Archive: April, 2006

The idea guaranteed to fail in meetings with any client is a message board. Companies in general fear public dissent from real people. They say things like, "So if we ship the wrong thing, or our customer has a bad service experience – then everyone in the community is going to hear about it? That’s bad." No, that’s good.

The reason they don’t like the idea is that they spend so much money on advertising, telling people how awesome they are – they don’t want to build a platform that will allow real people to compromise that illusion. But why? If you’re doing nothing wrong, people won’t have anything to complain about – and if you are doing something wrong then don’t you want to know about it so you can fix it? In my opinion a community where your customers rule is a must for any business going for perfection. Communities are human business debuggers. Why not know the problems, address them and prove that they’re fixed all in public? The idea is pure genius.

Okay let’s not get carried away. Many people use the word ‘community’ when talking about websites, but let’s define exactly what we’re talking about here. On Dictionary.com the word ‘community’ has the following definition:

com·mu·ni·ty
n. pl. com·mu·ni·ties

1. A group of people living in the same locality and under the same government.
2. The district or locality in which such a group lives.
3. A group of people having common interests: the scientific community; the international business community.
4. A group viewed as forming a distinct segment of society: the gay community; the community of color.
5. Similarity or identity: a community of interests.
6. Sharing, participation, and fellowship.
7. Society as a whole; the public.

To be honest, there was more to the definition but it went on to cover ecology so until plants learn to type we’ll leave it there.

From my point of view what defines community is interaction. Just being part of a society doesn’t mean that you interact with the rest of the people in that group. For me it’s the interaction that turns a group of people into a community.

Do you have a community or just a customer base?

Many site owners claim they have a community but all they have is a customer base. It’s easy to see the difference between the two if you think of them in the following terms. Imagine that your brand is a planet with both satellites and asteroids orbiting around it. What the satellites and asteroids have in common is the orbit – a relationship with the brand. What’s different is that the satellite can communicate with both the planet and other satellites. An asteroid just sits alone, only aware of the planet it orbits.

If your customers are like the asteroid they can float into your brand’s orbit with minor disturbance – and float right back out again. That’s a pretty weak relationship; don’t you think?

Is your business ‘community compatible’?

Let’s get one thing straight, a community-based business model is not good for everyone. Some businesses are not in a position to apply the model, nor should they try.

I was recently speaking at MIT with Jake and Jacob of skinnyCorp on the topic of User Innovation. We were talking to a small group of people who represented some pretty big businesses. The Jakes and I were approached by a couple of representatives from a large food manufacturer. They were interested in picking our brains on how they could apply user innovation as part of a community to help them decide which foods should come out next and help brain-storm ideas for new foods. After speaking with them for a while, I was still unsure whether the community model would actually work for their company – regardless of intention.

I imagined them walking into a boardroom and telling their boss that they will no longer have the authority to make decisions without the participation and agreement of their customer base. I could almost see the fury on the boss’s face from there.

Indeed most companies wouldn’t trust their customers to make important decisions either. Yet in my opinion how can a company expect to have a relationship with their customers without truly trusting them? The missing link for the food company was trust. If you don’t trust your customers then you won’t be able to build a community. It’s as simple as that.

A community is not just for Christmas…

It’s very important that you determine whether your business is truly community compatible. Because once you start, stopping is not an option. Building a community and then withdrawing from it will compromise the trust that glues your community together. And that will cause irreparable damage.

While attending the CustomerMade Conference in Copenhagen recently, I listened to a presentation by Paul Gerhardt, Joint-Director of the BBC Creative Archive. His presentation was about a program the BBC has whereby they allow free access for non-commercial purposes to medium-resolution versions of all of their original video content for use by the public. Needless to say, this is a huge deal. The program was in response to the overwhelming (possibly illegal) use of their material by artists and VJs in the UK. (Read the press release about the BBC Creative Archive). Mr. Gerhardt referenced the loyal, trusting audience of adults in the UK who were happy that their children had access to this. Someone asked Mr. Gerhardt what would happen if there was an overwhelming use of the material in a fashion that wasn’t inline with BBC’s values. The response? Essentially that they would consider pulling the program. Whoa! Hold up. Pull the program? A move like that could seriously compromise the trust of the program’s community who also happen to be the future loyal, trusting, adult BBC audience.

Granted, the BBC Creative Archive is still a hugely successful project and will most likely continue stay that way. It’s an important example though, because once you make the decision to create a community extension to your business, be aware that if you remove it the potential for damage is extremely high.

Pros and cons of community

Communities are an amazing entity to revolve your business around. They help take the guesswork out of business and product development, because if you want to know what it is that your customers want – simply ask. Furthermore, not only do your customers tell you exactly what they want, they essentially create and perpetuate the market for you. Community building is not just about slapping a mesageboard on your site, there are all kinds of inventive ways to get your customers involved in your business. FedEx for example introduced the ‘track your package’ service which enables users to see where their package is at any given moment. The transparent nature of FedEx’s shipping is a brilliant move that has been copied by others – it also makes the customer feel empowered.

There are downsides of course. It’s all very nice to get cosy with your customers but they may have unfavorable things to say about you and your service. The success of your community is a matter of your flexibility and ultimately depends on whether your business is truly ‘community compatible.’ Communities aren’t an ‘add-on’, like a plug-in for Photoshop. You can’t expect that by simply adding community features to your site your success is guaranteed. You have to think about how your customers want to connect with you, or indeed if they want to at all.

It’s also a scary ride. By allowing a community to be responsible for your development you’re essentially putting yourself in the passenger seat of your own vehicle. You can suggest where you would like to go, but ultimately the direction you go is not up to you. This can lead to a potential issue if your business becomes something you didn’t intend it to be. Or it can mean that you end up somewhere that is fantastic for your business – somewhere you would have never reached alone.

Links

If you’re interested in learning more about user innovation and customer co-creation, I recommend starting with the links below.

1. User Innovation
2. Customer Co-Creation
3. Eric von Hippel is an expert on these subjects. His books are available for free online via Creative Commons license

Part Two:
Jeffrey’s next article will delve deeper into the topic of community. He will talk about ideas for integrating simple community features into your business, and also how skinnyCorp built a successful community-based business.

Download the MP3 (6.6 MB)

In this 12 minute audio training clip, David Heinemeier Hansson (37Signals & Ruby on Rails) discusses how Ruby on Rails makes coding easier, quicker and happier, by creating common conventions.

This session is from the 1-day event The Future of Web Apps, hosted by Carson Workshops.

CSS has experienced a colourful and unusual history. From historic slow adoption to the current slow rate of development, ugly hacks have meant filling in the gaps is par for the course.

With CSS1, we had a simple and elegant styling language that was supposed to be friendly to even non-programmers. Hence decisions like, say, lack of variables and constants, or conditional logic. (My kingdom for an “if” statement!)

Then CSS2 came along and provided us with some powerful layout tools. Except some browsers completely disagreed on how to implement them (the box model and floats are two examples that come to mind). Us web designers took care of that problem however, thanks to our lovely CSS hacks and filters. Using perfectly valid CSS, we were able to exploit a browser’s parsing error and specifically serve (or hide) our CSS to it. Problem solved. Lucky us.

But now that Internet Explorer 7 is looming, we’re getting ready to deal with the first really major upgrade to a browser’s rendering engine since we’ve started using CSS-based layouts in earnest. (The launch of Safari didn’t really count, since it was so capable right out of the gate.) The truth is that when IE 7 comes most of our usual hacking methods are going to fail. Afraid yet?

Here’s the nasty little secret of CSS-based development over the past few years: we’ve had a stable target. Because of IE6’s limitations, we’ve been fairly conservative in our usage. There’s really no such thing as cutting-edge CSS, since the CSS2 spec has been final since the late 90’s and CSS3 is off somewhere in the future. Anything we’ve done to date has been able to degrade as gracefully as possible in IE, so we’ve held back on even the more interesting bits of CSS2.

Sure, there are great advanced demos in the form of the CSS Playground, or CSS/edge, or even various CSS Zen Garden designs. But for production-based sites that we create for clients? Conservative CSS use has reigned supreme.

Except … some of us have been a little more than liberal in our hack usage, haven’t we? You might argue that those hacks were necessary to make any sense of the messy browser landscape we were presented with. At the end of a long day of coding, loading that beautiful new site in Internet Explorer has always been a soul-crushing experience. Almost none of us want to spend the time necessary to wrap our minds around just how on earth IE has decided to mangle our code. A few dashes of “* html” [1] here or “_width” [2] there and the problem goes away. The short term fix we applied three years ago, however, now threatens to come back and bite us in the rear.

Conditional Comments

IE7 will fix a lot of traditional CSS hacks. The Internet Explorer team has publicly expressed disapproval of the whole idea of hacks, in favour of an IE-proprietary method known as conditional comments. Instead of code like this to filter a rule to Win/IE:

* html #selector {
	width: 100px;
}

We should instead be using an HTML comment syntax to selectively serve up a link to an external CSS file, which will contain a similar rule. The syntax looks like so

<!--[if IE]>
	<link rel="stylesheet" href="ie-specific-file.css" />
<![endif]-->

And then the IE-specific CSS file in question might contain the following rule:

#selector {
	width: 100px;
}

In theory, this system works much better than CSS hacks ever did. Instead of specifically exploiting bugs in a browser, bugs that will obviously one day get fixed, conditional comments are an officially-sanctioned feature of the browser that won’t ever go away. They validate, and even though they’re proprietary, when used with discretion they allow us to accomplish exactly the same thing as CSS hacks.

Sidebar

The question is begged, of course: why are conditional comments implemented only in HTML, and not in CSS? I have it on good word this is something the IE team may look into for future releases. For now, we must place our conditional comments in our HTML files.

Future Updates

But this is simply one single browser updating, and there’s a larger issue here which we’re going to have to start thinking about sooner or later. I’d prefer sooner.

All popular browsers are improving at a frequent clip again. We’re not stagnating anymore; the improvements are going to keep coming. CSS3 isn’t finished yet, but various modules of it are being implemented already. The future is just around the corner.

As the modern browsers update, in what other interesting and creative ways will our code break? How are we going to test them? How are we going to selectively serve up code to various versions?

Take Safari. Version 2.0 was recently released. Apple has no provision for installing and running multiple versions side by side however, much the same as Microsoft has always done with Internet Explorer.

The practical implication here is that I simply can’t test my work in Safari 1.0 any longer. How do we test now, without needing to own a separate computer for each individual version of a browser? Microsoft suggests we buy Virtual PC and multiple Windows licenses to maintain multiple versions of IE (more of my thoughts on that here), an expensive proposition. Apple hasn’t suggested anything.

Causing web developers to buy more software and hardware simply to test seems an unlikely scenario; but somehow, test we must.

Versioning

And the problem will amplify over time, as more incremental updates are released, and the browser share fragments. In one sense this won’t be 1998 all over again with its 85 different versions of Netscape 4, thanks to browser auto-updating keeping most users current. But, not every user will keep up to date. I can’t count how many times I ignore the update nag message on my own machine, so they can hardly be blamed.

What are the odds that all those early adopters of Firefox 1.0 or 1.2 have kept updating, and made it to version 1.5? Likely not as high as we’d hope. Are we going to continue testing in each of them? How will we fix rendering issues that affect 1.0 and 1.2, but not 1.5? No CSS hack I’m aware of can address that discrepency.

Now, let’s be clear. Ever since CSS1, there’s been a very simple versioning control built into the language. If a browser can’t understand a selector or a rule, it simply ignores it. The theory being, as browsers add new support for a particular CSS property or selector, they’ll simply start rendering the rule they previously ignored all along.

Hasn’t worked out so well, has it? One fatal flaw of this method is that it assumes that support for new selectors and properties will be perfect from the start. Need I even get into the problems that have resulted in browser implementation errors? Box model, anyone?

The other, more subtle flaw in this method is that it assumes the fallback is good enough. Simply not rendering a rule due to lack of support, however, causes adverse side effects in styles that depend on that rule. Side effects that can translate into major usability problems for your site’s visitors.

The most obvious example I can give you lies within the CSS3 “text-shadow” property, which is supported only by Safari at the moment. By using the drop shadow as an outline, we can do things previously impossible, like set white text on a white background.

To the left, you see the results in Safari; a perfectly legible pairing. To the right, you see almost nothing at all. This is what the text looks like in every other major browser, since they ignore the “text-shadow” property.

Is just ignoring the unsupported property a good enough fallback? Not in this case, and there are other potential problems in this vein. Point being, this all-or-nothing method of managing change simply doesn’t cut it. We need browser-specific filtration, to account for scenarios where the fallback causes more harm than good.

“A standard is a standard – you should be able to render the same code consistently in every browser,” I hear some cry. “Browser-specific authoring is a dead end.” And they have my emphatic agreement. I’d love it if the real world proved that were the case. But it’s not.

Legitimate Hack Use

No matter how browsers evolve over the next few years, one thing seems relatively safe to predict – there will always be differing levels of support for web standards, whether it be a difference in rendering between major browsers, or even between various versions of the same browser.

The legitimate need for hacks arose as we discovered major browser bugs that prevented us from adopting CSS in the first place; through the use of hacks, we were able to specifically target versions of browsers and force them to comply. Even those on the W3C CSS working group recognize the need for page authors to work around these bugs; wasn’t it Tantek Çelik who gave us the Box Model Hack, after all?

But our CSS hacks are meant for an older set of browsers that will become less relevant in the near future; we don’t have any new mechanisms for filtering the current stable of browsers. How will we deal with browser discrepancies going forward, in light of potential usability problems?

Coping

I see a few ways.

1. Limit yourself to only those CSS properties and selectors that you know will work across all browsers without fail. In fact, you don’t even have to wait for this, you can start today. Sure, it’s frustrating when all browsers but a single one render on your intended effect, but we’ve pretty well gotten used to that with things like “:hover” support on non-anchor elements. So, hang on to that patience, because you’ll need it.
2. Perhaps this may not even be an issue. If all browsers continually improve, and we never see another repeat of Internet Explorer’s stagnation over the past 5 years, then we simply need to be patient until the effects we seek become practical, and with any luck that won’t be long.
3. We could discover a whole new bag of hacks and filters. With the number of people hacking away at CSS these days, the chances aren’t small that sooner or later we’ll be able to exploit other bugs in other browsers, and get ourselves right back into this situation. I think a lot of people would prefer we didn’t go this route again, but it’s almost inevitable that sooner or later, the first IE7 and Firefox 1.0 hacks will rear their heads.
4. Let’s think pie-in-the-sky here: we could get a bit of recognition that this problem is legitimate, and an official W3C-sanctioned method of browser filtration. I suspect the browser manufacturers are well aware that this is a problem; the IE team has given us a method for filtering out their own browser in the form of conditional comments, after all. Suggestions for codifying a similar method within CSS have been made to the CSS working group many times over the years, and I have it on good authority that there has been at least one formal proposal made in the past on the subject, but as far as I know, nothing has developed from either.

The danger in going this route echos what we learned about HTTP user agent strings in the late 90’s, of course. Crappy browsers will force page authors to filter them somehow. Crappy filtering will cause browsers to pose as each other. Maybe it would be better this time around, since the base technologies have matured a little bit. Maybe it wouldn’t.

The Reality

So what do I think is actually going to happen moving forward? Quite likely, a bit of everything.

Many will certainly follow the path of least resistance and simply limit themselves to code that works cross-browser. Others won’t settle for the status quo, and instead will look high and low for new hacks that target specific versions of specific browsers.

And maybe, just maybe, we’ll get a reliable method of filtering on a per-browser basis. I’m not holding my breath on that last one, but stranger things have happened.

Notes

1. The Tan Hack, or * html bug as it’s also known, causes only IE to parse the CSS within the selector to which it’s applied. It will be fixed in IE7.
2. The underscore hack causes only IE to parse the CSS within the rule to which it’s applied. It also will be fixed in IE7.