You’re still thinking in the mentality of "build it with all the bells and whistles first, then think about making a simplified version", whereas I’m talking about the exact opposite.

If the people actually writing your application keep putting this kind of thing in the too hard basket and claiming it will cost more time / money, because they don’t understand how to do it right…

Well if it will cost THEM more time /money

This is a problem I am facing in my new job. I am designing a system, then the developers are claiming it is too hard. What hurts for me is that I know how to do some of the things they want to avoid (for me pretty easily) but for them it is outside their current skillset. Of course they have to build it, and maintain it so we have to make a compromise.

It is the same story as css layouts a couple of years ago, we just have to keep annoying people until they give up and learn how to do it right.

If you’re developing something new, you might want to consider graceful degradation. More and more folks are disabling JavaScript these days than developers think. Believe it or not, my stats are showing a whopping 10%. That’s more than the global usage of Firefox. Degradation is not only a ‘best practice’ - it’s practical and logical. It’s the third element to cross-brower development - because now you’re developing ‘cross-DOM’ compatible.

If your application becomes so ajax rich, it may be better to create an entirely separate application for non-js users. Take for instance Yahoo! mail. There was basically no room for degrading such a large application. Way too much drag and drop, way too much server calls… building a degrading layer would make it run that much slower. So what happens - you get kicked back to Y! mail classic. Excellent idea! Then if you’re not on a modern browser that supports css, we even kick you back to the pre-historic classic Y! mail. This would be known as ‘application fallback’ and Y! does it because they can.

If ajax is built in a modular sense that can be used anywhere in any application, a developer should consider fallbacks for all their little widgets.

So, back to the question "What is our fallback?" - is it:

A) Graceful Degradation B) A separate application C) Unhappy users

I opt not for the unhappy user.

"I use a question "Would I ever want to bookmark this?" to make a quick decision between building a nicely degradable solution or thinking more about it."

Good point. But I think that question is more useful in determining whether or not to use a solution like Ajax at all for the situation. In other words, the answer to that question helps answer the question, "should I use Ajax for this?" The finer question of whether or not that Ajax solution should be degradable should hopefully be a no-brainer. :-)

The point you make and that I completely understand is that this time shouldn’t be looked at as optional, it should be part of the planning just like planning the database schema or graphic design. It’s not the cherry on top, it’s part of the cake.

It would sound absurd to me if someone told me that we must use table layouts and no css because it cost to much time to do it otherwise, so I can level with you on your comments about it not taking longer.

I’m going to let everything simmer for a moment and I’ll get back with you.

I believe most of the time this is an acceptable compromise, but I also have no doubt in my mind that this might not always be the case.

I think we don’t disagree on usefulness or general preference. I think our disagreement is more or less limited to a difference between "always" and "most of the time".

Btw, I use a question "Would I ever want to bookmark this?" to make a quick decision between building a nicely degradable solution or thinking more about it.

"How do we approach clients and say that we can build an application that will work for 95% of your audience, but in order to capture another 3% it will take X amount longer and cost you X amount more."

My point is: it won’t! Unless you can get your head around that fact — that making Ajax degradable or building in accessibility doesn’t cost extra if it’s done from the start — then I’m afraid we are both going to be talking at complete cross purposes.

As for the selling points of CSS and XHTML, I’ve never, ever talked about them with clients: it’s just the way I build websites. They don’t need to be convinced of anything, they certainly don’t want to hear the details of the technology, and it doesn’t cost them any more money than if I used tables and font tags (quite the opposite in fact). It’s the same with degradable JavaScript. The term should really be a tautology: it shouldn’t enter our heads to do it any other way.

"Do you think clients should be made aware of facts like this, or do we just do it transparently and answer questions later on why the application is taking longer to build?"

Justin, Justin, Justin. I’m afraid that once again you are begging the question. You insist on believing that it takes longer to make degradable Ajax apps. That is only true if you haven’t planned the application logic correctly to begin with.

"The fact of the matter is that is does cost time"

That is quite simply not true. Or, at least it’s not true if you consider graceful degradation from the start.

Look, I’ve heard these same arguments before about things like accessibility and usability: Somebody builds a website and then tests it for accessibility; changes need to be made; those changes will take too much time; time is money; the changes aren’t made. Or: Somebody builds a website and then does some usability testing; changes need to be made; those changes will take too much time; time is money, etc.

It’s no different for degradable Ajax. If you come along after the fact and attempt to retrofit graceful degradation, then yes, it will cost you time and money and I can see how that would be a very difficult business decision to justify. But the problem lies with the process. That’s what I’ve been trying to say the whole time. This isn’t an issue of technology or time or money or business decisions. It’s purely about process and planning.

I know in these days of 37 Signals’ "getting real", words like process and planning are used less and less but I think they are incredibly important if you want to avoid incurring time and money penalties further down the line.

When I read post like this I ask myself am I in a state of denial like those who were opposed to CSS and XHTML before it was considered a requirement and not an extra.

CSS and XHTML we’re ways forward, like Ajax and Javascript are now but they are two totally different beast and I think we need more education on the benefits of degrading beyond the point that it’s just the right thing to do.

CSS and XHTML had many good selling points: * Faster page loading/Less bandwidth usage (time and money) * Ability to make 1 change in 1 file and have it applied globally (time and money) * Separation of style and structure (Technical)

I believe we’re approaching accessibility techniques such as degrading Javascript and other techniques like selling candy bars with plain white wrappers and only the ingredients is shown on it. It’s a hard sell to make this way.

How do we approach clients and say that we can build an application that will work for 95% of your audience, but in order to capture another 3% it will take X amount longer and cost you X amount more.

Do you think clients should be made aware of facts like this, or do we just do it transparently and answer questions later on why the application is taking longer to build? The fact of the matter is that is does cost time, and to tell a client that time isn’t money just won’t cut it. It is a business decision in my mind, and I have yet to be convinced other wise.

I appreciate all your efforts and others who are pushing for these techniques, and showing us methods to implement them. Implementation is the easy part, but when your not your own boss you have to have justification.

I’d be interested in hearing your comments on the cookie issue. Do we brute force track ip’s to bypass enhancements that cookies give us?

Kind regards, -Justin

That’s not to say that I’m throwing all my unobtrusive javascript techniques out the window while I build my super secret ajax app….I’ve already adopted those methods as common practice for all the reasons you’ve stated. But I’m only using these techniques because that’s what I’ve become most familiar with.