|
|
Posted by Jerry Stuckle on 02/25/07 13:49
Curtis wrote:
> Jerry Stuckle wrote:
>> 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
>>
>>
>
> I don't run my own business, and have been coding mainly for the sake of
> learning/enjoyment. So, there are probably perspectives I just can't
> conceive of right now.
>
> I was just curious why one couldn't eliminate the extra work of making a
> more accessible site through the practice of organizing code and making
> it as modular as possible. It would seem like you could reduce the
> overhead of a lot of tasks this way. I have become fluent in JavaScript
> over the years, and I find it works best when you start the app design
> without any JS, and build up from there, each layer gracefully degrading
> to the previous, when necessary. This is what I think of when Jerry
> mentioned using JS to "enhance" apps, not make apps dependent upon it.
> JS, I feel is a great way to reduce server load for things like
> validating data on the client side (of course, always ensuring that data
> is validated server side). But all this can be organized so reusing and
> building new things is relatively painless.
>
> Like I said though, I haven't been in a position like Erwin's, so I
> couldn't speak of that situation. I would imagine though, as long as
> your clients are happy, referring others, and/or returning, then you
> must be doing something right. :)
>
> --
> Curtis, http://dyersweb.com
Curtis,
Yes, you can do that - but it still requires additional effort, which
adds time and cost to the project - Just like doing a database-driven
PHP page takes more time and effort than a static HTML page.
Every time you add a new bell/whistle you're talking about more work,
and there are only so many billable hours. Now, if you want to give
your time away...
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|