|
|
Posted by Curtis on 02/25/07 11:57
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
Navigation:
[Reply to this message]
|