I working on an EE site and wanting to use JQuery, but I’m finding a ton of uses for it. This will be my first site using JQuery and I’m not sure if/what the threshold is when it comes to ‘too much.’
For example, I want to use the superfish, rounded corners, and possibly the shadow plugins. Plus the usual show/hide/toggle and some ajax calls. Is there a general rule for this or am I being too conservative?
I would possibly say that it’s not so much “How much” but more will the site still work with Javascript disabled which is more important.
Obviously placing every single spinning whizzing jQuery effect on a page could very quickly give a headache to lots of people but as long as you use it tastefully and ensure that the site still works without Javascript enabled then you will probably be on to a good thing
Since the scripts have to be downloaded, pay close attention to their file size and how it affects the initial load time. Save on file size by using compressed versions of the scripts.
The thing to consider is this: If all you have is a hammer, everything looks like a nail
I love (and use jQuery) myself, but sometimes less is more; always make sure that your site still works with JS turned off i.e. without the bells and whistles.
...always make sure that your site still works with JS turned off i.e. without the bells and whistles.
Does anyone have any stats on what percentage of users (varies according to type of site, naturally) run their browsers with Javascript turned off?
I wonder if it’s worth worrying about. Some jQuery plugins will degrade nicely, others just don’t (can’t?). Is it worth the effort? A similar issue exists when creating a site that runs valid XHTML and CSS. MSIE 5 and Netscape butcher standards-compliant sites, and often, the effort to create a site to fit those users on very outdated browsers reaches a point of diminishing returns rather quickly.
I just checked logs on a site with decent mixed traffic (Windows and Mac) and found some interesting stats: Almost 99-percent of visitors had Flash, in one version or another, over 99.6-percent of those had Flash 8 or above.
Java support (whatever that is… does it really mean ‘Javascript?’) was well over 96-percent. However, for site visitors using Windows and Internet Explorer, 25% were still using IE 6.x, but MSIE 5.x was well less than 1-percent. iPhone and iPod touch were about 1-percent of users.
Assuming screen resolution stats are accurate, what will happen to the 960 grid design in the near future? It took only a few years for sites to move from 760 pixel widths to 960. Only 11-percent of site visitors had screen resolution set to 1024x768 or smaller. Over 80-percent of screens were 1280x800 or larger, which might indicate that the 960 pixel width may be going away.
Some sites want as many visitors as possible to have a decent experience and they’re willing to pay the extra money to extend a site to cover nearly all browsers and all scenarios (Javascript, MSIE 5.x, 6.x, Flash, etc). I am finding more clients who prefer standards compliant design to browser compatibility. I prefer the former, of course, but the billable hours for the latter can be nice.
I am finding more clients who prefer standards compliant design to browser compatibility.
Why should these 2 be mutually exclusive? The whole goal of standards-based web design is to be as compatible with as many devices as possible, it just means you won’t have the exact same experience in every browser/user agent.
Also, this is something to strive for, not some kind of absolute
Why should these 2 be mutually exclusive? The whole goal of standards-based web design is to be as compatible with as many devices as possible, it just means you won’t have the exact same experience in every browser/user agent.
Standards based web design has one big flaw. It doesn’t work with a device that doesn’t adhere to standards.
MSIE, for starters.
In other words, you can’t create a standards compliant—XHTML, CSS, Javascript—site AND have it work on all devices (browsers, and their respective devices; notebooks, desktops, phones, etc.), because those devices do not interpret standards the same way, so the experience varies dramatically at times, which requires additional effort beyond standards, and leaving heavily toward ever diminishing returns.
Also, this is something to strive for, not some kind of absolute.
Agreed, so, back to that most basic issue—how far does one strive to adhere to standards at the expense of users who stick to devices that do not adhere to standards?
Most of us would agree that we no longer both with MSIE 5.x or old Netscape, but MSIE 6.x is still around, taunting designers from an open grave that cannot be filled in (as much as we try, wish, hope).
I’m close to the point where I’m ready to flush MSIE 6 and non-Javascript compliant browsers completely. Well, except for those wonderful billable hours…
I’m close to the point where I’m ready to flush MSIE 6 and non-Javascript compliant browsers completely. Well, except for those wonderful billable hours…
Idunno Ronnie, I’m to the point where I’m paying my clients to accept however-it-turns-out-in-IE6. In the end, I save on money and hair!
...always make sure that your site still works with JS turned off i.e. without the bells and whistles.
Does anyone have any stats on what percentage of users (varies according to type of site, naturally) run their browsers with Javascript turned off?
I wonder if it’s worth worrying about. Some jQuery plugins will degrade nicely, others just don’t (can’t?). Is it worth the effort? A similar issue exists when creating a site that runs valid XHTML and CSS. MSIE 5 and Netscape butcher standards-compliant sites, and often, the effort to create a site to fit those users on very outdated browsers reaches a point of diminishing returns rather quickly.
I just checked logs on a site with decent mixed traffic (Windows and Mac) and found some interesting stats: Almost 99-percent of visitors had Flash, in one version or another, over 99.6-percent of those had Flash 8 or above.
Java support (whatever that is… does it really mean ‘Javascript?’) was well over 96-percent. However, for site visitors using Windows and Internet Explorer, 25% were still using IE 6.x, but MSIE 5.x was well less than 1-percent. iPhone and iPod touch were about 1-percent of users.
Assuming screen resolution stats are accurate, what will happen to the 960 grid design in the near future? It took only a few years for sites to move from 760 pixel widths to 960. Only 11-percent of site visitors had screen resolution set to 1024x768 or smaller. Over 80-percent of screens were 1280x800 or larger, which might indicate that the 960 pixel width may be going away.
Some sites want as many visitors as possible to have a decent experience and they’re willing to pay the extra money to extend a site to cover nearly all browsers and all scenarios (Javascript, MSIE 5.x, 6.x, Flash, etc). I am finding more clients who prefer standards compliant design to browser compatibility. I prefer the former, of course, but the billable hours for the latter can be nice.
Any thoughts?
I use to track this with AWStats and found that less than 3% of my users had it turned off. It’s just not that common. How many sites rely on javascript now days?
This is my take on the Javascript on/off issue: If a user is knowledgeable enough to turn off javascript then they should know that some pages will not appear/act as they should. The only times I have seen javascript turned off is when one designer is judging another designers work (which is stupid, IMO). Plus, if one has javascript turned off chances are your site isn’t the only site they’ve been too that needs javascript to run. Heck, even the national news sites depend on javascript, Flash, and other technologies.
Standards compliance is nice and good and should be followed, but unfortunately some browsers don’t have enough respect for the web to follow these standards. If MS really wanted to, they could have patched IE6 years ago to play nice with standards. Right now I see them (IE6, Microsoft) as the jerk in the back of the classroom who does things just for attention.
With IE6 I am taking the approach of testing to make sure the presentation of content is desirable and the site is browsable(?). Other than that I have a message that shows on top of sites informing the user that they have an outdated browser, the site might not act as expected (all features might not be available) and that they should upgrade (with links to IE7, Firefox, and Opera).
It’s funny, as I went through today designing this site, I had plans to use all these JQuery calls and plugins. Now that I’ve gotten half way through, I’m only using JQuery plugin.
This is my take on the Javascript on/off issue: If a user is knowledgeable enough to turn off javascript then they should know that some pages will not appear/act as they should.
I’m of the opinion that Javascript is as ubiquitous as Flash. True, there are plenty of pundits who decry Flash for all the right sins, but it’s there, it’s everywhere, and, for the most part, it works. It plays stuff.
I think Javascript is equally embedded, too, and though it may carry a few sins, it’s there, it’s everywhere, and, usually, it works.
That’s more than can be said about MSIE 6.x standards rendering ability.
I’ve been digging into jQuery for less than two weeks and find the concept appealing—a single library with lots of functionality, plenty of easily embedded plugins for all sorts of nifty neato effects.
But those plugins add up quickly to the point where Javascripts alone outweigh the size of the page (initially). Then there’s the issue with plugin conflicts, and embedding plugins that are no longer under any kind of development or support, and then just the general complexity of it all—XHTML, CSS, Javascript, EE, and so on.
I haven’t run into plugin conflicts, though I know they exist. But my thoughts are, you’re loading the core libraries anyway, instead of reinventing the wheel for 10 different functions on a site, using jQuery allows it all in a much smaller package.
What I do is load jquery in the header, and the plugins in the body of any page that needs it. So i’m not loading 15 plugins on every page. I break my pages into templates then call them on a page. doing it this way is much cleaner for me. Pages like statistics and graphs will call all the plotting plugin stuff, while image rotations, and other ‘toys’ are loaded on pages that need them.
Some things, like jquery popups I DO load in the header, because they can used everywhere and the script is light if you use the *min* version
I break my pages into templates then call them on a page. doing it this way is much cleaner for me. Pages like statistics and graphs will call all the plotting plugin stuff, while image rotations, and other ‘toys’ are loaded on pages that need them.
I’ve tried to minimize the number of pages to one or two and use all sorts of conditionals to expand the capability of each, but keep coming back to creating multiple template “pages” to do exactly what you describe. It’s just easier to manage, and much easier for someone else to take over and manage. At most, I’ve set up maybe a dozen “pages” on a complex site, and most elements on each page are nothing more than repeating {embeds} anyway, but that method makes it much easier to assign Javascripts to the page it should be on, rather than on every page.
Here is my attempt at being clever regarding this…
I actually do the following for CSS, JS, breadcrumbs, and anything else where it applies.
First, I create an includes folder that handles anything global. All of the JS that applies globally would be put into template(s) with a naming convention of .js_jquery, .js_swfobject, et cetera. For my master css template, .css_global. My HTML fragments are called .html_css, .html_masthead, .html_footer, et cetera. There is one HTML fragment for JS called .html_js which calls in the javascript.
Next, I create a template in my template group and name it “.js_local”. All of the JS that applies to this group is within this JS file.
Finally, I embed {embed=“includes/.html_js”} in all of my templates. This keeps all of the JS nice and tidy between the head tags. This allows me to forget about the inclusion of specific Javascript(s) in individual templates moving forward. With this structure, I can add/delete/modify JS by heading to the .js_local or .js_global templates.
note: If JS applies to two or more template groups, I typically place it in the .js_global file with or without conditionals. Inside the local file, I use conditionals if I want the JS to apply to only one template.
another note: For JS, I use embeds in my includes/.html_js template, but for CSS I use <link rel=“stylesheet” type=“text/css” media=“all” href=”{stylesheet={segment_1}/.css_local}” /> in place of the embeds.
This may seem confusing or extraneous at first, but in my mind, it breaks everything up in manageable pieces that follows the template_group/template structure of EE. I typically avoid embeding other embeds, but I’ve noticed no penalty for this. I’d love to hear from Derek or someone within EE that could actually confirm this. This idea was born out of Derek’s Behind The Curtains II article.
I’m close to the point where I’m ready to flush MSIE 6 and non-Javascript compliant browsers completely. Well, except for those wonderful billable hours…
- It depends entirely on what type of audience you’re building for… My main corporate b2b site (circa 22,000 visits/month according to Google Analytics) had 40% IE6 users last month. I suspect most of those people are locked into IE6 by their IT department… those same IT depts that often block JavaScript and Flash. Ignoring those users would be corporate web suicide…
Java support (whatever that is… does it really mean ‘Javascript?’) was well over 96-percent.
- If you’re refering to Google Analytics, then no - this means Java, not JavaScript… very different. Google Analytics is based on JavaScript, so by definition is unable to tell you how many users have JS disabled. I was at the @media conference earlier this year where some developers from http://www.bbc.co.uk revealed that around 5% of their millions of visitors had JS disabled.
As for jQuery, as e-man says, it should be for bells n whistles - not things like layout or navigation. To minimise the impact of lots of plugins, you should follow the YSlow guidelines… among them:
1. Use the minified and gzipped jquery script from the google library here: http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js - this increases the chance that your visitor might already have the script in his browser cache, and you may also benefit from the parallel downloading capabilities built into browsers when you load page elements from two different domains or sub-domains.
2. Put your scripts at the end of the <body> so that the page can render on screen as soon as possible.
3. Combine all your jQuery plugins into one external file… Bad for maintainability, but very good for speeding up your site…
4. This one’s gold… If you get most of your hits on the home page, it’s really good to cut back on all http requests and stuff all your css into one <style> tag in the <head> and all your JS into one <scr*pt> tag at the end of the <body>. Then you can use some jQuery $.get() ajax calls at the end of the <body> to load the ‘real’ external assets into the user’s cache so that while they are viewing the fully-loaded speedy home page, everything they need for a deeper page view is being silently downloaded in the background. It’s a superb technique (called post-loading) that shaved 3.5 seconds off my home page loading time, despite a fair amount of jQuery.
