Keeping your web site audience in mind

How simple should a page be?

[grnidone]

Most of my clients are in the agriculture field. I have tried to make my sites with the most basic html 3.2 as possible. I avoid javascript and aim to make my pages as quick to download as possible.

But how far do I need to go? *Someday* I think it would be nice to use javascript and css. At what point can I assume that my audience can handle these more "advanced" features of web design?

Do you guys have a rule of thumb for this?
-G

[oilman]

I assume you have consulted your logs. You should be able to get some idea of what percentage of your audience is using different browsers and operating systems etc. If you watch these numbers for awhile you may be able to see a trend and plan for adding css and stuff when you are reasonable sure that a certain percentage of your audience will be able to see them properly.

[grnidone]

This works if you have decent traffic coming to your site already, but if you don't, is there a way to get that information otherwise?

-G

[rcjordan]

>Do you guys have a rule of thumb for this?
Yes, I do, and I break it daily.

I will not add css, but I'm heavy into js for all kinds of stuff.

Found this out the hard way: Do you know or SUSPECT that there are a lot of laptops accessing your site? If so, better write for NS3.

[oilman]

take a peek over at Web Snapshot [websnapshot.com]. That should give some idea of where things are technologically speaking. I would imagine that your audience is putting up lower number on average.

I'm sure Brett will pop on this thread tonight or tomorrow. He has a lot of experience in the ag arena.

[grnidone]

>take a peek over at Web Snapshot [websnapshot.com].

OH this is BEAUTIFUL.

Thanks, Oil!
:>
-G

[tedster]

>>rcjordan: I will not add css, but I'm heavy into js for all kinds of stuff.<<

I'm curious about why you see such a big difference.

Also, do you try to stick with, say, javascript 1.1? I would think if you get beyond that level, basic CSS support would be almost guaranteed in a browser that supports 1.2 or later.

[Brett_Tabke]

I am just the opposite; I'll add css long before javascript. CSS is about display issues that browsers can resolve in a non-fatal way. Where as javascript is usually about navigation and makes the site unusable for some. If the site becomes unusable for 2-5% of the users, that is unacceptable.

I was just at a site (law.com [law.com]) that denied access based on agent name. I switched agent names and walked right in no problems at all. They just lost a potential longterm user and created a vocal critic at the same time - all because of a clueless webmaster.

Don't trust general browser charts since everyone is running with IE as an agent name these days. Most third party browsers, proxy agents, and web kid filters are being delivered with IE agent name as the default.

I think the line is right there on navigation. As long as you do things with jscript that aren't specific to navigation, you'll be alright. Once you start messing with jscript as a form of navigation, that's when the site breaks down.

[rcjordan]

Let me start with an aside, I'm handling sites that are several thousand pages in size. As Tedster and I have discussed before, the needs of single-handed webmastering for large sites sometimes alters perspective. IF I were handling a site of, say, less that 200 pages, I'd use zero CSS and all JS for navigation would have a redundant path in a more universal format, such as click-maps or text nav bars.

>I'm curious about why you see such a big difference.
It's not so much that I see a difference, I view BOTH css and js as violations of the KISS principle in most instances. BUT, while I can replicate most of the desired effects of css with tag attributes, there are some instances where js actually simplifies navigation for the vast majority of the users without taxing the CPU with dynamic calls. Here's a frame from a site [stateguide.com] that is the best example. (Sorry for the url-drop, I couldn't think of a way to explain it in under 500 words.)

>Also, do you try to stick with, say, javascript 1.1?
Basically, I write to NS3 with js 1.2 for navigation. I figure my traffic losses are 8 percent.

[Brett_Tabke]

Back to your main site as an Ag site; I can't think of another target audience that has a wider distribution of user hardware. There is everything from top-of-the-line dsl, cable, and sat connections, to people running on 2400modems, got Wap phones out of the combine cab. There is also a wide distribution of platforms from pc's, mac's, and dedicated terminal devices like DTN and DataLink terminals (huge). Those dedicated sat boxes like DTN show up as IE, but run a browser that is closer to Lynx (there are 150,000 of those out there and are used heavily since they are so fast).

[tedster]

RC-

One of the difficulties I see with drop-down box JavaScript navigation goes beyond whether the browser is js-enabled. The issue is that the categories are not visible on the page.

When categories are in sight on the page, as in regular HTML nav, they are at least registering in peripheral vision. My feeling is this makes the site stickier. Drop down choices seem a bit "out of sight, out of mind".

Wonder if you have any comments or experience/counter-experience in this area.

[rcjordan]

>The issue is that the categories are not visible on the page.
I tend to agree with you.

In the military base example above, the categories are usually already known to those coming to the page --they are also very limited in number. The js drop-down is really structured to logically replace a simple database sort query. IMO, this was a perfect place to use this type of navigation, but I wouldn't use it for general navigation. In fact, when I use js to write general navigation now, the look harkens back to the old mosaic-style text link panels, I'm just using document.write to do it.