[thelist] targeting effectively

aardvark roselli at earthlink.net
Mon Mar 25 10:21:27 CST 2002

> From: Erik Mattheis <gozz at gozz.com>
> I read all the splintered threads for the first time all at once, so
> was responding to it as a whole. My point is that if you think about a
> cost/benefit ratio, the right decision is sometimes to do something in
> a way which may ideally should be done otherwise. Maybe a better
> example ... real, to boot:

that's often the case in accelerated timeframes, although it's good
practice to outline the tasks needed to correct the short-term
hacks for phase 2, even if the client never gets there... that way
you and they know the faults and how to fix them, so it's just a
matter of budget...

> 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

i've been down this road... luckily, i was able to remind the client
that users don't see products the same way as they do... that we
could actually break up the entire application and present it
differently so it didn't need to meet their internal expectations, just
those of the user...

> 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.

the JS window can still exist without all the JS-specific code... it
can just open up and submit back to the parent, right?  sure, code
it as a JS pop-up, it'll look better, but you can also make it open for
those not using JS...

> Requiring JS is a no-brainer there. 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 don't know about requiring it... i've seen *lots* of cases where a
developer has said JS is required, but after looking at the code, i've
been able to gut it pretty quickly with no adverse effects...

> Other than the above ... another real-life example, my first paying
> project:
> I was the only developer they could afford, 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.

so, because you didn't know how to do it on the server, JS was the
best solution?  for you to keep the job, yes... but that's about it...

> Other examples:
> #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.

see above... lack of skill doesn't mean a certain language or
technique is the best choice...

had nobody heard of subcontractors?

> #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.

hey, if JS can temporarily fill the gap because of a terribly bad
server environment, go for it... too bad the SEs were indexing the
wrong page...

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

this is a euphemism, right?  *i* don't need JS to do that, just
something with lanolin...

> >  > a 84 year
> >  > old user from the Ozarks who views the web through a mercury
> >  > filling in his molar
> >
> >i wanna meet this guy...  i wanna see what resolution he's running
> >at... and his font sizes...
> Last I heard he was still trying to punch the monkey.

ugh... bad image...

> 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.

on a case-by-case basis, that can happen, but my overall point is
that people assume it's that way *all* the time...

there are many cases where Flash or DHTML is the best way to
present something, but with accessibility laws, browser
differences, and user preferences all over the place, creating a
baseline that works and building up from there is a much more
effective approach than just shutting out x% of users because
"that's what everyone says"...

> >and imagine that poor lonely Ozarkian, probably searching for love on
> >Yahoo personals... *i* wanna be the one to build it, so that poor
> >mercury-ridden soul can get a chance at happiness...
> You would be surprised at how much pleasure he's already getting from
> just the _prospect_ of seeing a real live teen showing ALL! --

punching monkeys...

More information about the thelist mailing list