While in Seattle for a recent business trip, I spent two nights sampling the local cuisine. I enjoyed each meal immensely, however one clearly stood apart from the other. But why?
Reflecting on the meals, I saw a great deal of parity: each dish was attractive and stylishly plated; each venue offered a friendly, cozy atmosphere; each menu offered a wide assortment of choices, all of which were reasonably priced; each had charming wait staff. So what made the experience of the second restaurant so much better than the first?
As with most things in life, it’s the little things that matter most. Take a water glass for example. A careless server might let it dip quite low or, worse yet, go dry before coming by to refill it. One who cares about your experience will make sure the meniscus never passes the halfway mark. And the best servers will leave you surprised to find the glass you just drank from is filled to the brim yet again.
There’s a lot we, as designers of the web experience, can learn from something as simple as a water glass.
Who is the customer?#section2
As a waiter, you know people come to your table with certain needs and possibly even a few expectations. In most restaurants, the water glass is the first “touch point” or point of contact with the customer. A good first impression is made by filling it quickly, but that’s just the beginning. Some people drink more quickly than others and will require more refills. Some will not drink until they’ve gotten their food. Others may never touch their water at all, perhaps requesting iced tea or some other beverage. When it comes right down to it, you really have no idea what type of person is sitting at your table. And when it becomes a table of four, six, or even ten, it pays to be prepared.
The web is much the same. We make beautiful websites that (hopefully) make a great first impression, but we need to make sure every touch point keeps the promise made in those first crucial seconds or we squander the small amount of goodwill we were in the process of gaining. This type of thinking birthed the concept of progressive enhancement.
On the web, we don’t know anything about the person coming to our website. We don’t know what browser she is using. We don’t know if she is hitting our site from her cell phone. We don’t know if she prefers using her keyboard over her mouse. We don’t know if JavaScript (or even CSS) is enabled in the device she is using. We don’t know if she wants to print the page. We don’t know if she is using a screen reader. We really don’t know anything.
So what do you do when you don’t know anything? Anticipate.
As web developers, we need to be able to meet our users’ needs. And if we’re really sharp, we can do it without them even realizing it.
Like pouring cold water in a customer’s lap#section3
Lala.com is a website built around a community of folks who love music. Its system facilitates the swapping of CDs through the mail within that community.
Figure 1-1. Lala homepage.
I hesitate to call their website (Figure 1-1) attractive, but it is usable…unless you have JavaScript turned off (Figure 1-2).
Figure 1-2. Lala sans JavaScript, circa July 2006.
You gotta love the fact that there’s a “loading” message even though nothing’s loading.
Now granted, that screenshot was taken a bit ago, but in the intervening months since I first began hoisting them as an example of what not to do, all they’ve managed to cobble together is a message (Figure 1-3) reminiscent of those heady days amidst the browser wars.
Figure 1-3. Lala brings back fond memories.
The problem here is not that Lala is using JavaScript, but that they are requiring it. The reason? Well, they apparently like the idea of loading all of the content into their pages using Ajax. In their rush to cram all that Web 2.0 stuff under the hood, they’ve alienated a good portion of Web 1.0 users and a sizable chunk of the mobile market. And they’re not alone.
Consider this: you’re a Lala user and you’re browsing around a record shop and stumble upon the new Arcade Fire album. You didn’t realize it had come out and you want to add it to your Lala wishlist before you forget. If your phone’s browser doesn’t support JavaScript (or you keep it turned off to reduce your download time/usage fees), you’re gonna be staring at a screen with good information about what Lala is (Figure 1-4), followed by that message saying you need JavaScript to use the site.
Figure 1-4. Lala a-no-go.
You’ve got no access to your wish list or anything else on the site. Even the search box (way at the bottom of the page) fails to function. For a closed application or service, this might be acceptable, but for a public website it’s a disaster.
Think before you pour#section4
We’ve already established that as web developers, we’re generally flying blind when it comes to our users’ needs. The best we can do is anticipate what their needs may be and meet those needs at every level, trying to give them the best experience possible. This is where progressive enhancement comes in—we need to think about possible levels of need and how to deliver on each of them.
Level 1: No frills#section5
Some users just want the content. They might be surfing on a mobile device, looking to print out some information, or using some sort of assistive device to browse the web—they may even be browsing with images off. Keeping your markup clean, well-ordered, and semantic is key for this user. They want to consume light, fast-downloading pages without distraction.
Level 2: Make it pretty#section6
Some users like a little window dressing (or a slice of lemon). For them, you can provide a nicely designed and well layed-out website. You could even add a few visual flourishes or a bit of Flash and they will be happy. As long as your design doesn’t confuse the visual hierarchy of the page, you’ve been diligent in your browser testing, and you’ve provided some basic styles for alternate media, you should be golden.
Level 3: Make it sing#section7
Other users may want the full monty. For them you can pull out all the stops and create a marvelous Web 2.Oh-my experience replete with yellow fades, sliding widgets, and Ajax galore.
Keep in mind, however, that levels aren’t always that clearly demarcated. You may need to support an intermediate step between levels one and two, giving Netscape 4.x and IE5/Mac some basic typographic styles and colors. Or you may want to consider offering JavaScript enhancements to browsers as they can handle them, injecting a creamy nougat between levels two and three.
Moving unnoticed#section8
Once you’ve decided on the rough levels of support, you can go about constructing your site.
Start with the content. Sometimes designers and developers forget that this is why people come to your site to begin with. Craft it lovingly and serve it to your users with a minimum of distraction, like a well-plated dish; don’t just heap it all together like it’s a buffet. You worked hard on your content… celebrate it.
Once you’ve got your content in order, you can begin to establish the look and feel of your site. Using the various techniques at your disposal, style your site in a way that reaches your users at their level; hide certain CSS files from older browsers and deliver browser-specific styles to those that need a bit more attention. Conditional comments have been a real boon in this area, but dig out old favorites like @import and specific media combinations, which can allow you to selectively offer some flavor to the folks in older/problematic browsers.
Be sure to consider the presentation of your content in print and on mobile devices. Do you give them layouts or just some basic typographic and color treatments? How do you handle images? Forms? Try to anticipate which features a mobile user would want and streamline the experience for them by removing the cruft. And if you use style :hover on a link, don’t forget to give equal consideration to :focus, keyboard and mobile users will thank you for it.
Once the design is pulled together, add some sparkle with a bit of clever JavaScript. You already know to use object and method detection to determine if a script can run in a user’s browser, but consider how your scripts may interfere with common browser interactions like bookmarking or using the Back button. And don’t forget about script interdependencies either. Will your site become unusable if one script can run and another can’t?
If you’re creating a widget or other interface control, generate the additional markup you need once you’ve determined that the widget can run and everything else is in order. And if you separate your widget-related CSS from your JavaScript like a good little standardista, make sure the styles are not active until the script has indicated that the widget can be used. A good way to do that is to engage in class-swapping (see Table 1).
| Widget | At Rest | Activated |
|---|---|---|
| Tab Interface | .tabbed |
.tabbed-on |
| Auto-submitting Form | .auto-submit |
.auto-submit.active |
Finally, if you plan on using Ajax, use it wisely. There is no need to suck in all of a page’s content via little Ajax calls; it just ends up being yet another roadblock between the user and your content. On top of that, it can lead to <!-- parked domain MAR2013 -->increased overhead on your server<!-- -->, makes your content invisible to search engines, and can render your site <!-- commented out because site wasn't loading MAR2013 -->unusable to someone requiring a screen reader <!-- --> and most people on mobile devices.
Don’t get me wrong, Ajax has its place, but it’s important to know where that place is and even more important to know where it isn’t.
Collect a big tip#section9
Carefully anticipating your users’ needs and addressing them in as stealthy a manner as possible is key to leaving a good impression. As with the water glass, your users should never have to wave you over to be served.
While user experience is extremely important, who the users are is an enormous factor to consider. In Lala’s case, they didn’t necessarily need to use all that flashy Ajax to make their site go; but some sites (like Gmail) would actually be hamstrung if they tried to make concessions for every unique case that came down the pipe. Requiring Javascript is probably not a wise choice, but it’s not devil worship.
Whereas I definitely think we should always make a serious attempt at building web apps without JavaScript, I do think there are cases where the app would be so hamstrung without it that it’s not worth the effort. In these cases, I think it’s perfectly fair to require JavaScript.
We place all sorts of technical requirements on desktop software (RAM, processor, video card, OS, etc.) — so I don’t see why it wouldn’t be okay to do the same with web-based software. Those technical requirements should be as low as feasible for the given app, but if something truly requires JavaScript to be built, then I would suggest it’s fine to require JavaScript rather than simply not building it or dumbing it down (and the same goes for Flash, in my mind). Just the same, if Adobe seriously can’t make Photoshop run in less than 512MB of RAM, then I’d rather than require 512MB of RAM than dumb the product down into something that can fit int 128MB.
All that having been said, Lala is clearly an example of a site that could have been built to work without JavaScript and simply wasn’t, out of pure negligence. That’s not cool.
Good article, but is anyone out there still going to the effort of catering for Netscape 4 or IE5 Mac?
Whilst it is a nice idea to be able to get it right in these browsers, surely the extra coding & kbs required outweighs the benefit for such a small number of users – Time which could be better spent constructing/adding valuable content. (Does anyone have any statistics about how many people are still using these? – my Google Analytics stats show tiny percentages, – much less than 1% – but are probably not all that reliable given that the stats themselves rely on javascript!)
Asking for a Netscape 4 compatibility is a waste of time IMO. Try browsing the web with it and you know what I mean.
For those criticizing the statement about IE5 and Netscape 4, don’t miss the main point of the article. The point is, make sure the websites that you create work, despite varying technologies (or lack thereof) installed on different computers. It may very well be that less than 1% use any given browser, but given high amounts of traffic, that can still be a substantial amount of visitors. Regardless, the writer did not say you always had to cater to these browsers, but that sometimes you may need to.
Also, I can think of very few situations in which javascript is absolutely necessary. So to leave users without javascript unable to use your website is just a little lazy. What if a road were built on which you could not drive a ’55 Chevy? Wouldn’t seem fair, would it?
I’m very taken with the three levels:
-Level 1: No frills
-Level 2: Make it pretty
-Level 3: Make it sing
…I’ve been thinking of a development sequence to apply that ensures all bases are covered at the appropriate time – content drives layout drives style…those three seem to do the trick neatly and concisely.
We can actually learn a lot about our user base through the use of web analytics. In your restaurant example, we could take a detailed accounting (or just make mental notes) of who comes to our restaurant, when they come to eat, what type of food they order, how much they spend, etc. I would be disturbed to find a restaurant profiling its patrons, but that is besides the point.
We can do the same with web analytics; we take a detailed accounting of who is coming to our site, what they are capable of receiving (XHTML, JavaScript, CSS, applets, etc), what they do while at our site, where they come from, where they go to, how much they spend, etc. We may not know very much about the specific user coming to our website (although we do know some things when they arrive), but we can make educated guesses and safe(r) assumptions based on our analysis results.
Jesse,
GMail is probably not the best example. Google 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. Google Docs requires JavaScript because the functionality behind Google Docs requires JavaScript (or another scripting solution, or an applet, etc). I think that’s the key when making hard decisions that could alienate users. We have to ask ourselves, “Does our application/service/site require this to function?” If not, then we should leave it out or do as Google has done with GMail and implement a safety net.
As “Jesse says”:/comments/ruininguserexperience?page=1#1
bq. Requiring Javascript is probably not a wise choice, but its not devil worship.
I couldn’t agree more. I love JavaScript, but I like to see it used _wisely_ as an enhancement.
He (and several others) mentions GMail as an example where a non-JS would hamstring you. As “John points out”:/comments/ruininguserexperience?page=1#8, GMail has a non-Ajax interface, but he brings up Google Docs as another example. I think that closed/subscription applications, like desktop applications, can justify a base level of requirements (think Basecamp too), as I say at the end of my discussion of Lala:
bq. For a closed application or service, this might be acceptable, but for a public website its a disaster.
The key here is _public website_ and I think “Chris’ ’55 Chevy analogy”:/comments/ruininguserexperience?page=1#5 is a good one.
And finally, on the topics of NS4 and IE5/Mac, there are such simple little tricks to allow you to offer some modicum of support (typography, colors, etc.) to these browsers that it seems a shame not to do it. As long as it doesn’t cause conflicts with the modern browsers that are your target, I don’t see the harm. The experience won’t be “hi-fi,” but it’ll be something.
I often use @media=”screen,projection”@ on my linked stylesheets to hide layout-related CSS from NS4 and something as simple as wrapping the filename of an @import in single quotes instead of double will hide a stylesheet from IE5/Mac. The browser filtering eventually becomes just part of your process; in fact, my skeleton XHTML and CSS templates I use for every project are set up in this very way, so it is no extra work for me to offer this sort of staged support.
Finally, “John brings up analytics”:/comments/ruininguserexperience?page=1#7 as another way to get to know your users. I agree that analytics can be very helpful, but unfortunately many popular analytics programs rely heavily (or entirely) on JavaScript to gather this information, so if someone comes without JavaScript on, it may never get logged. If you plan on using analytics as a way to gather this sort of information, always make sure the analytics software supports a non-JS means of gathering this information _and_ that you implement that means.
I can appreciate the article. Knowing your audience is very important, and I’d say that 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.
It’s just my opinion, but designing for non-javascript users is like building a parking lot with a horse barn just in case someone doesn’t have a car. Those users are a niche group and the handful that they are should probably have their own pda version of a site.
I’ve never in my life used a browser that didn’t have javascript.
It’s odd that I would forget that most commercial analytics solutions use JavaScript when here we are discussing the requiring of JavaScript in public web applications!
Brandon: You would be surprised at the estimated number of individuals browsing the web without JavaScript and the empirical number of individuals that I’ve measured on the sites I’ve moderated. Between people using accessibility tools, folks that have turned it off without knowing what it is and people using computers under the charge of overly-paranoid IT managers, there are plenty of these folks to go around.
bq. …designing for non-javascript users is like building a parking lot with a horse barn just in case someone doesn’t have a car. Those users are a niche group and the handful that they are should probably have their own pda version of a site.
I’ve never in my life used a browser that didn’t have javascript.
It doesn’t really matter if _*you’ve*_ never used a browser with no javascript. There are a number of people who don’t. Having JavaScript turned off isn’t like riding a horse instead of a car. It’s like having a car without cruise control. Imagine a highway, or parking lot, that didn’t allow cars without cruise control. *Content* should never be replaced by presentation. There is no reason for any web site to hide (intentionally or not) its information from me simply because I have a technology turned off.
There are lots of people who access the web using screen readers which certainly don’t use JavaScript. And the number of users accessing the Web from mobile phones will become greater than the people using PC’s. In some areas, where PC’s aren’t available, a mobile phone is the *only* way to access the Web.
When I was first learning web design, before I started doing it professionally, I designed sites for IE users only. Even though I was in the majority, I wasn’t the only person out there. So even if *you* never use a browser without javascript, chances are someone else does.
I think the main reason sites such as lala rely so much on Javascript is because today, Javascript is used in the same way Flash used to be used. It can be done and it looks great so Marketing want it. And when Marketing want something, Marketing generally Marketing get it. The fear is that if they don’t use AJAX everywhere, their competitors will and sales will be lost. I think it’s great to encourage web standards, but we need to change the Marketing mindset of these companies.
Using alistapart.com is a great experience (creep!) and it’s a great experience with virtually no AJAX functionality. We need to show more companies how good websites can be created without a reliance on AJAX and then things will hopefully start to change. It’s all well and good inspiring the coders, but they rarely make the final decisions about how the product functions.
I just read somewhere that web 3.0 is really content or words like that. I like the point made in this article and the examples are self-explaining, but this must have been the worse analogy I have read in a long time (and again, very US centred. Try getting service like that in your average French or Dutch restaurant; you won’t. But the food is still great).
On the point of javascript, a lot of large corporations have the habit of letting their proxy servers rip out all javascript from pages served. If your website caters towards professional use within corporations you might find yourself in trouble.
bq. Knowing your audience is very important, and I’d say that 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.
Geeks don’t use Dells. Friends don’t let friends buy Dell. More important, though, you’re guessing. If you’re designing a website whose users are music lovers, are you _sure_ the will never want to use it in a music store?
bq. It’s just my opinion, but designing for non-javascript users is like building a parking lot with a horse barn just in case someone doesn’t have a car.
More like building a parking lot with handicapped parking spaces. Sure, _most_ of your customers will have two good legs, but can you, or any business, afford to turn away the ones who don’t? Or would you make your parking spaces too small to put a SUV in because you’ve never in your life driven anything bigger than a Honda Civic?
bq. Those users are a niche group and the handful that they are should probably have their own pda version of a site.
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. Probably many more that I’ve missed; I need more caffeine.
bq. I’ve never in my life used a browser that didn’t have javascript.
I’ve never in my life owned a SUV, but if I ran a tire store, I’d be a fool not to sell tires for them. It’s not about you.
Commercial website design isn’t about showing off how much you know. It’s not showing off how many “kewl” things you can do. It’s about one thing, and one thing only: Making money move from someone else’s pocket into your own. Whatever makes more of that money move from more pockets is good; whatever impedes the movement of that money, or reduces the number of source pockets, is bad.
For example, if you owned an outdoor goods store, wouldn’t it be a cool idea to have the entrance on the second floor, and have a climbing wall in front to get to it? That would be new! different! unique! But, even leaving out handicapped accessibility requirements (and how much the UPS guy would hate you) do you think any store owner would be that bloody stupid?
Sure, maybe most of the customers would be experienced climbers and would have no problem with the wall. Some might even think it’s fun, not just annoying. But what about the non-climbers shopping for birthday presents for climbers? What about the person who just needs fifty meters of really good rope? What about the person bringing a spouse’s sleeping bag in to get a new zipper? What about the climber with one arm in a cast? For that matter, what about the newspaper reporter coming to do a local business profile on your store? (aka a search engine spider)
How many of those customers can you really afford to turn away at the door?
People don’t use your website to ooh and aah over how kewl your design is. They don’t use it to be impressed with your mastery of the hottest new technologies. They don’t use it to admire how smart you are. They use it to get _their_ stuff done, as quickly, easily, and painlessly as possible. The more experienced on the Web they are, the less impressed they are with glitz and the more they want to just do what they went there for and get it over with. If you put speedbumps in the way of that, whether it’s unnecessary browser requirements, or long load times, or inconvenient navigation systems, or anything else, they’ll go to some other website — namely your competitor’s — where they can just do what they need to do and get back to their lives. And your competitor who knows what it’s all about — who knows it’s about what the customer wants — will eat your lunch.
Great article (and thanks for the plug ;)). I’m with you all the way .. except where you talk favourably about conditional comments.
Conditional comments are HTML hacks, and as such, inherently worse than CSS hacks. HTML is content and therefore sacrosanct, but CSS is design and in a sense arbitrary; CSS is the proper place for hacking.
And they’re not just HTML hacks – they’re proprietary HTML hacks! At best they solve a problem for one vendor only; at worse they’re playing the game by IE’s rules, and that puts even more power in Microsoft’s stable … and they have way too much of that already!
bq. I can appreciate the article. Knowing your audience is very important, and I’d say that 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.
bq. Consider this: you’re a Lala user and you’re browsing around a record shop and stumble upon the new Arcade Fire album. You didn’t realize it had come out and you want to add it to your Lala wishlist before you forget. If your phone’s browser doesn’t support JavaScript (or you keep it turned off to reduce your download time/usage fees), you’re gonna be staring at a screen with good information about what Lala is (Figure 1-4), followed by that message saying you need JavaScript to use the site.
Or were you somehow saying that people who buy shiny new Dells aren’t in the same market as people who shiny buy new cellphones?
I think most of the comments here point to the fact that one cannot assume how someone is viewing your website. That’s the point argued in this article and that’s the bottom line.
I love the approach of building from the ground up. For example. If you build a website with an *edit link* to edit a users details, then apply Javascript on top. The Javascript’s first job will be to remove the link using DOM scripting and then add something like *edit-in-place*. The result is an interface that works well with request/response calls to the server *and* with AJAX. This takes more time but caters for so many more people. All of this involves good design and lots of it.
A point about who we build sites for and why. We need to build sites everyone can use to make money but also to make the web a decent place to be. Catering for all types of people on the web makes life more pleasant for everyone and nobody is excluded. The beauty of web standards is that cowboys are run out of town but who would want them to stay anyway.
*Jeff Croft*:
bq. If Adobe seriously can’t make Photoshop run in less than 512MB of RAM, then I’d rather than require 512MB of RAM than dumb the product down into something that can fit int 128MB
A key difference here is that you can still get older versions of Photoshop that run on 128MB, so you aren’t excluding people altogether.
No-one is saying that *every* last feature of a website has to be made accessible, if there is no realistically sensible way to achieve this without Javascript (or Flash, or any other technology). Yahoo manages to run a cut-down version of its webmail for people on the lower rungs of the technology ladder, giving them access to their email but without all the bells and whistles that other people get.
*Brandon Richards*:
bq. It’s just my opinion, but designing for non-javascript users is like building a parking lot with a horse barn just in case someone doesn’t have a car. Those users are a niche group and the handful that they are should probably have their own pda version of a site.
I’d say it’s more like providing cycle racks than a horse barn. And up and down the country, more and more shops and businesses *are* providing cycle racks in their car parks, in recognition of the importance of welcoming *all* visitors.
There are many reasons why people may be browsing without full Javascript support, and to declare them a niche group unworthy of your time or efforts _without a good reason to do so_ is insufferably arrogant. In the vast majority of cases, there is no good reason why the regular version of a website can’t accommodate those using PDAs/WAP and accessibility technologies, other than laziness and arrogance on behalf of those (ir)responsible for the site.
*Jean McGuire*:
bq. For example, if you owned an outdoor goods store, wouldn’t it be a cool idea to have the entrance on the second floor, and have a climbing wall in front to get to it?
I just want to say thank you for that delightful analogy 🙂
I haven’t made up my mind on the use/don’t use JS argument yet but I am amazed how many sites break with JS turned off. I have been using a FireFox plug-in called NoScript. NoScript disables javascript unless you allow it for a particular site. I can’t tell you how many sites I sat at while the site “Loaded” forever just to remember that I probably need to enable JS for that site. No message, no warning, just eternal loading.
Another point regarding FireFox. There is another plug-in called WebDeveloper that allows you to (among many other things) disable javascript and CSS for a page you are viewing to see how it will render. Very handy.
Using web analytics should help paint the picture of what changes to make and when. I wholeheartedly agree that you should not force large changes on your visitors and completely agree with designing for as many users as possible.
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. (I quit designing for Netscape 4 all together based on the analytics).
And I do not believe that javascript or flash is bad…but in moderation!
http://www.skatterbox.com/2007/03/i-love-jimmy-johns-and-hate-thier.html
In response:
I’m still not convinced.
However, I did mention that if pda peeps are your audience then maybe you should cater to them with their own version, insuring they can take full advantage of your service.
As Luke Newton pointed out, the best bang for your buck is the largest majority of users based upon your stats. Put it in a bell curve and the few outliers will quickly become unimportant and not worth the extra investment to the typical client.
I think the author would make a much more compelling case if he actually showed us a site where he has implemented his methodology.
Lacking an actual example, readers are left to wonder is this is just the usual generic advice that is always easier said than done…
bq. I haven’t made up my mind on the use/don’t use JS argument yet
It’s not whether Javascript is good or bad. It’s good but only if it’s used in the right way – to enhance a site that works just as well without it.
beauti ful Colour combination112
beauti ful Colour combination112
beauti ful Colour combination112
beauti ful Colour combination112
beauti ful Colour combination112
beauti ful Colour combination112
khjkhjkhjkhjk
Godd keep it up
good one
reytrytrhdtrhyrdthydtrhyrt
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
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,
bq. …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?
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.
*@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!
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.
yes really, and i plan to translate it in french with my new kung fu in english 😉
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.
*@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.
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.
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.
Well said, Jean.
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.
bq. 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.
bq. 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
bq. 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?
By designing for people that refuse to move forward with everyone else we’re holding everybody else back! Adapt or die :/
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.
Thanks
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…