|
|
Posted by Jerry Stuckle on 02/23/07 21:25
Erwin Moller wrote:
> 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. ;-)
>
Understandable. But you wouldn't want to hear my try at Dutch! :-)
>
>>>>> 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.
>
Me, neither. And it depends a lot on the target audience.
> 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?
>
I can still get it here.
> 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.
>
Yes, it is more work. But things like validation (as you pointed out
earlier) can be done on the client side - but must be done on the server
end, also. And yes, 10-20% is about right, in my experience.
>
>>>>> 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.
>
Yep, and fewer lost potential customers.
>>>>> 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%)
>
About the same here. It depends a lot on the site.
>
>>> 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...)
>
I still do some server side Java - it's nice if you get it on a fast
server. But Java can be a resource hog, and many clients it would run
unacceptably slow, especially when you're targeting consumers (who are
more likely to be speed and/or memory constrained).
>
>> 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. :-)
>
Yes, I see that, also. But that's where I explain to them how they can
lose customers because of it. If the have any brains at all, they think
about that.
>
>> 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! ;-)
>
Sure I do :-)
But most of them aren't selling $5 Rolex Replicas, either. :-) They're
doing something a little higher end, where their markup could be from
$10-100 per order. Even at $10 it doesn't take long to recoup a couple
of hundred dollars.
>> 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
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|