Peter Van Dijck nails it in 2 sentences:

At DEMO, they’re charging US$ 15,000 to do a demo (…). In other words, DEMO is only for VC companies, not web 2.0 companies (who are supposed to do without VC cash, right?).

DEMO’s not the only case of conferences where you need to pay to play, but if the whole thing is about the companies and products, shouldn’t money flow the other way around - or just not between conference and speakers?

Without companies, there would be no conference. Maybe I’m seeing things from the wrong perspective here, but I’d much rather go to an event where companies were invited for their merits instead of the money they can cash out in order to tell me how great they are.

This must have slipped through the cracks on my aggregator some time ago, but the guys at 23 - a photo service similar to Flickr - know how 2.0 should be and don’t mind showing it (even if that means recognizing the value of competition). The proof is that their developer API is based on Flickr’s so that developers can support their application in 2 minutes if they already support Flickr.

Here’s what they have to say on their developer page:

We believe that APIs should be open and non-vendor specific to create a common field for interoperability and competition. It doesn’t make a lot of sense for us to create a “23 API” that can only be used with one service. Therefore we’re actively working with a wide variety of people in the sharing space to create open standards. In the meantime we’ve added support for the Flickr API giving any developer who’s already has spent time implementing the Flikr API a chance to support 23 in 2-3 minutes.

Extremely smart. This move is good for them, developers who want to support more platforms in their applications, and the web in general - we need more people pushing for interoperability of APIs and services. Kudos.

Imagine if this article was written in red. You would hate it. In fact, you’d be so pissed off about it that you’d stop reading. Red means danger, in traffic lights and brake lights. Animals use red to issue warnings and announce their mating season. Red is used to provoke erotic feelings. Red is the color of your blood. Most of all, red means STOP or ERROR.

So, it is a shock to me when companies use red in their websites when displaying success messages (see Technorati screenshots) or in search boxes (see YouTube screenshots). Technorati should be using green, if any color, to show when I’ve just made something right (or when they have, rather), and why should YouTube be coloring my search term in red? Is that supposed to mean I won’t get any results?

Stop being crazy: mind your use of colors in designing web applications. Remember humans associate color with feelings and states of mind - you don’t want to provoke anxiety or stress when showing something went right, do you?

Disclaimer: Even though I’m pointing mistakes in two public websites, the goal is not to mock their design (to be fair, they’re both good) but to point out some (unfortunately common) mistakes in use of color. I use both Technorati and Youtube, know people at both companies, and love their products - you should too. And if you’re really wondering why on earth someone would search for American Idol on YouTube, here’s the explanation.

One of the most important parts of building an application is actually just that - building the application. It follows that particular attention should be given to the process of planning and elaboration of a timeline. Many projects take longer than expected to complete, with never-ending iteratings and constant adding of new features. Ever wondered why that happens? Keep reading.

From an idea to development

You have a great idea, you want to make it into an application. You have a stable picture in your mind of what you want the application to accomplish. You gather a team to build it. You try your best to make sure the picture you have in your mind is passed on to everyone else on the team. You fail, problems ensue.

The planning stage in a development process is constantly overlooked. People assume (particularly in a start-up, loose environment) that planning is unnecessary, a waste of time or (and this is extremely frequent) something that can always be interleaved with development. Truth is, this sort of behavior leeds to the developer’s worst enemy: scope creep.

Defining scope creep

Here’s Wikipedia’s definition of scope creep, as of this writing:

Scope Creep (also called “requirement creep”) in project management refers to uncontrolled changes in a project’s scope. This phenomenon can occur when the scope of a project is not properly defined, documented, and controlled.

Typically, the scope increase consists of either new products or new features of already approved products. Hence, the project team drifts away from its original purpose. Because of one’s tendency focus on only one dimension of a project, scope creep can also result in a project team overrunning its original budget and schedule. As the scope of a project grows, more tasks must be completed at the same cost and in the same time frame as the original series of project tasks.

Fighting the bastard

Fighting scope creep is quite simple, really. Plan, plan, and plan. Make sure you (or your team) and the client know what the intended purpose of the web application is, and that you agree on it - to the finest of detail. Make sure your vision and the client’s vision is one and the same, not the intersection of one-another.

Remember that a project must be built in close connection and discussion with a client, whoever it may be. In fact, even if you’re doing something for yourself, make sure you don’t ask yourself about new features. You’re not experiencing a multiple personality disorder: it is innate for humans to wonder about the “what if’s” of development all the time. “What if I could add this super cool feature?” - Say no, even to yourself, if saying yes will be walking away from the vision.

Putting it together

In sum, scope creep delays projects, messes project budgets, diminuishes developer productivity and ruins client satisfaction. Fighting it is simple - it requires planning, prior to writing the first line of code, to make sure the vision of the application is the same for client and implementor. Agree on the features beforehand, and aim for the same goals. Do it right, and it wont bite you in the butt.

Remember to say no, keep your vision in focus and don’t allow it to blur with “what if’s”. You’ll build better, tighter applications - and you’ll be happier doing it.