|
|
Posted by Erwin Moller on 02/23/07 14:42
Jerry Stuckle wrote:
> Erwin Moller wrote:
>> Jerry Stuckle wrote:
>>
>> <snip>
>>>>
>>>> In defense for JavaScript: My *personal experience* is that a lot of my
>>>> customers prefer the sexy behaviour a site gets with javascript above
>>>> better compatibility (= JS disabled).
>>>> Also: It takes a lot more developmenttime in realworld situation to
>>>> make a 'double site': one for JS enabled, one for disabled. And not all
>>>> want to pay for that, and settle for JS only site.
>>> You don't need to have two sites. JS should enhance a page - but not be
>>> required to use it.
>>
>> Hi Jerry,
>>
>> Of course you don't need 2 seperate sites.
>> I know that. I I think you know I know. :-)
>> That is why I wrote 'double site' between the ''.
>> My point is simply that making sites work in both situations can take a
>> lot more effort in some situations.
>> And I am not refering to trivial checks like somebody filled in a certain
>> field in a form. That is a breeze of course, and should be checked
>> serverside anyway.
>>
>
> But a lot of people would take "double site" to mean two separate copies
> of each page - one with JS enabled and one without.
My bad.
That happens when Dutch guys think they mastered english enough. ;-)
>
>>
>>>> I simple say at the homepage/entrancepage that JS must be enabled to
>>>> use the site.
>>>> Of course, a website that handles both situations right is better than
>>>> one that demands JS.
>>>>
>>> And therein lies the problem. How many people leave after seeing your
>>> home page without going any further? Every one of them who run with JS
>>> turned off. So obviously, since you only see those who have javascript
>>> disabled, your conclusion is that most people have JS enabled.
>>
>> ???
>> Where did I say I concluded that most people have JS enabled based on my
>> visitors? You put words in my mouth/writing.
>>
>> I DO think that by the way, I just didn't say it. Maybe you are confusing
>> posters. :-)
>>
>
> No, you didn't state it here. But it's a logical conclusion from other
> comments you've made and the fact you don't push it with your customers.
> But it's also an obvious conclusion to make when you never see the
> non-JS users.
>
> There isn't anything wrong with this opinion, Erwin. And for your
> customer base it may be 100% correct. But do you think it might also be
> based on incomplete information?
To be honest, I am unsure.
Last numbers I saw (w3schools) says 6% is JS challenged.
But I admid I have no clue how reliable that numbers are.
By the way: I cannot reach www.thecounter.com anymore. They used to serve
good statistics if memory serves me well.
Does anybody know what happened with them? Paying clients only?
Still, from a (business) clients point of view 6% missed customers can or
cannot be acceptable (pricewise).
Very roughly speaking: I think the price for sites I build rises by 10-20%
on most projects I work on to make them work in both situations.
Mostly because of double work.
>
>>>> An example (a thing I am working on right now):
>>>> I need a geograpical map of some area with lots of regions in it.
>>>> The user clicks on one region and I must select the neighbouring
>>>> regions: they light up.
>>>> Another selectbox defines how deep the neighbours are found (eg 0, 1,
>>>> 2, etc).
>>>> If I must deliver that piece without JS, I need a roundrobin to the
>>>> server for each click, rebuild the map with the right regions lighted
>>>> up: quite slow and it will result in a sluggish enduserexperience.
>>>> This is just an example of realworld situations I do want to
>>>> program/deliver without JS.
>>>>
>>> Yes, it requires a request to the server. but it should not be "slow"
>>> and should not result in a sluggish end user experience".
>>
>> Not?
>> Not if the map exists of 200+ images that the browser has to layout every
>> time after every click?
>> Of course that will be sluggish compared to Javascript switching a few
>> images, and you know that just as well as I do. Or I am misjudging your
>> competence completely.
>>
>
> First of all, most of those images would already be cached by the
> browser and wouldn't need to be fetched from the server.
>
> But it also means you need to send two copies of every image for the JS
> version, whether or not you'll even need them (and chances are you won't
> need all of them - maybe not even a large percentage of the copies).
>
> So your first page is going to be twice as slow loading because it has
> to load all of those images which probably won't be used.
True.
But after one click JS wins performancewise.
Slower to build the first time, faster after one click.
>
> So a good compromise in this case would be to have JS load the copies
> and handle the image switches. And if JS isn't active, don't load the
> extra copies and make the trip to the server.
>
> That way JS is enhancing the experience, but the experience doesn't
> require JS.
True.
I am merely trying to get the point across that I have to make the routines
in HTML/JS AND in PHP serverside.
More work, higher bill.
>
>>
>>>> One a sidenote: What is so bad about demanding JS for your site? People
>>>> demand IE, Flash, Java, Acrobat Reader, etc to use their sites.
>>>> I have no problems with it. :-/
>>>>
>>> Because you lose customers that way. Every one who surfs with
>>> javascript turned off. And you never see them go.
>>
>> Loose customers?
>> I loose MY customers if I present them bills for fully compatible sites
>> (JS/no JS, Java/No Java, Flash/no Flash, etc).
>>
>
> I'm talking about THEIR customers. I don't lose customers because I can
> show them how not being compatible would lose them money. Most are
> quite happy to pay for non-JS versions when they understand requiring JS
> can cost them more in lost sales than the cost of implementing the
> solution.
Just curious, roughly speaking, how much more work do you guess you need to
make your app work nicely with and without JS? (I estimated that in my case
around 10-20%)
>
>> Well Jerry, as I said: I don't mind making apps 100% non-JS compatible.
>> But I must raise my bill because it results in more coding/thinking and
>> in some situations a lot of double work.
>> Of course I prefer a site that handles both situations....
>> And the situation flas/no flash.
>> And the situation Java/no Java.
>> Go on and do the math. My bills will grow.
>>
>> I think you are describing some 'ideal world' solution, while I tried to
>> describe real world situations that run on tight budgets.
>> I do not know how you are employed, but I run my own business and simply
>> do not have the luxery to make perfect apps day-in-day-out, allthough I
>> would like that.
>>
>
> No, not "ideal world". The way I work. I run my own business, also
> (have for over 16 years, now). I don't make 'perfect' apps. But at the
> same time I show my customers the real world. And BTW - I don't do
> flash at all - too "graphically challenged" :-). But I have someone who
> can do the flash if I need it. And I don't do client-side Java unless
> there is a very good reason for it. Most sites obviously don't need it.
True.
I also seldom use Java clientside these days. (I used to love it, but since
Javascript became more powerfull, and I could develop a lot fatser in
JS...)
>
> In an "ideal world" you could require JS/Flash/Java and anything else
> and not lose any potential customers. In the "real world", though,
> doing any of these will lose you potential customers. The only question
> is which will cost you more money in the long run - the loss of
> customers by requiring these technologies, or the cost of implementing
> non-JS/Java/Flash version.
Yes, that is the question.
And the answer depends on the type of customer indeed.
I do a lot of start-ups (people who just start their business and need
online help), and lots of them are very pennywise, but poundfoolish.
In case their business runs smoothly, they DO have the money to upgrade/fix
annoying stuff on their site. :-)
>
> It's a trade-off, and details will be different for each site. But for
> my customers the extra up front cost would be recovered by just a few
> sales.
>
You don't charge them enough Jerry! ;-)
>
> Another example here. I'm working on a site with dropdowns for country
> and state/province. When the country changes, the state/province
> contents change (or it is disabled).
>
> Obviously this requires javascript and there's no way to do it with
> javascript disabled. So I set it up such that all entries are placed in
> the state/province block. When JS is enabled, it replaces the content
> with an accurate list (or disables it completely). But if JS is
> disabled, the state/province block shows all entries. Either way there
> needs to be further validation server side. But again, JS "enhances the
> experience".
Yes, that's the right way to do it: replace the content of some div or
something like that.
No discussion there. :-)
Happy coding.
Regards,
Erwin Moller
Navigation:
[Reply to this message]
|