[thelist] targeting effectively

[.jeff]

erik,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: Erik Mattheis
>
> A company is revamping their website and is introducing
> a product configuration tool. A solid launch date has
> been set. The development of the product configuration
> part has to start immediately to meet the deadline. It
> also requires a whole bunch of screen space. The design
> of the main site may change again before the product
> configuration tool changes. So it comes down to:
> designing the rest of the site around the tool and
> making the tool smaller that it really should be, or
> requiring JS and doing a pop up window. Or maybe just
> requiring visitors to use their back button and still
> making the configuration tool smaller than it should
> be.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

requiring javascript for the popup window is absolutely ridiculous and unnecessary.  simply using a target attribute you'll get a new window.  oh sure, you don't get a popup with all the chrome tuned the way you want, but so what.  for js users, you can have your fancy-schmancy popup, but not at the expense of accessibility for non-js users.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> Requiring JS is a no-brainer there.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

exactly.  you don't require it.  that's the no-brainer.  it just isn't necessary to require it.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> Some people are going to be irritated and others will
> have to get someone else to help them be able to use
> the site. But the sun will rise the next day, and if
> the other variables fall into place as well, the
> company's bottom line will be greater because the site
> required JS.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i fail to see how using javascript in an exclusionary manner is going to improve the company's bottom line.

all the following scenarios begin with the following:

average joe user encounters your client's site.  he's using a browser that has javascript disabled (his son is paranoid of those sorts of things and turned it off without telling dear old dad).  he sees you offer an online configuration tool.  he eventually finds his way to the page where it can be opened. he finds the link/button to open it, ...

scenario #1

clicks it and, if you've been a careless, bastard developer, nothing happens.  so he clicks it again.  and again.  and again.  eventually he gives up. ...

scenario #2

sees some text below the link/button that says that javascript is required, thinks to himself "wtf is javascript", clicks it, and nothing happens. ...

scenario #3

... clicks it, and is taken to a page telling him javascript is required.  at least you had the decency to code in a way for non-js users to find out what's happening.  so, you explain to him all the neat things javascript can do, why he should turn it on, and how to go about doing that in various browser versions.  joe doesn't know what browser he's using so he hollers at his son to help him.  his son takes one look at the page and mutters something about "those bastards want you to turn on javascript so they can take control of your computer" as he leaves the room fuming.  joe doesn't get the help he needs so ...

and they all end with:

... he makes the assumption that there's something with your site.  after all, links/buttons work on all the other sites he visits so why it doesn't work on your site is beyond him.  his gain, your client's loss.

that's not the end of the scenarios though.  here's one last one with a different ending:

scenario #4

... clicks it, a new window is opened.  joe is disoriented for a second, but then realizes that he now has two browser windows open.  he thinks to himself, "wow, you can have more than one thing running at a time?"  by this time the configuration tool is loaded.  joe plays around a bit, sets up something the way he wants, decides he can't live without it, pulls out his credit card, and buys it right there online.

the difference with this last one is that joe didn't know he could have had a slightly better (in your opinion) experience had javascript been enabled in his browser.  however, he was able to use the site which ultimately led to a purchase.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> > i don't see how less generous budgets equates to JS
> > use...
>
> Other than the above ... another real-life example, my
> first paying project:
>
> I was the only developer they could afford, ...
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

what they can afford and what you were willing to work for doesn't equate to javascript being a shoe-in for smaller budgets.  with the myriad of browsers out there that support javascript at varying levels, i think it'd end up costing more to support a smaller set of users than if you'd done it server-side to begin with.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> ... I was pretty good at JS and only had a vague idea of
> what "backend" meant. They needed to have a searchable
> calendar of events ... I made a JS form that would
> display results by searching JS arrays - and made a tool
> for them to update the arrays themselves. Requiring
> JavaScript was part of the solution.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

and also part of the problem.

i've done my share of javascript powered search engines when i was first starting out.  that's not to say that i'm proud of them though.  knowing what i know now, i would never do that again.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> #1. Company's lone tech, "Snowberry" is a JS and HTML
> whizz but it ends there. They'd like users to see a
> message on their home page when a product is back in
> stock. Best solution: do it with JavaScript.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

how do you figure?  i don't see js being a solution to that at all.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> #2. Xmas eve. Company is offering a discount for orders
> placed before Midnight Pacific time Dec 31. Server is
> screwed, is not serving PHP.  Chip and Rich spent all of
> the 23rd moving static versions of pages from their
> development server to the live production server.
> "Giovanni" from the legal dept goes ape that the
> discount message is going to be listed until at least 8
> am Jan 1 at the earliest. Compromise: A JavaScript
> redirect if it's after Midnight Jan 1 - Chip and Rich
> get to spend the holidays with their families.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

does "giovanni" know that non-js users will still see the discount until 8am?  didn't think so.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> #3. You get to see what the babe looks like naked if you
> punch the monkey. JavaScript to the rescue.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

how does requiring javascript in these scenarios impacting the usability/accessibility of the site?  while i don't see javascript being a solution in most of these scenarios, i don't think that using it is a showstopper.  those without javascript will go on like nothing's missing (provided you did it responsibly).

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> I'm certainly not saying that people shouldn't bother
> expanding their skills/knowledge so that they can make
> their creations work for a larger number of visitors,
> but I am saying that sometimes it's reasonable, even
> applaudable, to say "Welp, I'm very sorry, you need
> JavaScript/browser x/plug-in Y/connection speed Z" to
> a portion of your visitors.
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

understandable coming from a guy who makes a fair amount of his income from the use of flash.  ;p

myself and my clients would prefer to put their message in front of as many users as possible.

.jeff

http://evolt.org/
jeff at members.evolt.org
http://members.evolt.org/jeff/