RE: Distributed Computing Project Popularity

From: Alejandro Dubrovsky (s328940@student.uq.edu.au)
Date: Mon Jun 02 2003 - 15:43:19 MDT

  • Next message: naccts: "evolution and its implications."

    On Tue, 2003-06-03 at 06:11, Robert J. Bradbury wrote:
    > On Mon, 2 Jun 2003, Harvey Newstrom wrote:
    >
    > > Excellent paper, Robert! I have my browser set to prompt me on everything,
    > > so I can see what is happening, and reject/accept each item individually.
    > > Some sites have no idea that they are sending literally dozens of cookies
    > > and loading dozens of scriptlets just to load their welcome screen. No
    > > wonder they are so slow.
    >
    > Absolutely. I sent a letter to KOMO TV here in Seattle a couple
    > of days ago because whatever editor they are using to create their
    > web site is specifying alignments and fonts in *each* table cell
    > (rather than a table row or even the entire table). Very sloppy.
    > (rest of Robert's post at the bottom)

    But putting one for the row or the entire table isn't legal html, so
    that would be worse (the font tag itself has been deprecated since
    around 1997 but at least most browsers will work with the font tag in
    each cell, putting a font tag around a whole table won't work on most
    browsers) . The "standard" (as in w3c standard) way to do it would be
    using stylesheets, but then your seemingly favourite browser (Netscape
    4.x) would not render it properly since it's one of the most standard
    non-compliant browsers around.
    In any case, web designers very rarely hand write, see, or even
    understand their html. It is 99% produced by tools, so if anyone should
    be pressured then it should be the tool producers (eg Macromedia,
    Microsoft)
    Your assumption about the correlation of rendering times (below) accross
    browsers doesn't always hold, especially if you are taking Netscrape 4.x
    as your base, since that browser has severe problems with (tables inside
    tables)^n, where n is bigger than around 6 or 7. This situation is not
    completely atypical among pages but Netscape's algorithm seems to be
    polynomial to the nth so it tends to chug in a very ugly way in cases
    where IE wouldn't even notice (btw, i don't use or like IE, but nothing
    beats it for speed).
    Cookies are almost harmless helping tools if implemented properly. They
    also make tracking on the id of a registered entity to a site practical
    to use for most web developers. Cookies mainly get a bad rep from bad
    security on the browser side.
    Scripts have a million helpful uses (validation on forms, hover help,
    multi-select addition/deletion) and telling people to write less usable
    sites so that browser writers can get away with weaker interpreter
    implementations seems like overkill to me. Switch to a different
    browser and turn pop-ups off, and if you dislike the scrollers turn off
    the time-interrupt functions too, but don't force the multi-hundred
    million users to go through a submit, refresh to find out they forgot to
    fill in the required "state" field at the bottom of the page.
    (The funny thing is I agree with the sentiment of your post, it would be
    good if pages where w3c compliant and they all went through html tidy
    with no warnings, but your suggestions are the wrong option to me.
    Upgrade to IE 6/Mozilla/Opera/Netscape 7/Galeon/Konqueror/whatever, they
    are newer, they are better, don't force designers to support the
    brokenness of the Netscape 4.x/IE4 hell days)
    alejandro

    > Perhaps someone (or preferably a several someones) should cruise
    > on over to the Mozilla web site and request "enhancements"
    > to the browser pages that make it clear in some bright red font
    > the actual page size and the actual download time. If one got
    > Mozilla to add these it would create pressure on Microsoft, Opera,
    > etc. to add the same features as well as put pressure on developers
    > to make their pages "cool" by making them "fast".
    >
    > For example, I've noticed over the last several days that the
    > Nature web site (http://www.nature.com) has very long page display
    > times in the old browser that I am using (Netscape 4.79). But if its
    > slow in the old browsers, its probably slow in the new browsers
    > (from a comparitive standpoint). Slower is *bad* -- it retards
    > the progress of scientific learning, interaction, resolution of
    > different opinions, etc.
    >
    > In response to Harvey's meta-question regarding "what are we doing?" --
    > can we complain to Nature in sufficient numbers that they actually
    > *fix* the damn website so it is fast rather than pretty?
    > One can get the customer service contact info here:
    > http://nature.custhelp.com/cgi-bin/nature.cfg/php/enduser/std_adp.php?p_sid=9bPUKLKg&p_lva=&p_faqid=226&p_created=1043771300&p_sp=cF9zcmNoPSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MTExJnBfcGFnZT0y&p_li
    >
    > If one is a non-customer, then one can complain that the "customers"
    > (or former customers in my case) complain that the pages are poorly
    > designed and take too long to display -- after all not everyone
    > has a Pentium 4 or uses IE 6.x.
    >
    > It is very easy for me to judge this on windows. I simply have
    > the "Windows Task Manager" running (but minimized) most of the
    > time and watch the degree of CPU usage when I am doing something.
    > When I open a Nature page in a browser the CPU pegs at 50%
    > activity (its a dual CPU machine and most browsers are single
    > threaded) and it stays there for many seconds until the page
    > actually displays. Has to be poor page design.
    >
    > Of course the same applies to loading many cookies or scripts as
    > Harvey points out. Such is a sign of either (a) careless page design
    > or (b) seeking to control of the downstream computer in some way.
    > What is needed is better feedback tools so one can place pressure
    > on website designers to clean up their acts.
    >
    > Robert
    >
    >



    This archive was generated by hypermail 2.1.5 : Mon Jun 02 2003 - 15:53:31 MDT