This is Interesting: Free Magazines for Graphics designers and webmasters
Home > Archive > Webmaster forum > September 2005 > JavaScript Required
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
JavaScript Required
|
|
| Matt Silberstein 2005-09-26, 10:21 pm |
| I am beginning design on a new site that pretty much demands
JavaScript/AJAX. With that kind of technology I think I can give a
high quality useful experience, without it the system would drag and
take time and/or lots of bandwidth. I know I could do both versions,
but in this case that would probably mean maybe 80% extra work. What %
of people keep JavaScript off all the time? Do anyone have any
thoughts on whether this is a bad business model or not?
--
Matt Silberstein
Do something today about the Darfur Genocide
Genocide is news | Be A Witness
http://www.beawitness.org
"Darfur: A Genocide We can Stop"
www.darfurgenocide.org
Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
| |
| Ben Jamieson 2005-09-27, 3:30 am |
| On 2005-09-26 22:03:41 -0400, Matt Silberstein
<RemoveThisPrefixmatts2nospam@ix.netcom.com> said:
> I am beginning design on a new site that pretty much demands
> JavaScript/AJAX. With that kind of technology I think I can give a
> high quality useful experience, without it the system would drag and
> take time and/or lots of bandwidth. I know I could do both versions,
> but in this case that would probably mean maybe 80% extra work. What %
> of people keep JavaScript off all the time? Do anyone have any
> thoughts on whether this is a bad business model or not?
Matt,
This kind of depends on your target audience. If its a corporate
market, forget it. While they may have Javascript available, a whole
heap of IE users may well not have ActiveX enabled, which means they
ain't going to be able to do squat with your site! (Windows requires
ActiveX for AJAX in IE)
Even in a non-corporate market, combine the two (Javascript *and*
ActiveX) in general and your audience is diminishing quickly. (This may
change in IE 7, should it actually be usable when it arrives)
Also, if its a commercial site that needs pages to show up in search
engines, forget about it again. the SE's won't be able to get past your
first click..
Its now down to you knowing your market. If none of the above is an
issue, they you're fine. If any one of them *may* be a *potential*
issue, and you intend to make money from the site, the 80% extra is
pretty much essential.
| |
| Jerry Stuckle 2005-09-27, 3:30 am |
| Matt Silberstein wrote:
> I am beginning design on a new site that pretty much demands
> JavaScript/AJAX. With that kind of technology I think I can give a
> high quality useful experience, without it the system would drag and
> take time and/or lots of bandwidth. I know I could do both versions,
> but in this case that would probably mean maybe 80% extra work. What %
> of people keep JavaScript off all the time? Do anyone have any
> thoughts on whether this is a bad business model or not?
>
>
It's a good business model if you want to steer people AWAY from your site.
I don't know how many have javascript turned off, but I'm one of them.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
| |
| Matt Silberstein 2005-09-27, 3:31 am |
| On Mon, 26 Sep 2005 22:54:27 -0400, in alt.www.webmaster , Ben
Jamieson <ben@thymeonline.com> in
<2005092622542716807%ben@thymeonlinecom> wrote:
>On 2005-09-26 22:03:41 -0400, Matt Silberstein
><RemoveThisPrefixmatts2nospam@ix.netcom.com> said:
>
>
>Matt,
>
>This kind of depends on your target audience. If its a corporate
>market, forget it. While they may have Javascript available, a whole
>heap of IE users may well not have ActiveX enabled, which means they
>ain't going to be able to do squat with your site! (Windows requires
>ActiveX for AJAX in IE)
>
>Even in a non-corporate market, combine the two (Javascript *and*
>ActiveX) in general and your audience is diminishing quickly. (This may
>change in IE 7, should it actually be usable when it arrives)
>
>Also, if its a commercial site that needs pages to show up in search
>engines, forget about it again. the SE's won't be able to get past your
>first click..
>
>Its now down to you knowing your market. If none of the above is an
>issue, they you're fine. If any one of them *may* be a *potential*
>issue, and you intend to make money from the site, the 80% extra is
>pretty much essential.
<mumble mumble>
That is what I thought. For what I have in mind I don't care about the
search engine aspect. The JS is for manipulation and construction, the
SEs should only care about the data when it is static. As for
corporate business, I am uncertain right now whether or not I would go
after the corporate market. It may be that I need to either rethink
the process or just wait. There are just so many cool things you can
do if you grab the data as needed instead of having to grab big chunks
and hope you are right and if not having to re-load everything and
start over. Sigh.
--
Matt Silberstein
Do something today about the Darfur Genocide
Genocide is news | Be A Witness
http://www.beawitness.org
"Darfur: A Genocide We can Stop"
www.darfurgenocide.org
Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
| |
| Matt Silberstein 2005-09-27, 3:31 am |
| On Mon, 26 Sep 2005 22:58:54 -0500, in alt.www.webmaster , Jerry
Stuckle <jstucklex@attglobal.net> in
<OvudnSW7Y7rtKKXeRVn-pw@comcast.com> wrote:
>Matt Silberstein wrote:
>
>It's a good business model if you want to steer people AWAY from your site.
>
>I don't know how many have javascript turned off, but I'm one of them.
If I turn away 5% of 10% that is not such a big deal. 30-40% is
serious. There are just so many interesting and useful things I can do
with the JavaScript constructing the page on the fly. If I have to do
a full refresh with each click, which is almost how it would work,
then it would be way to slow. And without AJAX it would be a major
drag.
--
Matt Silberstein
Do something today about the Darfur Genocide
Genocide is news | Be A Witness
http://www.beawitness.org
"Darfur: A Genocide We can Stop"
www.darfurgenocide.org
Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
| |
| David Dorward 2005-09-27, 3:31 am |
| Matt Silberstein wrote:
> If I turn away 5% of 10% that is not such a big deal
It isn't? 1 in every 10 customers is not a big deal?!
> There are just so many interesting and useful things I can do
> with the JavaScript constructing the page on the fly. If I have to do
> a full refresh with each click, which is almost how it would work,
> then it would be way to slow.
Design for Graceful degradation, and don't think of it as being 80% extra
work. Wrap up lots of functionality in reusable modules that you can use on
both sides.
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
| |
| Brian Wakem 2005-09-27, 6:31 am |
| Matt Silberstein wrote:
> If I turn away 5% of 10% that is not such a big deal.
What! That's like a shop owner standing at his shop door and telling every
tenth customers to clear off. That is no business model, it's a bankruptcy
model.
--
Brian Wakem
Email: http://homepage.ntlworld.com/b.wakem/myemail.png
| |
|
|
"Ben Jamieson" <ben@thymeonline.com> wrote in message
news:2005092622542716807%ben@thymeonlinecom...
>
> This kind of depends on your target audience. If its a corporate market,
> forget it. While they may have Javascript available, a whole heap of IE
> users may well not have ActiveX enabled, which means they ain't going to
> be able to do squat with your site! (Windows requires ActiveX for AJAX in
> IE)
AJAX is essentially a trendy new name for what has been known as Remote
Scripting (and other names) for ages. OK, there *are* differences - remotes
scripting doesnt need ActiveX for example, but the common idea is to update
a page using client-side script to avoid unnecessary form submission and
round-trips to the server.
I use remote-scripting (in a form known as XML Data Islands) all the time,
and very useful it is too.
However, as David has suggested, the key thing is to make the page degrade
gracefully. This technique should enhance the application, but the
application should not be dependant on it.
Chris
| |
| Charles Sweeney 2005-09-27, 6:32 am |
| CJM wrote
> However, as David has suggested, the key thing is to make the page
> degrade gracefully. This technique should enhance the application, but
> the application should not be dependant on it.
This is what always gets me about this. If the app shouldn't be dependant
on it, then why have it???
To me it's counter-productive. With today's low costs and higher spec
machines, you shouldn't need to rely on the client-side, and *most
certainly* if it's anything connected with an order form.
--
Charles Sweeney
http://CharlesSweeney.com
| |
|
| Charles Sweeney wrote
> To me it's counter-productive. With today's low costs and higher spec
> machines, you shouldn't need to rely on the client-side, and *most
> certainly* if it's anything connected with an order form.
Remember back in the "mainframe" days where client side was a keyboard and a
screen and just enough transistors to get keypresses up the line and stuff
coming down the line into the screen buffer? Absolutely *everything* was
done server side.
Perhaps we should be returning to this. After all, if it is done server side
then we *know* it will get done and we *knnow* it will get done correctly,
and all of this supposedly efficient AJAX[1]bedamned.
[1] which *does* cause a round trip back to the server, which those who push
AJAX, the OP included, neatly ignore.
Matt, for me a round trip to your server takes an absolute minimum of 300
milliseconds (on a good day). Do I now care if your AJAX enabled setup
returns the 1K of additional data to me with a transfer time of 1
millisecond or a whole 50KB new page, with a transfer time of 10
milliseconds?
Cheers
Richard.
| |
| Charles Sweeney 2005-09-27, 7:13 pm |
| rf wrote
> Charles Sweeney wrote
>
>
> Remember back in the "mainframe" days where client side was a keyboard
> and a screen and just enough transistors to get keypresses up the line
> and stuff coming down the line into the screen buffer? Absolutely
> *everything* was done server side.
I don't remember them from experience, I'm relatively new to this game!
> After all, if it is done
> server side then we *know* it will get done and we *knnow* it will get
> done correctly
This wins it for me, every time.
--
Charles Sweeney
http://CharlesSweeney.com
| |
| Ben Jamieson 2005-09-27, 7:13 pm |
| On 2005-09-27 01:13:07 -0400, Matt Silberstein
<RemoveThisPrefixmatts2nospam@ix.netcom.com> said:
> There are just so many cool things you can
> do if you grab the data as needed instead of having to grab big chunks
> and hope you are right and if not having to re-load everything and
> start over. Sigh.
A agree totally - xmlhttp requests allow us to finally make our web
apps work the same way as desktop apps, with immediate responses to
actions, and allow us to remove the whole 'page' metaphor
If Windows hadn't ruined the whole Javascript/ActiveX thing for
everyone and instead had created a browser that was actually safe to
use with these technologies, we'd be a lot closer to all this.
Unfortunately, due to this, and of course the elitist few who seem to
believe the web should be a completely passive experience and happily
tell the world how they would never enable javascript (and are usually
pretty vocal about Flash and Cookies too, poor souls), we're held back
in developing apps that can truly make the most of technology - xmlhttp
has been available to us since IE 4, but have only gained exposure in
the last 8 months -go figure!
I've been using it for the last 6 months pretty heavily for some of the
apps I'm building/have built, but have the advantage of them being
deployed in fairly closed environments, so I know when and where it
will work for all the users.
In more public apps, we add an explanatory notice for those with
ActiveX disabled, advising them to use a non ActiveX based browser that
will allow advanced functionality without the security risks, and,
where possible <noscript></noscript> versions, again with a note
advising (not 'telling') the user of the advantages of changing their
ways.
If they choose to leave to go back to watching their black and white
TV's or listening to their mono transistor radios, then so be it -
there's really not enough of them using our systems to warrant holding
the rest of our users back!
| |
|
|
"Charles Sweeney" <me@charlessweeney.com> wrote in message
news:Xns96DE6E9FB15EAmecharlessweeneycom@130.133.1.4...
> CJM wrote
>
> This is what always gets me about this. If the app shouldn't be dependant
> on it, then why have it???
>
To quote myself: '..to enhance the application...'
If it requires javascript to use the application, then 15% of the population
will be excluded. If javascript merely 'enhances' the application but
degrades gracefully, you have 85% of people with an improved browsing
experience, and 15% with a satisfactory browsing experience. Simple really.
Various Assumptions: That the application minus js is well designed; that
the enhanced application with js is still well designed; etc, etc...
> To me it's counter-productive. With today's low costs and higher spec
> machines, you shouldn't need to rely on the client-side, and *most
> certainly* if it's anything connected with an order form.
>
Ok, a simple example:
Standard HTML SELECT behaviour - type a letter in a dropdown box and it will
jump to the next item beginning with that letter. Type in a second letter,
and it jumps
My enhanced (with js) SELECT behaviour - type in a letter, and it jumps to
the same place, type in a second letter it jumps to the first entry that
matches BOTH letters. Eg. GA for Gateshead, GL for Glasgow - in a standard
box, GL will probably give you Leeds!
DHTML menus are another example.... (providing we are indeed talking about
the ones that degrade properly).
| |
|
|
"rf" <@invalid.com> wrote in message
news:nU8_e.16048$0E5.8384@news-server.bigpond.net.au...
> Charles Sweeney wrote
>
>
> Remember back in the "mainframe" days where client side was a keyboard and
> a
> screen and just enough transistors to get keypresses up the line and stuff
> coming down the line into the screen buffer? Absolutely *everything* was
> done server side.
>
Ah.. back to the future again.
> Perhaps we should be returning to this. After all, if it is done server
> side
> then we *know* it will get done and we *knnow* it will get done correctly,
> and all of this supposedly efficient AJAX[1]bedamned.
>
Wtf? You know what will get done?
There is nothing wrong with doing *some* things client-side. The trick is to
know what to do and where. Filtering recordsets is a bad idea, but sorting
them isnt...
> [1] which *does* cause a round trip back to the server, which those who
> push
> AJAX, the OP included, neatly ignore.
It's certainly not with no cost at all, but the overhead and the impact on
the server is significantly less (though depends on the specific examples).
>
> Matt, for me a round trip to your server takes an absolute minimum of 300
> milliseconds (on a good day). Do I now care if your AJAX enabled setup
> returns the 1K of additional data to me with a transfer time of 1
> millisecond or a whole 50KB new page, with a transfer time of 10
> milliseconds?
>
Do you care that you have to submit a page and wait longer for a response
when certain UI choices are made? Sure if the page can react to you input
without delays then your browsing experience is improved?
The bottom line it that there things that should usually be done server-side
and some things that should usually be done client-side, and a host of
things that fall somewhere in that grey area in between. AJAX and similar
approaches live firmly in this middle area.
| |
| William Tasso 2005-09-27, 7:13 pm |
| Writing in news:alt.www.webmaster
From the safety of the cafeteria
CJM <cjmnew04@REMOVEMEyahoo.co.uk> said:
>
> "Charles Sweeney" <me@charlessweeney.com> wrote in message
> news:Xns96DE6E9FB15EAmecharlessweeneycom@130.133.1.4...
>
>
> To quote myself: '..to enhance the application...'
>
> If it requires javascript to use the application, then 15% of the
> population
> will be excluded. If javascript merely 'enhances' the application but
> degrades gracefully, you have 85% of people with an improved browsing
> experience, and 15% with a satisfactory browsing experience. Simple
> really.
nicely put.
> Various Assumptions: That the application minus js is well designed; that
> the enhanced application with js is still well designed; etc, etc...
ok - the application is a list of lists aka nested lists
Implementation: <ul><li><ul><li> ... etc.
additional usability can be gained by allowing click to expand/collapse[1]
each list (and nested list)
The common mistake: assume everybody has script (enabled) and deliver the
lists collapsed.
Trivial solution - deliver the lists expanded, provide collapse
functionality. Additionally fire a collapse all when the page has
finished loading[2].
[1] CSS: display
[2] Arguably a usability issue in some circumstances.
--
William Tasso
Lovely are recruiting citizens - http://citizensrequired.com/
| |
|
|
"William Tasso" <SpamBlocked@tbdata.com> wrote in message
news:op.sxrm2o11m9g4qz-wnt@tbdata.com...
>
> ok - the application is a list of lists aka nested lists
>
> Implementation: <ul><li><ul><li> ... etc.
>
> additional usability can be gained by allowing click to expand/collapse[1]
> each list (and nested list)
>
> The common mistake: assume everybody has script (enabled) and deliver the
> lists collapsed.
>
> Trivial solution - deliver the lists expanded, provide collapse
> functionality. Additionally fire a collapse all when the page has
> finished loading[2].
>
>
> [1] CSS: display
> [2] Arguably a usability issue in some circumstances.
> --
> William Tasso
>
| |
|
| Oops.. premature submission there...
"CJM" <cjmnew04@REMOVEMEyahoo.co.uk> wrote in message
news:3pt4b8Fc23keU1@individual.net...[color=darkred]
Yeah, I've made that mistake before but with a menu...
[color=darkred]
| |
| Matt Silberstein 2005-09-27, 7:14 pm |
| On Tue, 27 Sep 2005 10:17:05 +0100, in alt.www.webmaster , "CJM"
<cjmnew04@REMOVEMEyahoo.co.uk> in <3psh0hFbra80U1@individual.net>
wrote:
>
>"Ben Jamieson" <ben@thymeonline.com> wrote in message
>news:2005092622542716807%ben@thymeonlinecom...
>
>AJAX is essentially a trendy new name for what has been known as Remote
>Scripting (and other names) for ages.
Trendy or not, it is the name people recognize.
>OK, there *are* differences - remotes
>scripting doesnt need ActiveX for example, but the common idea is to update
>a page using client-side script to avoid unnecessary form submission and
>round-trips to the server.
>
>I use remote-scripting (in a form known as XML Data Islands) all the time,
>and very useful it is too.
The idea of getting the information that the user needs, right now,
when they have selected something, rather than downloading tons (if it
is even possible), or having to reload the page, is astounding. I have
in mind here filling out forms, where filling in one fields allows
specific drop down lists for the other ones.
>However, as David has suggested, the key thing is to make the page degrade
>gracefully. This technique should enhance the application, but the
>application should not be dependant on it.
I agree, but that was part of my question. The graceful degradation
would almost double the work here and/or make for a much worse
experience. I guess the "opportunity" is to find the most graceful
degradation (isn't "most graceful degradation" a great name for a
song, if not a lifestyle?) I can.
--
Matt Silberstein
Do something today about the Darfur Genocide
Genocide is news | Be A Witness
http://www.beawitness.org
"Darfur: A Genocide We can Stop"
www.darfurgenocide.org
Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
| |
| Matt Silberstein 2005-09-27, 7:14 pm |
| On Tue, 27 Sep 2005 10:10:27 GMT, in alt.www.webmaster , "rf"
<@invalid.com> in <nU8_e.16048$0E5.8384@news-server.bigpond.net.au>
wrote:
>Charles Sweeney wrote
>
>
>Remember back in the "mainframe" days where client side was a keyboard and a
>screen and just enough transistors to get keypresses up the line and stuff
>coming down the line into the screen buffer? Absolutely *everything* was
>done server side.
>
>Perhaps we should be returning to this. After all, if it is done server side
>then we *know* it will get done and we *knnow* it will get done correctly,
>and all of this supposedly efficient AJAX[1]bedamned.
>
>[1] which *does* cause a round trip back to the server, which those who push
>AJAX, the OP included, neatly ignore.
Who is ignoring it? Of course it is there, but it is a much smaller
amount of data each way and far less processing in total (though more
on the client side). With optimistic estimates each of these would
be far less than 1% of re-loading the page.
>Matt, for me a round trip to your server takes an absolute minimum of 300
>milliseconds (on a good day). Do I now care if your AJAX enabled setup
>returns the 1K of additional data to me with a transfer time of 1
>millisecond or a whole 50KB new page, with a transfer time of 10
>milliseconds?
>
Imagine a broad tree, 100 options at each branch, and just three
levels. I have three successive drop downs for the use to select. If I
do this all at once I have to download 1 million items. With Ajax I
download the first 100. Use that to populate the second, use that to
populate the third. Or I do the first. Send back all of the data and
re-build the entire page. Do the second. Send back all of the data and
re-build the entire page. And then have the third. Now imagine that I
have ten of these on the page. Yes, Ajax can give a much better user
experience.
--
Matt Silberstein
Do something today about the Darfur Genocide
Genocide is news | Be A Witness
http://www.beawitness.org
"Darfur: A Genocide We can Stop"
www.darfurgenocide.org
Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
| |
| Matt Silberstein 2005-09-27, 7:14 pm |
| On 27 Sep 2005 09:52:19 GMT, in alt.www.webmaster , Charles Sweeney
<me@charlessweeney.com> in
<Xns96DE6E9FB15EAmecharlessweeneycom@130.133.1.4> wrote:
>CJM wrote
>
>
>This is what always gets me about this. If the app shouldn't be dependant
>on it, then why have it???
10x speed improvement at the very least. Ability pick valid options
from a drop down list instead of filling in a field and hoping it
passes.
>To me it's counter-productive. With today's low costs and higher spec
>machines, you shouldn't need to rely on the client-side, and *most
>certainly* if it's anything connected with an order form.
This is not an order form, it is a full application I have in mind.
The higher spec machines don't help if I can't use it for processing
and have to do all the work on the server side. My rough guess for my
app is that doing it the old fashioned way would be maybe 10 times as
slow. I would really have to do a complete re-think of the application
and end up loosing some features. With Ajax I can pre-load fields,
with the old system I would have to let the user fill things in and
then check the data. (Yes, I know I have to check the data anyway, but
with the drop down the user can't get it wrong.)
--
Matt Silberstein
Do something today about the Darfur Genocide
Genocide is news | Be A Witness
http://www.beawitness.org
"Darfur: A Genocide We can Stop"
www.darfurgenocide.org
Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
| |
| Matt Silberstein 2005-09-27, 7:14 pm |
| On Tue, 27 Sep 2005 09:31:45 +0100, in alt.www.webmaster , Brian Wakem
<no@email.com> in <3psebhFc4356U1@individual.net> wrote:
>Matt Silberstein wrote:
>
>
>
>What! That's like a shop owner standing at his shop door and telling every
>tenth customers to clear off. That is no business model, it's a bankruptcy
>model.
No, it is like a shop owner deciding not to carry certain products.
You loose some business, but not every sale produces a profit. Read up
on the notion of getting rid of expensive customers.
--
Matt Silberstein
Do something today about the Darfur Genocide
Genocide is news | Be A Witness
http://www.beawitness.org
"Darfur: A Genocide We can Stop"
www.darfurgenocide.org
Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
| |
| William Tasso 2005-09-27, 7:14 pm |
| Writing in news:alt.www.webmaster
From the safety of the Church of Last Thursday cafeteria
Matt Silberstein <RemoveThisPrefixmatts2nospam@ix.netcom.com> said:
> On Tue, 27 Sep 2005 10:17:05 +0100, in alt.www.webmaster , "CJM"
> <cjmnew04@REMOVEMEyahoo.co.uk> in <3psh0hFbra80U1@individual.net>
> wrote:
>
>
> Trendy or not, it is the name people recognize.
yhm - not really. some, maybe.
>
> The idea of getting the information that the user needs, right now,
> when they have selected something, rather than downloading tons (if it
> is even possible), or having to reload the page, is astounding. I have
> in mind here filling out forms, where filling in one fields allows
> specific drop down lists for the other ones.
Sure, I remember an app (not one of mine I hasten to add) wher the dev had
built client side datasets for all the data the user could possibly need -
each page took 20 seconds to download/render - on a corporate LAN.
It's horses for courses.
>
> I agree, but that was part of my question. The graceful degradation
> would almost double the work here and/or make for a much worse
> experience.
ok - the trick is to design your app assuming no client side functionality.
> I guess the "opportunity" is to find the most graceful
> degradation (isn't "most graceful degradation" a great name for a
> song, if not a lifestyle?) I can.
how about graceful enhancements?
--
William Tasso
Lovely are recruiting citizens - http://citizensrequired.com/
| |
| Ben Jamieson 2005-09-27, 7:14 pm |
| On 2005-09-27 14:19:57 -0400, Matt Silberstein
<RemoveThisPrefixmatts2nospam@ix.netcom.com> said:
> I agree, but that was part of my question. The graceful degradation
> would almost double the work here and/or make for a much worse
> experience. I guess the "opportunity" is to find the most graceful
> degradation (isn't "most graceful degradation" a great name for a
> song, if not a lifestyle?) I can.
The following is sort of off topic, but this is obviously an
application with a web front end you are developing, as opposed to a
website with an application in the background.
The main difference between applications online and applications
offline seems to be that "System Requirements', while printed on the
box of every piece of software I've ever bought, seem to be a huge
no-no when building an application for the web. Why?
Everyone completely accepts that you need at least the "minimum system
requirements" to run Adobe Photoshop, but a hugely complex web app must
run on a PDA or you're damned forever by people who will complain that
it doesn't work on Browser B with CSS, images, Javascript, ActiveX
,cookies and colours all disabled.
NOTE: These aren't my views as a developer, just an observation of the
situation in general, so please don't attack me for not caring about my
users etc. I just think sometimes that the majority of web users (and
developers) still see the web as a one way flow of information, with
only limited return flow. The reality is that it has the ability, and
has had for a long time, to be so much more, but the general perception
we must develop for the 'lowest common denominator' seems to be holding
it (and us) back.
Imagine where my beloved Photoshop would be if users continued to
insist that version 8 must support 486 chips with 16MB RAM and a 200MB
hard drive. I shudder at the thought!
| |
| Brian Wakem 2005-09-27, 7:14 pm |
| Matt Silberstein wrote:
> On Tue, 27 Sep 2005 09:31:45 +0100, in alt.www.webmaster , Brian Wakem
> <no@email.com> in <3psebhFc4356U1@individual.net> wrote:
>
>
> No, it is like a shop owner deciding not to carry certain products.
If that's you're interpretation then you are in trouble.
--
Brian Wakem
Email: http://homepage.ntlworld.com/b.wakem/myemail.png
| |
| Ben Jamieson 2005-09-27, 7:14 pm |
| On 2005-09-27 15:15:30 -0400, Brian Wakem <no@email.com> said:
>
>
> If that's you're interpretation then you are in trouble.
How come? There's a shop near me, it sells cars. Only sells a few
brands, not all of them yet seems to be doing fine! Granted, they lost
the business of the guys who *want* the other brands, but they're a
*loooong* way from being 'in trouble'
| |
| Brian Wakem 2005-09-27, 7:14 pm |
| Ben Jamieson wrote:
> On 2005-09-27 15:15:30 -0400, Brian Wakem <no@email.com> said:
>
>
> How come? There's a shop near me, it sells cars. Only sells a few
> brands, not all of them yet seems to be doing fine! Granted, they lost
> the business of the guys who *want* the other brands, but they're a
> *loooong* way from being 'in trouble'
You're analogy is way off. If I want to buy a car from him but he tells me
he doesn't want to sell me a car because I am wearing a red jumper, which
maybe 10% of his potential customers do, then he is an idiot. Banning
non-javascript users from your site is just like this.
--
Brian Wakem
Email: http://homepage.ntlworld.com/b.wakem/myemail.png
| |
| Matt Silberstein 2005-09-27, 7:14 pm |
| On Tue, 27 Sep 2005 21:00:33 +0100, in alt.www.webmaster , Brian Wakem
<no@email.com> in <3ptmn1Fc6mtvU1@individual.net> wrote:
>Ben Jamieson wrote:
>
>
>
>You're analogy is way off. If I want to buy a car from him but he tells me
>he doesn't want to sell me a car because I am wearing a red jumper, which
>maybe 10% of his potential customers do, then he is an idiot. Banning
>non-javascript users from your site is just like this.
You have to show it is as irrelevant as wearing a red jumper and not
as relevant as, say, not taking checks and money orders because it is
too much trouble and there is too much fraud. People do customer
discrimination all of the time, the question is what are the relevant
and cost effective discrimination characteristics. Would you blithely
attack someone for refusing to build a Mac version of an application?
It is nonsensical to avoid building a Linux version of a desktop app?
IMO those are reasonable business decisions: you figure out cost and
benefit per customer and which way things are trending and such.
--
Matt Silberstein
Do something today about the Darfur Genocide
Genocide is news | Be A Witness
http://www.beawitness.org
"Darfur: A Genocide We can Stop"
www.darfurgenocide.org
Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
| |
| Charles Sweeney 2005-09-27, 7:14 pm |
| Ben Jamieson wrote
> On 2005-09-27 01:13:07 -0400, Matt Silberstein
> <RemoveThisPrefixmatts2nospam@ix.netcom.com> said:
>
chunks[color=darkred]
>
> A agree totally - xmlhttp requests allow us to finally make our web
> apps work the same way as desktop apps, with immediate responses to
> actions, and allow us to remove the whole 'page' metaphor
>
> If Windows hadn't ruined the whole Javascript/ActiveX thing for
> everyone and instead had created a browser that was actually safe to
> use with these technologies, we'd be a lot closer to all this.
>
> Unfortunately, due to this, and of course the elitist few who seem to
> believe the web should be a completely passive experience and happily
> tell the world how they would never enable javascript (and are usually
> pretty vocal about Flash and Cookies too, poor souls), we're held back
> in developing apps that can truly make the most of technology -
xmlhttp
> has been available to us since IE 4, but have only gained exposure in
> the last 8 months -go figure!
>
> I've been using it for the last 6 months pretty heavily for some of
the
> apps I'm building/have built, but have the advantage of them being
> deployed in fairly closed environments, so I know when and where it
> will work for all the users.
>
> In more public apps, we add an explanatory notice for those with
> ActiveX disabled, advising them to use a non ActiveX based browser
that
> will allow advanced functionality without the security risks, and,
> where possible <noscript></noscript> versions, again with a note
> advising (not 'telling') the user of the advantages of changing their
> ways.
>
> If they choose to leave to go back to watching their black and white
> TV's or listening to their mono transistor radios, then so be it -
> there's really not enough of them using our systems to warrant holding
> the rest of our users back!
Aye, but no-one in their right mind would advocate using Flash,
JavaScript or ActiveX for an order form.
--
Charles Sweeney
http://CharlesSweeney.com
| |
| Ben Jamieson 2005-09-27, 7:14 pm |
| On 2005-09-27 16:00:33 -0400, Brian Wakem <no@email.com> said:
>
> You're analogy is way off. If I want to buy a car from him but he tells me
> he doesn't want to sell me a car because I am wearing a red jumper, which
> maybe 10% of his potential customers do, then he is an idiot. Banning
> non-javascript users from your site is just like this.
Ahh, but you removed all the relevant bits of the previous post from
your reply, leaving only:
[color=darkred]
Which I interpreted correctly.
So, to change the analogy, this is like saying [Major Software
Developer] is in trouble because they have minimum system requirements
for *their* applications just like Matt has in his.
[Major application] *requires* a certain system criteria to run, so
[Major Software Developer] must, by your reasoning, be 'in trouble'.
Hmm... Still not getting it!
Why produce a 'basic' product to pacify 10% when 90% would prefer the
advanced product. I would prefer to have 90% of the clients happy, not
10%.
But that's just me.
| |
| Charles Sweeney 2005-09-27, 7:14 pm |
| CJM wrote
> If it requires javascript to use the application, then 15% of the
> population will be excluded. If javascript merely 'enhances' the
> application but degrades gracefully, you have 85% of people with an
> improved browsing experience, and 15% with a satisfactory browsing
> experience. Simple really.
Depends entirely on what you mean by "enhanced" or "improved". There's
many a drop-down box or predictive form field that drives me nuts!
Speaking as a surfer, such "enhancements" are generally a pain in the
arse.
Ditch the JavaScript and give 100% of visitors an improved browsing
experience.
--
Charles Sweeney
http://CharlesSweeney.com
| |
| Charles Sweeney 2005-09-27, 7:14 pm |
| William Tasso wrote
> Writing in news:alt.www.webmaster
> From the safety of the cafeteria
> CJM <cjmnew04@REMOVEMEyahoo.co.uk> said:
>
> nicely put.
You must know what "enhances" means.
I don't accept that one requires JavaScript to have an "improved
browsing experience".
The best "browsing experience" is where the content, product or service
is delivered quickly and cleanly. In my experience JavaScript is *not*
a pre-requisite for achieving this. On the contrary, the lightest,
cleanest, JavaScript-devoid sites usually deliver best.
--
Charles Sweeney
http://CharlesSweeney.com
| |
| Charles Sweeney 2005-09-27, 7:14 pm |
| Matt Silberstein wrote
> On 27 Sep 2005 09:52:19 GMT, in alt.www.webmaster , Charles Sweeney
> <me@charlessweeney.com> in
> <Xns96DE6E9FB15EAmecharlessweeneycom@130.133.1.4> wrote:
>
>
> 10x speed improvement at the very least. Ability pick valid options
> from a drop down list instead of filling in a field and hoping it
> passes.
>
>
> This is not an order form, it is a full application I have in mind.
> The higher spec machines don't help if I can't use it for processing
> and have to do all the work on the server side. My rough guess for my
> app is that doing it the old fashioned way would be maybe 10 times as
> slow. I would really have to do a complete re-think of the application
> and end up loosing some features. With Ajax I can pre-load fields,
> with the old system I would have to let the user fill things in and
> then check the data. (Yes, I know I have to check the data anyway, but
> with the drop down the user can't get it wrong.)
One would have to get into specifics to add anything here. I think the
gist has been established.
--
Charles Sweeney
http://CharlesSweeney.com
| |
| Brian Wakem 2005-09-27, 7:14 pm |
| Ben Jamieson wrote:
> So, to change the analogy, this is like saying [Major Software
> Developer] is in trouble because they have minimum system requirements
> for *their* applications just like Matt has in his.
>
> [Major application] *requires* a certain system criteria to run, so
> [Major Software Developer] must, by your reasoning, be 'in trouble'.
>
> Hmm... Still not getting it!
>
> Why produce a 'basic' product to pacify 10% when 90% would prefer the
> advanced product. I would prefer to have 90% of the clients happy, not
> 10%.
>
> But that's just me.
Minimum system requirements for software are different. They are the min
requirements because the software *couldn't* be written to work on lesser
machines. The javascript issue is different, you do not *have* to use it.
--
Brian Wakem
Email: http://homepage.ntlworld.com/b.wakem/myemail.png
| |
| Brian Wakem 2005-09-27, 7:14 pm |
| Matt Silberstein wrote:
> You have to show it is as irrelevant as wearing a red jumper and not
> as relevant as, say, not taking checks and money orders because it is
> too much trouble and there is too much fraud. People do customer
> discrimination all of the time, the question is what are the relevant
> and cost effective discrimination characteristics. Would you blithely
> attack someone for refusing to build a Mac version of an application?
> It is nonsensical to avoid building a Linux version of a desktop app?
> IMO those are reasonable business decisions: you figure out cost and
> benefit per customer and which way things are trending and such.
But a Mac or Linux alternative will probably be available, or the Windows
software can be made to work using wine or crossover, of if the user is
capable, he can write his own alternative (which I've had to do a few
times!).
With a website these options are not available. If I can't use your website
I can't buy anything from you, simple as that.
--
Brian Wakem
Email: http://homepage.ntlworld.com/b.wakem/myemail.png
| |
| Charles Sweeney 2005-09-27, 7:14 pm |
| Ben Jamieson wrote
> The main difference between applications online and applications
> offline seems to be that "System Requirements', while printed on the
> box of every piece of software I've ever bought, seem to be a huge
> no-no when building an application for the web.
I won't give you an argument there.
Talking about websites (as opposed to applications) the problem for me
is when webmasters exclude some visitors by using JavaScript where HTML
can be used. Menus for example.
OK. it's their tough luck if they lose visitors, but I would always
advocate making a site from HTML if you want *every* visitor to be able
to use it.
I would also not rely on the client-side for validating form data.
--
Charles Sweeney
http://CharlesSweeney.com
| |
| Charles Sweeney 2005-09-27, 7:14 pm |
| Matt Silberstein wrote
> On Tue, 27 Sep 2005 09:31:45 +0100, in alt.www.webmaster , Brian Wakem
> <no@email.com> in <3psebhFc4356U1@individual.net> wrote:
>
>
> No, it is like a shop owner deciding not to carry certain products.
> You loose some business, but not every sale produces a profit. Read up
> on the notion of getting rid of expensive customers.
I have studied accounting, and know about keeping lines that do not make
a profit, but contribute to fixed costs. Brian's analogy is a good one.
Unless of course you are talking about an esoteric application here, I'm
talking about websites in general.
--
Charles Sweeney
http://CharlesSweeney.com
| |
| Matt Silberstein 2005-09-27, 7:14 pm |
| On 27 Sep 2005 21:00:45 GMT, in alt.www.webmaster , Charles Sweeney
<me@charlessweeney.com> in
<Xns96DEDFF501B40mecharlessweeneycom@130.133.1.4> wrote:
>William Tasso wrote
>
>
>
>You must know what "enhances" means.
>
>I don't accept that one requires JavaScript to have an "improved
>browsing experience".
It all depends on the application.
>The best "browsing experience" is where the content, product or service
>is delivered quickly and cleanly. In my experience JavaScript is *not*
>a pre-requisite for achieving this. On the contrary, the lightest,
>cleanest, JavaScript-devoid sites usually deliver best.
Again, it all depends on the application. Take a look at Google Earth
for an example of a JavaScript enhanced user experience.
--
Matt Silberstein
Do something today about the Darfur Genocide
Genocide is news | Be A Witness
http://www.beawitness.org
"Darfur: A Genocide We can Stop"
www.darfurgenocide.org
Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
| |
| Charles Sweeney 2005-09-27, 7:14 pm |
| Ben Jamieson wrote
> On 2005-09-27 15:15:30 -0400, Brian Wakem <no@email.com> said:
>
>
> How come? There's a shop near me, it sells cars. Only sells a few
> brands, not all of them yet seems to be doing fine! Granted, they lost
> the business of the guys who *want* the other brands, but they're a
> *loooong* way from being 'in trouble'
Yes, but to use Brian's analogy, you wouldn't turn away every tenth
prospect looking for the few brands that they do stock.
You would want to welcome *all* such prospects.
--
Charles Sweeney
http://CharlesSweeney.com
| |
| Matt Silberstein 2005-09-27, 7:14 pm |
| On 27 Sep 2005 21:27:45 GMT, in alt.www.webmaster , Charles Sweeney
<me@charlessweeney.com> in
<Xns96DEE488E777Cmecharlessweeneycom@130.133.1.4> wrote:
>Ben Jamieson wrote
>
>
>I won't give you an argument there.
>
>Talking about websites (as opposed to applications) the problem for me
>is when webmasters exclude some visitors by using JavaScript where HTML
>can be used. Menus for example.
>
>OK. it's their tough luck if they lose visitors, but I would always
>advocate making a site from HTML if you want *every* visitor to be able
>to use it.
>
>I would also not rely on the client-side for validating form data.
If you see a "website" as display only then I agree. JavaScript simply
to enhance display may well be unnecessary. As a processing
environment that is a different thing.
--
Matt Silberstein
Do something today about the Darfur Genocide
Genocide is news | Be A Witness
http://www.beawitness.org
"Darfur: A Genocide We can Stop"
www.darfurgenocide.org
Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
| |
| Matt Silberstein 2005-09-27, 7:14 pm |
| On Tue, 27 Sep 2005 22:15:47 +0100, in alt.www.webmaster , Brian Wakem
<no@email.com> in <3ptr43Fc7na0U1@individual.net> wrote:
>Ben Jamieson wrote:
>
>
>
>Minimum system requirements for software are different. They are the min
>requirements because the software *couldn't* be written to work on lesser
>machines.
Or that it was not worthwhile to spend the extra money to make it fit
or it was not worthwhile to reduce the feature set.
>The javascript issue is different, you do not *have* to use it.
Your ability to know what an application requires is impressive.
--
Matt Silberstein
Do something today about the Darfur Genocide
Genocide is news | Be A Witness
http://www.beawitness.org
"Darfur: A Genocide We can Stop"
www.darfurgenocide.org
Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
| |
| Dylan Parry 2005-09-27, 7:14 pm |
| Using a pointed stick and pebbles, Matt Silberstein scraped:
> Again, it all depends on the application. Take a look at Google Earth
> for an example of a JavaScript enhanced user experience.
ITYM Google Maps? Google Earth, IIRC, is a downloadable application.
--
Dylan Parry
http://electricfreedom.org -- Where the Music Progressively Rocks!
"Under every stone lurks a politician" - Aristophanes
| |
| Matt Silberstein 2005-09-27, 7:14 pm |
| On 27 Sep 2005 21:32:32 GMT, in alt.www.webmaster , Charles Sweeney
<me@charlessweeney.com> in
<Xns96DEE558A10D6mecharlessweeneycom@130.133.1.4> wrote:
>Matt Silberstein wrote
>
>
>I have studied accounting, and know about keeping lines that do not make
>a profit, but contribute to fixed costs.
Do you know about dropping lines that are not profitable?
> Brian's analogy is a good one.
>
>Unless of course you are talking about an esoteric application here, I'm
>talking about websites in general.
I was talking about my specific case, I make no claims about websites
in general. It is sometimes reasonable to go after 90%, sometimes it
is cost effective to include 90% of the rest. It is not always
worthwhile to go after everyone.
--
Matt Silberstein
Do something today about the Darfur Genocide
Genocide is news | Be A Witness
http://www.beawitness.org
"Darfur: A Genocide We can Stop"
www.darfurgenocide.org
Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
| |
| Gerry for email use my name at dergal dt com 2005-09-27, 7:14 pm |
| Charles Sweeney wrote:
> Ben Jamieson wrote
>
>
>
> chunks
>
[color=darkred]
>
> Aye, but no-one in their right mind would advocate using Flash,
> JavaScript or ActiveX for an order form.
>
Not true ...
it depends on what the order form is for ...
Javascript and flash are very good for some order forms - there is an
excellent demo on the Macromedia website, for a hotel with a room
bookings (order form) that uses Flash effectively ...
Flash is easy to produce a no - flash version for ...
| |
| Charles Sweeney 2005-09-27, 7:14 pm |
| Matt Silberstein wrote
> Again, it all depends on the application. Take a look at Google Earth
> for an example of a JavaScript enhanced user experience.
I wouldn't say that was "enhanced", I would say it was a pre-requisite.
Like Flash, JavaScript is excellent if used in the correct context, like
above.
My concern is where it is used where HTML would be better, or where it is
used for validating form data. None of which apply above.
--
Charles Sweeney
http://CharlesSweeney.com
| |
| Gerry for email use my name at dergal dt com 2005-09-27, 7:14 pm |
| Charles Sweeney wrote:
> CJM wrote
>
>
>
>
> Depends entirely on what you mean by "enhanced" or "improved". There's
> many a drop-down box or predictive form field that drives me nuts!
>
> Speaking as a surfer, such "enhancements" are generally a pain in the
> arse.
>
> Ditch the JavaScript and give 100% of visitors an improved browsing
> experience.
>
www.SkyScanner.co.uk
Really good as a result of flash and scripting ... could be achieved
using standard HTML, yes ... but probably not as quick loading, clean or
usable
Flash / Javascript can MASSIVELY help usability and even (shockingly)
accessibilty!
G
| |
| Charles Sweeney 2005-09-27, 7:14 pm |
| Dylan Parry wrote
> Using a pointed stick and pebbles, Matt Silberstein scraped:
>
>
> ITYM Google Maps? Google Earth, IIRC, is a downloadable application.
AIUI the Earth one also works online. But the point is the same, and one I
agree with, it's a good example of JavaScript being used to good effect.
--
Charles Sweeney
http://CharlesSweeney.com
| |
| William Tasso 2005-09-27, 7:14 pm |
| Writing in news:alt.www.webmaster
From the safety of the Posted via Supernews, http://www.supernews.com
cafeteria
Ben Jamieson <ben@thymeonline.com> said:
> ...
> So, to change the analogy ...
May I play?
I believe the argument is more akin to building an out of town supermarket
before negotiating with the local authorities to have a bus route stop by.
--
William Tasso
Lovely are recruiting citizens - http://citizensrequired.com/
| |
| Charles Sweeney 2005-09-27, 7:14 pm |
| Matt Silberstein wrote
> If you see a "website" as display only then I agree. JavaScript simply
> to enhance display may well be unnecessary. As a processing
> environment that is a different thing.
Agreed. I think it is important to make a distinction between an
"application" and a "website".
Spacegirl often reminds us that the web is a media-rich environment,
without constraints. In many ways she is correct.
However, if you are trying to sell something, or trying to deliver
content to as many people as possible, then you should always aim for
the lowest common denominator.
--
Charles Sweeney
http://CharlesSweeney.com
| |
| Charles Sweeney 2005-09-27, 7:14 pm |
| Matt Silberstein wrote
> On 27 Sep 2005 21:32:32 GMT, in alt.www.webmaster , Charles Sweeney
> <me@charlessweeney.com> in
> <Xns96DEE558A10D6mecharlessweeneycom@130.133.1.4> wrote:
make[color=darkred]
>
> Do you know about dropping lines that are not profitable?
lol! Naturally. But sometimes you need to keep the one that doesn't
make a profit. I've got an example somewhere if anyone is interested.
I'm[color=darkred]
>
> I was talking about my specific case, I make no claims about websites
> in general. It is sometimes reasonable to go after 90%, sometimes it
> is cost effective to include 90% of the rest. It is not always
> worthwhile to go after everyone.
Fair enough. You tend to get the "websites in general" angle here.
--
Charles Sweeney
http://CharlesSweeney.com
| |
| Charles Sweeney 2005-09-27, 7:14 pm |
| Gerry for email use my name at dergal dt com wrote
> Charles Sweeney wrote:
>
> Not true ...
Couldn't be truer.
> it depends on what the order form is for ...
True, it could be a product that you have no great desire to sell.
> Javascript and flash are very good for some order forms
If you want to lose some potential customers.
> - there is an
> excellent demo on the Macromedia website, for a hotel with a room
> bookings (order form) that uses Flash effectively ...
The demo might be excellent, but the only thing you are doing
effectively is precluding potential customers.
> Flash is easy to produce a no - flash version for ...
Ah. Well as long as you have an HTML order form as well, then you
should be alright. This assumes that it is presented correctly, and the
user without Flash can quickly and easily see it and use it.
Personally I can't see how Flash could bring anything to an order form
that HTML and server-side processing can't.
--
Charles Sweeney
http://CharlesSweeney.com
| |
| Charles Sweeney 2005-09-27, 7:14 pm |
| William Tasso wrote
> Writing in news:alt.www.webmaster
> From the safety of the Posted via Supernews, http://www.supernews.com
>
> cafeteria
> Ben Jamieson <ben@thymeonline.com> said:
>
>
> May I play?
>
> I believe the argument is more akin to building an out of town
> supermarket before negotiating with the local authorities to have a
> bus route stop by.
LOL! Wouldn't be the Clapham omnibus by any chance??
--
Charles Sweeney
http://CharlesSweeney.com
| |
| Ben Jamieson 2005-09-27, 7:14 pm |
| On 2005-09-27 17:27:45 -0400, Charles Sweeney <me@charlessweeney.com> said:
> Talking about websites (as opposed to applications) the problem for me
> is when webmasters exclude some visitors by using JavaScript where HTML
> can be used. Menus for example.
Absolutely - core navigation and such should never depend on additional
stuff like javascripts.
>
> OK. it's their tough luck if they lose visitors, but I would always
> advocate making a site from HTML if you want *every* visitor to be able
> to use it.
The differentiation you make between websites and applications where it
all gets really tricky.
One of the systems I have just completed is a web 'project' that serves
one purpose - which is to provide a specific Financial Services
industry function. This particular function could only be handled via a
website (technically incorrect, but it is the ionly 'viable' way to
connect the client and provider) but is most definitely not a web
*site* - it is a reasonably complex application that needs these
additional capabilities to function in an efficient manner (I put that,
because yes, it could be built *not* to require them, but the end
result would be no more efficient than completing the process by
surface mail - and client and provider are rarely in the same country!)
The final result is more of an application, not a site, that has a
'minimum system requirement' through necessity. Clients that do not
wish to comply with the requirement can do things the old way - faxes
and phone calls, but we've yet to have any reports of them doing this
for the providers we've deployed the system for.
The web is no longer a passive vehicle for displaying non-linear
information. It has grown far beyond this and can enable business
methods that didn't exist previously. Should the small percentage who
do not wish to take advantage of these capabilities stop the
advancement of systems for those who see the benefits
And this brings us round to:
Why do those 15% disable javascript?
Some, without doubt, are forced to due to corporate mandate, brought on
by the horrific track record of Windows. The others are a mystery to me.
Sorry.... back on topic:
>
> I would also not rely on the client-side for validating form data.
Would anyone? <grin>
| |
| Matt Silberstein 2005-09-27, 10:21 pm |
| On Tue, 27 Sep 2005 22:42:14 +0100, in alt.www.webmaster , Dylan Parry
<usenet@dylanparry.com> in <3ptsldFc6vpeU2@individual.net> wrote:
>Using a pointed stick and pebbles, Matt Silberstein scraped:
>
>
>ITYM Google Maps? Google Earth, IIRC, is a downloadable application.
Google Earth is a downloadable application that uses JavaScript and
Ajax to give a remarkably nice user experience. Unfortunately people
here seem to be making a big distinction between a web page and an
application. IMNSHO users don't use computers, they don't use the
Internet, they don't use software or hardware, they use applications.
They don't give a hoot that the browser is just displaying something
that was made up elsewhere or it is doing it all itself. They want
something and that is it. So I make applications. Sometimes it is just
to display something on a variety of computers, sometimes I have to
make display and some processing on a server. In this particular case
I have an idea for an application that would best (as in most
efficiently, providing the best user experience) mostly on the client
side.
--
Matt Silberstein
Do something today about the Darfur Genocide
Genocide is news | Be A Witness
http://www.beawitness.org
"Darfur: A Genocide We can Stop"
www.darfurgenocide.org
Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
| |
| Matt Silberstein 2005-09-27, 10:22 pm |
| On 27 Sep 2005 22:19:51 GMT, in alt.www.webmaster , Charles Sweeney
<me@charlessweeney.com> in
<Xns96DEED5E95B89mecharlessweeneycom@130.133.1.4> wrote:
>Matt Silberstein wrote
>
>
>I wouldn't say that was "enhanced", I would say it was a pre-requisite.
Are you denying the existence of a middle case, where it helps, but is
not required.
>Like Flash, JavaScript is excellent if used in the correct context, like
>above.
>
>My concern is where it is used where HTML would be better, or where it is
>used for validating form data. None of which apply above.
I am not a big fan of HTML, but if it can do the job reasonably then
it is better than JavaScript. And, for the most part, CSS/HTML does
lots of good stuff moderately obviously. But I am thinking of pages
that are re-configured on the fly. Going back to the server to reload
the page each time is a major bother and slow. Using hide/show in CSS
can only take you so far, after awhile it is way too cumbersome
--
Matt Silberstein
Do something today about the Darfur Genocide
Genocide is news | Be A Witness
http://www.beawitness.org
"Darfur: A Genocide We can Stop"
www.darfurgenocide.org
Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
| |
| Dylan Parry 2005-09-28, 6:26 am |
| Using a pointed stick and pebbles, Matt Silberstein scraped:
>
> Google Earth is a downloadable application that uses JavaScript and
> Ajax to give a remarkably nice user experience.
Ah right, I didn't realise that was how it worked. I wasn't saying that
there is a difference between using /x/ in an application and using it
on a Webpage, but merely being ignorant of the fact that Google Earth
used JavaScript :)
--
Dylan Parry
http://electricfreedom.org -- Where the Music Progressively Rocks!
"He who hesitates is not only lost, but miles from the next exit" - Anon
| |
|
|
"Charles Sweeney" <me@charlessweeney.com> wrote in message
news:Xns96DEDFF501B40mecharlessweeneycom@130.133.1.4...
>
> I don't accept that one requires JavaScript to have an "improved
> browsing experience".
>
It's not so black and white. Javascript can in *some* situations provide
some benefits. But without Javascript, it should still be easy, usable
etc...
> The best "browsing experience" is where the content, product or service
> is delivered quickly and cleanly.
Agreed.
> In my experience JavaScript is *not*
> a pre-requisite for achieving this.
It is no, I agree. But it can be helpful in some situations.
>On the contrary, the lightest,
> cleanest, JavaScript-devoid sites usually deliver best.
Sometimes.
A well developed site with javascript is better than a poorly designed site
without javascript. Hence, javascript is not the issues - it's how well
designed the site is. And good design depends on many factors *including*
the best usage of javascript (or not).
| |
|
|
"Ben Jamieson" <ben@thymeonline.com> wrote in message
news:2005092719014216807%ben@thymeonlinecom...
>
> Why do those 15% disable javascript?
>
They don't. A proprtion of these don't have a javascript-enabled browser.
Eg. Screen Readers etc
And since the Disability Discrimination Act (DDA) came into force, even a
private web application can be expected to be accessible. The logical
conclusion is that web sites/applications that are dependant on such things
as Javascript can be considered inaccessible.
In practice, this is a grey area, and we are awaiting the first few cases to
produce some good case law. Apparently the RNIB are pushing for a few cases
to be brought forward, but little has happened as yet. But if/when it does,
this whole argument may cease - good practice may well become a legal
requirement...
[straying back OT it seems]
Chris
| |
|
| On $DATE , Gerry for email use my name at dergal dt com wrote:
> Charles Sweeney wrote:
>
>
> www.SkyScanner.co.uk
>
> Really good as a result of flash and scripting ... could be
> achieved using standard HTML, yes ... but probably not as quick
> loading, clean or usable
>
> Flash / Javascript can MASSIVELY help usability and even
> (shockingly) accessibilty!
>
> G
I surf with Javascript and cookies disabled completely. Anything
that doesn't work I simply consider non-existent.
All script should be server-side scripts and cookies aboloished.
Regards,
Fred
(remove FFFf from my email address to reply)
| |
| William Tasso 2005-09-28, 6:36 pm |
| Writing in news:alt.www.webmaster
From the safety of the cafeteria
CJM <cjmnew04@REMOVEMEyahoo.co.uk> said:
> ...
> A well developed site with javascript is better than a poorly designed
> site without javascript.
I'm sure you didn't intend for that to sound like 'either/or'.
--
William Tasso
Lovely are recruiting citizens - http://citizensrequired.com/
| |
| David Dyer-Bennet 2005-09-28, 6:36 pm |
| Matt Silberstein <RemoveThisPrefixmatts2nospam@ix.netcom.com> writes:
> I am beginning design on a new site that pretty much demands
> JavaScript/AJAX. With that kind of technology I think I can give a
> high quality useful experience, without it the system would drag and
> take time and/or lots of bandwidth. I know I could do both versions,
> but in this case that would probably mean maybe 80% extra work. What %
> of people keep JavaScript off all the time? Do anyone have any
> thoughts on whether this is a bad business model or not?
I've heard recent claims of 5-10% either keep it turned off by
default, or are running a browser that doesn't support it at all. I
don't have my own source of figures to offer a number I came up with
myself. Remember that stats from sites already deeply
Javascript-dependent will be skewed towards people who can see it!
A lot of people beyond that find a JavaScript-dependent site highly
annoying, and only put up with it if they really feel they benefit.
I see *so* many stupidly gratuitous uses of JavaScript that I tend to
take a jaundiced view of *any* use of it, but of course you can use it
do some handy things sometimes.
--
David Dyer-Bennet, <mailto:dd-b@dd-b.net>, <http://www.dd-b.net/dd-b/>
RKBA: <http://noguns-nomoney.com/> <http://www.dd-b.net/carry/>
Pics: <http://dd-b.lighthunters.net/> <http://www.dd-b.net/dd-b/SnapshotAlbum/>
Dragaera/Steven Brust: <http://dragaera.info/>
| |
| Matt Silberstein 2005-09-29, 3:25 am |
| On Wed, 28 Sep 2005 14:01:55 -0400, in alt.www.webmaster , Fred
<unclefred@fredwilliamsFFFf.ca> in
<kRA_e.6366$cq2.672385@news20.bellglobal.com> wrote:
[snip]
>
> I surf with Javascript and cookies disabled completely. Anything
>that doesn't work I simply consider non-existent.
> All script should be server-side scripts and cookies aboloished.
Other than possible security issues, why? Wide adoption of Ajax is
going to revolutionize what you can do with a website..
--
Matt Silberstein
Do something today about the Darfur Genocide
Genocide is news | Be A Witness
http://www.beawitness.org
"Darfur: A Genocide We can Stop"
www.darfurgenocide.org
Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
| |
| Matt Silberstein 2005-09-29, 3:25 am |
| On 28 Sep 2005 16:12:13 -0500, in alt.www.webmaster , David
Dyer-Bennet <dd-b@dd-b.net> in <87vf0kx5g2.fsf@gw.dd-b.net> wrote:
>Matt Silberstein <RemoveThisPrefixmatts2nospam@ix.netcom.com> writes:
>
>
>I've heard recent claims of 5-10% either keep it turned off by
>default, or are running a browser that doesn't support it at all. I
>don't have my own source of figures to offer a number I came up with
>myself. Remember that stats from sites already deeply
>Javascript-dependent will be skewed towards people who can see it!
>
>A lot of people beyond that find a JavaScript-dependent site highly
>annoying, and only put up with it if they really feel they benefit.
>
>I see *so* many stupidly gratuitous uses of JavaScript that I tend to
>take a jaundiced view of *any* use of it, but of course you can use it
>do some handy things sometimes.
The particular JavaScript use I have in mind is a dynamic "table"
where the customer is going to be able to configure at will and add
"rows". (I mean real tables and rows, not HTML markup.) Yes, I can
play games with hidden rows and use CSS to show them, but that kind of
trick will only take you so far. The other option is to send back to
the server and re-do the page each time. For this application that
will get very annoying. (I will also do lots of Ajax to load specific
data as needed.)
--
Matt Silberstein
Do something today about the Darfur Genocide
Genocide is news | Be A Witness
http://www.beawitness.org
"Darfur: A Genocide We can Stop"
www.darfurgenocide.org
Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
| |
| Steve Sobol 2005-09-29, 3:25 am |
| Matt Silberstein wrote:
>
> Other than possible security issues, why? Wide adoption of Ajax is
> going to revolutionize what you can do with a website..
You just have to have Javascript disabled by default. Then, only enable it
for sites you trust. Not a big deal IMHO. *shrug*
--
Steve Sobol, Professional Geek 888-480-4638 PGP: 0xE3AE35ED
Company website: http://JustThe.net/
Personal blog, resume, portfolio: http://SteveSobol.com/
E: sjsobol@JustThe.net Snail: 22674 Motnocab Road, Apple Valley, CA 92307
| |
| Brian Wakem 2005-09-29, 6:24 am |
| Matt Silberstein wrote:
> The particular JavaScript use I have in mind is a dynamic "table"
> where the customer is going to be able to configure at will and add
> "rows". (I mean real tables and rows, not HTML markup.) Yes, I can
> play games with hidden rows and use CSS to show them, but that kind of
> trick will only take you so far. The other option is to send back to
> the server and re-do the page each time. For this application that
> will get very annoying. (I will also do lots of Ajax to load specific
> data as needed.)
When you are done it might be interesting to post the url here and we'll see
how many people can and can't use it.
--
Brian Wakem
Email: http://homepage.ntlworld.com/b.wakem/myemail.png
| |
| Matt Silberstein 2005-09-29, 6:27 pm |
| On Thu, 29 Sep 2005 09:22:15 +0100, in alt.www.webmaster , Brian Wakem
<no@email.com> in <3q1mhnFco2jjU1@individual.net> wrote:
>Matt Silberstein wrote:
>
>
>
>When you are done it might be interesting to post the url here and we'll see
>how many people can and can't use it.
I figure 6months or so of development so I am trying to figure the
market as best I can first. Right now I am thinking it is reasonable.
I'll let everyone know. (And then it won't be spamming, right?)
--
Matt Silberstein
Do something today about the Darfur Genocide
Genocide is news | Be A Witness
http://www.beawitness.org
"Darfur: A Genocide We can Stop"
www.darfurgenocide.org
Save Darfur.org :: Violence and Suffering in Sudan's Darfur Region
http://www.savedarfur.org/
| |
| Charles Sweeney 2005-09-29, 6:27 pm |
| Matt Silberstein wrote
[his new site/service/product/application]
> I'll let everyone know. (And then it won't be spamming, right?)
Correct.
--
Charles Sweeney
http://CharlesSweeney.com
|
|
|
| | Copyright 2003 - 2008 forum4designers.com Software forum Computer Hardware reviews |
|