[thelist] targeting effectively

[aardvark]

> From: "David Kutcher" <david_kutcher at hotmail.com>
>
> > except that this promotes leaving users out in the cold...
> It promotes targeting.  If I'm a company that doesn't sell products to
> China nor is willing to ship internationally, must I support other
> languages besides English?  Must my site support non-english character
> types?  Or can I make the decision to exclude non-US users?

localization requires development...

coding a site to work for all requires (wait for it) -- *less* development...

less code, less templates, less hacking and fixing...

your analogy doesn't fit...

> > if you built the site to be browser/OS/device/JS independent, it'll
> > still work as
> > new browsers and platforms are released... otherwise, the client has
> > to constantly keep you around to maintain and update their site to
> > work on newer systems, fix bugs, etc...
> So, when Netscape 6 was released, you didn't have to go back and make
> fixes because it failed to adequately support various features?

nope.

cool, huh?

> It's a disservice to create a site that must be completely redesigned
> and developed if the client is ignorant of why the decisions were
> made, but if target specifications are agreed upon, why is this a
> disservice to the client?  It might be a disservice to a user, but the
> company makes the decision whom to target.

and that decision is based on getting accurate, useful information from the
vendor... if the vendor doesn't explain the ramifications of accessibility
caselaw, or doesn't explain how the percentages work across real users, what
good is that decision?

take that 90% number... take a site that does $1million per year in sales...
now tell that client that the site may be *costing* them $100,000 per year in
sales by that lost 10%... that's a few salaries depending on the staff...

ask them that way, see how they respond...

of course, i don't know why you suggest the site would need to be
redesigned... that's what i always end up doing when fixing sites that were
built for specific browsers and features...

> That's the whole purpose of XML/XSLT, styling, and browser/device
> types.  To be able to create a styled page that effectively targets
> that user's device with minimal coding.  It's not MANY templates, it's
> one template with the ability to effectively transform to be displayed
> properly on the user's device.

i use XML/XSLT... i've built all sorts of tools around it... i know how it works...

and guess what?  it's the same damn thing as PHP/ASP/JPS/etc templates
for different browsers...  you may just stuff all the code into one place, but if
you're maintaining multiple outputs from one 'template', you've really got
multiple templates...

if i could create one 'template' to achieve the same goal, with minimal coding
(which is what i do), then what's the issue?  ok, i have less to do to maintain
all the different outputs...

> Is that MY decision or my CLIENT's decision?  If I can prove that the
> site I create for them with javascript, flash, etc. makes them more
> money because it retains their customers better at the expense of the
> few users that are not able to even view their site, then this
> technique worked, did it not?

it's the client's decision... i'm hoping that was a rhetorical question, but
thought i'd answer just in case...

and can you really prove customer retention?  i've found very few people
qualified to prove those assertions based on server logs alone, which leaves
you with market research that might be just as skewed if you're interpreting it
for them...

> If a client makes the determination that they want to expand their
> target audience to include another device, then again, it's another
> styling of the same template, not a recoding of the entire site.
> content != interface. separation of the two and the use of styling
> makes this relatively easy.

yes it does...  content and style shouldn't live together... but you still have to
assess the new browser, make recommendations, find a solution, and
implement it...

i don't...

> Most of the CMS interfaces that I have developed rely HEAVILY on
> javascript. And javascript was the most effective way of creating the
> interface while maintaining a high level of usability.

are you talking about the authoring portion?  if so, you're straying here, since
a controlled audience (ie, you tell them what to use, like an intranet) is a
whole different animal...

but you still said "wow" users... why "wow" users on an intranet?  on a CMS
tool?  why not just make it efficient?

> I think mine have a good idea of whom they want to target and have
> been online and in business long enough to make decisions.  They don't
> see the entire world as their customers, but instead have market
> research that tells them pretty effectively who their customers are
> and how they surf the web. With that information, we target them in
> the most effective way possible because we KNOW who they are and how
> they are surfing.  Moving a company onto the web that is taking the
> buckshot approach (scatter shots as widely as possible) is not what I
> consider a winning proposition.

that argument would work *if* it cost more or was more difficult to *not* leave
users out...

since that's not the case, it's a little hard to swallow...

granted, i have many sites that have enhancements for users, but the site
doesn't blow up on anyone who can't see it... and i still address the audience
determined by research and have the *added* bonus of allowing even *mroe*
people in that were on the fringes of their bell curve...

why *not* do it?