Copy & paste the code below to embed this comment.
Alex Charalambides
The argument for catering for JavaScript and Non-JavaScript users boils down to not only your target audience but also what is the cost involved in providing for both.
If you know that of your prospective audience, only 2% of your users are Non-JS users, and that it will cost you 25% of your development budget to cater for them, it doesn’t make financial sense to spend time building out a non-JS version. If the number is considerably greater than that, say 15-20% then it does make sense.
The other factor to consider is how big is your user base. If you are a new site starting out you really just want to get the fundamentals right first – structure, navigation, content. If you haven’t nailed these there really is no point in builing out all the aspects of your site until you have.
Yes, yes, yes, this is EXACTLY what people should be doing. Thank you for this article.
A lot of the comments seem to miss the point. The idea isn’t that you write code that works perfectly for everyone. The idea is that you design enhancements which can lay upon one another gracefully.
As one anonymous poster said,
…most people who are swapping albums on the net are probably web geeks, with new shiney dells. I doubt they are using their pda’s.
…
I’ve never in my life used a browser that didn’t have javascript.
Cuz, ya know, web geeks NEVER use pda’s, right? </sarcasm>
If you think that no one doesn’t use Javascript, then you’re forgetting what happens if:
1. A bug slips past QA, throws an error, and your script doesn’t catch it, resulting in your classes not being defined, and everything crashing. Most users don’t notice script errors, since they’re quiet by default.
2. A user is viewing your site from a computer in a bank, or in some other (usually corporate) setting where javascript is disabled by the IT department.
3. They’re one of the 2-3% that turn their Javascript off for whatever reason. (We don’t have to agree or understand, but they do.)
If you think that 2% will never matter, then you’re basically telling yourself that you’ll never work on a high-profile site. 2% of a million people is 20,000 people. What happens if your site is successful, and you make it to 20 million visits a month, or whatever pie-in-the-sky goals you told your venture capitalists?
Layered semantic markup is how web developers plan for success.
Wow, that’s a really great forward. Great minds really do think alike.
It took me two days of racking my brain to come up with that analogy. I find it even more interesting, however, that we each picked up on the concepts of anticipation and levels of service and how they connect the two disparate professions (food service and user experience).
Copy & paste the code below to embed this comment.
Brian LePore
While I agree with the concept of the article, I do feel that it all depends on where a user is located on your site. For the main, live Web site that everyone sees than you should definitely make it work well with CSS/JavaScript off. That said, if you are in an administrative section of the Web site than I do not feel that it is unfair to make requirements such as CSS/JavaScript being on and cookies being enabled. If applicable you should make the OUTPUT of the administrative area completely accessible, but there is nothing wrong in making requirements on your admin. area. Where I work we have a Website builder that has a WYSIWYG editor, image upload tool, etc. that in theory would could spend days/weeks to make it work in a JavaScript-less environment but I do not agree that we should consider that situation. Heck, in the admin. only section I am not opposed to using custom HTML attributes, as long as those attributes aren’t carried over to our clients’ live Web sites.
Great article and excellent message. People forget to be accommodating. The web is about the user (customer), not strictly about the site and developer’s (waiter) wants.
“John brings up admin sections”:/comments/ruininguserexperience?page=4#31, a subject which I glossed over toward the end of my discussion about Lala.com and that has been touched on a bit in the comments here.
I am in complete agreement… in CMSs, closed applications, etc., levels of support should be at the discretion of the developer. Something to think about, however, is whether or not you plan to market the tool and what you see as the target audience for that app.
I see this particularly affecting CMS vendors who may need to make the backend of their application work in any situation (especially if they want to sell their app to government agencies, etc.). In that case, the thing that may set you apart from your competition is such incredible flexibility and attention to accesibility concerns; it could mean the difference between getting the sale and not.
Copy & paste the code below to embed this comment.
Bill Spingarn
What this article completely misses is that intelligently enhancing your site using JavaScript has the potential to increase the efficiency of your visitors. This is important in particular to those of us that design for e-commerce.
It’s all about the conversions.
Let’s say non-JS users represent 5% of traffic. The other 95% allow JS. If JavaScript intelligently enhances the efficiency of JS users to the point where they are more likely to find their product and complete an order, then it will pay off more to use JS than it ever would to exclude it.
However, the only way you will ever know this is to use A/B or multivariate switch testing software that does not rely on JS (obviously). If you don’t, it really is a gamble because sales fluctuate with a million variables beyond anyone’s objective understanding.
Copy & paste the code below to embed this comment.
Jean McGuire
Bill, you have a good point about the tradeoff between greater sales to the JS users vs. a larger target market if you include the non-JS users. But that’s something which is next to impossible to measure. Also, it is difficult to determine the impact of even a single user.
For instance, I have a web page online where I display some extremely inept customer support emails I received from a certain company, annotated with my comments pointing out the more clueless and ridiculous aspects. A lot of people have seen that. A friend passed it around at his work yesterday, and several hundred people in the offending company’s target market wasted work time laughing about how bad the offender’s customer service is. 99% of the customers you turn away might go away quietly, but the one who makes a fuss may carry a lot of leverage.
Someone saying to a friend who’s looking to buy a widget “Don’t bother with UltraWidgetCo’s website, it sucks” is costing you not only the customer you turned away, but the customer you never had a chance to impress. Remember, happy customers might tell someone, but unhappy customers will tell someone.
The answer is in your own post: JS should enhance the site. It should make the already fully functional website work better in some way.
For example, I could write this post without the handy live preview below. Having the preview enhances ALA comments, but it is an improvement layered on top of existing functions. That is good. If I couldn’t comment at all without JS, that would be bad.
Build your website with standards-compliant HTML. Then add the pretties. Your customers, your bottom line, and your search ranking will thank you.
As one of the main developers working on lala.com today, as well as someone who greatly respects ALA, I’m not thrilled to see the site put up as a poster child of ruining the user experience, but your points are valid.
Those without JavaScript include: Cell phone users. PDA users. Blind people (wouldn’t they be a prime market for CD swapping?). Search engines. Internet Explorer users who choose maximum security (a wise choice with IE). Again, because they’re so important, search engines. -Jean McGuire
Exactly, unfortunately. “Ruining the user experience” applies to that entire list.
The truth is that each designer and company will have to determine what and when they are willing to sacrifice usability for added functionality. Its a dance we all do when we build out our sites. – Luke Newton
For better or worse, we’ve made the conscious decision to not cater to these people at the moment. We are building the site for IE6, IE7, Firefox 1.5+, and Safari 2+ on Windows and Mac. We require CSS and Javascript. Our minimum screen resolution is 1024×768.
Not catering to Netscape 4.5 and such, ok, that might make sense. But not cater to search engines? That’s crazy! Yes, it isn’t a fun world. When the website was started in 2005, the then developers decided to move ahead using client-side rendering. This decision has cost us in how we can be crawled and who can use the site, accessibility, etc.
But what have we gained? Well, from a developer’s point of view, coding a site in JS is quite nice. Does that doesn’t equate to an enhanced user experience. If you are in the wrong group you will have a bad/non-experience. As has been pointed out, there are some serious and definite sacrafices. But we also gain in the site’s responsiveness and also in speed of development. If you are a JS-enabled, modern-browser-using user, you will have a better experience than if the site weren’t written the way it is. (That’s my biased contention.)
If lala.com were about something more important, more critical that CD swapping and listening to music, then there is no doubt that we should bite the bullet and switch over to being friendly, if not fully functional, to users of non-JS and/or non-CSS enabled browsers.
We’ve limited our potential userbase, and for better or worse we accept that for now.
I’m really glad to get your perspective on this Alec, thanks for taking the time to respond. I was hoping someone from lala would.
Speaking from a user perspective (and I’ve been using the site for a little over a year now and have traded 200+ CDs), I can honestly say there are good moments and bad ones. I’m not going to write it all here, but I’m happy to talk to you offline if you’re interested. You can reach me by emailing “aaron” at the website linked in my bio.
Though I may not agree with them, I do understand your arguments and the decisions you made; there are always trade-offs in development and you always need to balance long-term vision with short-term priorities. I do not, however, agree with your contention that
If you are a JS-enabled, modern-browser-using user, you will have a better experience than if the site weren’t written the way it is.
I think that a progressively enhanced website could deliver everything that your “modern-browser-using” customers have come to expect without alienating someone who wants to use the service on her mobile. In future articles I will be discussing such techniques.
On a completely unrelated note, I have to ask: are you seeing any sort of performance hit on the server end by doing everything with Ajax? Some people have said that the increased volume of requests has added some extra strain. What has your experience been?
So, by your estimation, Suraj, we should forget about accessibility, interoperability, search engine optimization, mobile devices, and printing the web? You see, it’s not all about backward compatibility, but simply compatibility, period.
You view seems pretty short-sighted for someone who has “adapted.”
Gooooooogle serves a capable non-AJAX GMail solution to user agents that do not support JavaScript. A better example (staying in the same family of apps) is Google Docs.
Copy & paste the code below to embed this comment.
Rob Lammers
Sorry, I just couldn’t let that one go.
A hack is when you exploit rendering flaws in a browser to display alternative code. This is a problem, because you never know how future browsers will interpret it (as everyone found out in IE7).
Conditional Comments, first and foremost… are just comments. Any browser that’s not expecting them will never render them any other way. This makes them a powerful tool in building sites and it’s foolish to overlook them.
Despite your personal feelings, not everything that’s good for Microsoft is bad for everyone else.
I always try to design pages and even JavaScript is used, it’s used rather as extra functionality for existing page. But many people don’t understand it and when you disable JavaScript in your browser you cannot use site at all – you cannot order or buy something in shop because it was designed, that javascript is needed for such actions as adding product to cart.
Unfortunately more and more sites use javascript as something that is needed – in google you won’t login to your account if you disable JavaScript…
55 Reader Comments
Back to the Articlederricktgroupe derricktgroupe
beauti ful Colour combination112
derricktgroupe derricktgroupe
beauti ful Colour combination112
traviskvolk traviskvolk
khjkhjkhjkhjk
traviskvolk traviskvolk
Godd keep it up
traviskvolk traviskvolk
good one
traviskvolk traviskvolk
reytrytrhdtrhyrdthydtrhyrt
makis spyratos
Interesting use of the restaurant example.
Take a look at the Forward I wrote a few years back in our UX methodology. Great minds think alike?
http://www.adjancy.com/UsabilityExperience.pdf
Alex Charalambides
The argument for catering for JavaScript and Non-JavaScript users boils down to not only your target audience but also what is the cost involved in providing for both.
If you know that of your prospective audience, only 2% of your users are Non-JS users, and that it will cost you 25% of your development budget to cater for them, it doesn’t make financial sense to spend time building out a non-JS version. If the number is considerably greater than that, say 15-20% then it does make sense.
The other factor to consider is how big is your user base. If you are a new site starting out you really just want to get the fundamentals right first – structure, navigation, content. If you haven’t nailed these there really is no point in builing out all the aspects of your site until you have.
Isaac Schlueter
Yes, yes, yes, this is EXACTLY what people should be doing. Thank you for this article.
A lot of the comments seem to miss the point. The idea isn’t that you write code that works perfectly for everyone. The idea is that you design enhancements which can lay upon one another gracefully.
As one anonymous poster said,
Cuz, ya know, web geeks NEVER use pda’s, right? </sarcasm>
If you think that no one doesn’t use Javascript, then you’re forgetting what happens if:
1. A bug slips past QA, throws an error, and your script doesn’t catch it, resulting in your classes not being defined, and everything crashing. Most users don’t notice script errors, since they’re quiet by default.
2. A user is viewing your site from a computer in a bank, or in some other (usually corporate) setting where javascript is disabled by the IT department.
3. They’re one of the 2-3% that turn their Javascript off for whatever reason. (We don’t have to agree or understand, but they do.)
If you think that 2% will never matter, then you’re basically telling yourself that you’ll never work on a high-profile site. 2% of a million people is 20,000 people. What happens if your site is successful, and you make it to 20 million visits a month, or whatever pie-in-the-sky goals you told your venture capitalists?
Layered semantic markup is how web developers plan for success.
Aaron Gustafson
@makis:
Wow, that’s a really great forward. Great minds really do think alike.
It took me two days of racking my brain to come up with that analogy. I find it even more interesting, however, that we each picked up on the concepts of anticipation and levels of service and how they connect the two disparate professions (food service and user experience).
Thanks for sharing!
Brian LePore
While I agree with the concept of the article, I do feel that it all depends on where a user is located on your site. For the main, live Web site that everyone sees than you should definitely make it work well with CSS/JavaScript off. That said, if you are in an administrative section of the Web site than I do not feel that it is unfair to make requirements such as CSS/JavaScript being on and cookies being enabled. If applicable you should make the OUTPUT of the administrative area completely accessible, but there is nothing wrong in making requirements on your admin. area. Where I work we have a Website builder that has a WYSIWYG editor, image upload tool, etc. that in theory would could spend days/weeks to make it work in a JavaScript-less environment but I do not agree that we should consider that situation. Heck, in the admin. only section I am not opposed to using custom HTML attributes, as long as those attributes aren’t carried over to our clients’ live Web sites.
bruno bichet
yes really, and i plan to translate it in french with my new kung fu in english ;)
Mike Cherim
Great article and excellent message. People forget to be accommodating. The web is about the user (customer), not strictly about the site and developer’s (waiter) wants.
Aaron Gustafson
“John brings up admin sections”:/comments/ruininguserexperience?page=4#31, a subject which I glossed over toward the end of my discussion about Lala.com and that has been touched on a bit in the comments here.
I am in complete agreement… in CMSs, closed applications, etc., levels of support should be at the discretion of the developer. Something to think about, however, is whether or not you plan to market the tool and what you see as the target audience for that app.
I see this particularly affecting CMS vendors who may need to make the backend of their application work in any situation (especially if they want to sell their app to government agencies, etc.). In that case, the thing that may set you apart from your competition is such incredible flexibility and attention to accesibility concerns; it could mean the difference between getting the sale and not.
Aaron Gustafson
@Jean: I love “your analogy”:/comments/ruininguserexperience?page=2#15.
@bruno: Thanks so much for “offering to translate it”:/comments/ruininguserexperience?page=4#32. Send us the link when you’ve posted it.
Bill Spingarn
What this article completely misses is that intelligently enhancing your site using JavaScript has the potential to increase the efficiency of your visitors. This is important in particular to those of us that design for e-commerce.
It’s all about the conversions.
Let’s say non-JS users represent 5% of traffic. The other 95% allow JS. If JavaScript intelligently enhances the efficiency of JS users to the point where they are more likely to find their product and complete an order, then it will pay off more to use JS than it ever would to exclude it.
However, the only way you will ever know this is to use A/B or multivariate switch testing software that does not rely on JS (obviously). If you don’t, it really is a gamble because sales fluctuate with a million variables beyond anyone’s objective understanding.
Jean McGuire
Bill, you have a good point about the tradeoff between greater sales to the JS users vs. a larger target market if you include the non-JS users. But that’s something which is next to impossible to measure. Also, it is difficult to determine the impact of even a single user.
For instance, I have a web page online where I display some extremely inept customer support emails I received from a certain company, annotated with my comments pointing out the more clueless and ridiculous aspects. A lot of people have seen that. A friend passed it around at his work yesterday, and several hundred people in the offending company’s target market wasted work time laughing about how bad the offender’s customer service is. 99% of the customers you turn away might go away quietly, but the one who makes a fuss may carry a lot of leverage.
Someone saying to a friend who’s looking to buy a widget “Don’t bother with UltraWidgetCo’s website, it sucks” is costing you not only the customer you turned away, but the customer you never had a chance to impress. Remember, happy customers might tell someone, but unhappy customers will tell someone.
The answer is in your own post: JS should enhance the site. It should make the already fully functional website work better in some way.
For example, I could write this post without the handy live preview below. Having the preview enhances ALA comments, but it is an improvement layered on top of existing functions. That is good. If I couldn’t comment at all without JS, that would be bad.
Build your website with standards-compliant HTML. Then add the pretties. Your customers, your bottom line, and your search ranking will thank you.
Aaron Gustafson
Well said, Jean.
Alec Reitter
As one of the main developers working on lala.com today, as well as someone who greatly respects ALA, I’m not thrilled to see the site put up as a poster child of ruining the user experience, but your points are valid.
Exactly, unfortunately. “Ruining the user experience” applies to that entire list.
For better or worse, we’ve made the conscious decision to not cater to these people at the moment. We are building the site for IE6, IE7, Firefox 1.5+, and Safari 2+ on Windows and Mac. We require CSS and Javascript. Our minimum screen resolution is 1024×768.
Not catering to Netscape 4.5 and such, ok, that might make sense. But not cater to search engines? That’s crazy! Yes, it isn’t a fun world. When the website was started in 2005, the then developers decided to move ahead using client-side rendering. This decision has cost us in how we can be crawled and who can use the site, accessibility, etc.
But what have we gained? Well, from a developer’s point of view, coding a site in JS is quite nice. Does that doesn’t equate to an enhanced user experience. If you are in the wrong group you will have a bad/non-experience. As has been pointed out, there are some serious and definite sacrafices. But we also gain in the site’s responsiveness and also in speed of development. If you are a JS-enabled, modern-browser-using user, you will have a better experience than if the site weren’t written the way it is. (That’s my biased contention.)
If lala.com were about something more important, more critical that CD swapping and listening to music, then there is no doubt that we should bite the bullet and switch over to being friendly, if not fully functional, to users of non-JS and/or non-CSS enabled browsers.
We’ve limited our potential userbase, and for better or worse we accept that for now.
Aaron Gustafson
I’m really glad to get your perspective on this Alec, thanks for taking the time to respond. I was hoping someone from lala would.
Speaking from a user perspective (and I’ve been using the site for a little over a year now and have traded 200+ CDs), I can honestly say there are good moments and bad ones. I’m not going to write it all here, but I’m happy to talk to you offline if you’re interested. You can reach me by emailing “aaron” at the website linked in my bio.
Though I may not agree with them, I do understand your arguments and the decisions you made; there are always trade-offs in development and you always need to balance long-term vision with short-term priorities. I do not, however, agree with your contention that
I think that a progressively enhanced website could deliver everything that your “modern-browser-using” customers have come to expect without alienating someone who wants to use the service on her mobile. In future articles I will be discussing such techniques.
On a completely unrelated note, I have to ask: are you seeing any sort of performance hit on the server end by doing everything with Ajax? Some people have said that the increased volume of requests has added some extra strain. What has your experience been?
Suraj Bharath
By designing for people that refuse to move forward with everyone else we’re holding everybody else back! Adapt or die :/
Aaron Gustafson
So, by your estimation, Suraj, we should forget about accessibility, interoperability, search engine optimization, mobile devices, and printing the web? You see, it’s not all about backward compatibility, but simply compatibility, period.
You view seems pretty short-sighted for someone who has “adapted.”
Murat Isik
Gooooooogle serves a capable non-AJAX GMail solution to user agents that do not support JavaScript. A better example (staying in the same family of apps) is Google Docs.
Thanks
Rob Lammers
Sorry, I just couldn’t let that one go.
A hack is when you exploit rendering flaws in a browser to display alternative code. This is a problem, because you never know how future browsers will interpret it (as everyone found out in IE7).
Conditional Comments, first and foremost… are just comments. Any browser that’s not expecting them will never render them any other way. This makes them a powerful tool in building sites and it’s foolish to overlook them.
Despite your personal feelings, not everything that’s good for Microsoft is bad for everyone else.
Marcin Nabiałek
I always try to design pages and even JavaScript is used, it’s used rather as extra functionality for existing page. But many people don’t understand it and when you disable JavaScript in your browser you cannot use site at all – you cannot order or buy something in shop because it was designed, that javascript is needed for such actions as adding product to cart.
Unfortunately more and more sites use javascript as something that is needed – in google you won’t login to your account if you disable JavaScript…