RE: XHTML Applications and XML Processors [was Re: xhtml 2.0 noscript]

On Wed, 2 Aug 2006, John Foliot - WATS.ca wrote:
> 
> First, a "page" weighing in at 50 kb will take roughly 20 seconds to 
> fully load at 56 k baud.  This is certainly slow (I agree), but users at 
> this connection speed are accustomed to this speed of page delivery, 
> dynamic content or not.  So it may be frustrating, but I do not see 
> "harm".

Twenty seconds is eons in terms of a user's attention span. They may be 
used to their connection being slow, but that doesn't mean they're ok with 
it and don't mind waiting each time. I assure you, based on a number of 
usability studies and extensive experience reading user feedback for Web 
browsers, that users absolutely would not consider it acceptable for a 
browser to force them to wait those twenty seconds.


> I won't get into the whole "...event trigger needs to be input 
> independent" rant; suffice that it frustrates the hell out of me every 
> time I see "onclick" all by it's lonesome... Another discussion for 
> another day.

The onclick event handler is input independent. It really means "when 
activated"; it'll trigger for a mouse click, a pen tap, the enter key 
being pressed while the element is focussed, etc.


> My understanding in this discussion however is that the point of the 
> "return example();" is to somehow modify the way the page renders 
> *while* loading, as opposed to the final rendering being re-loaded in a 
> modified state - what is often referred to as AJAX today.

It could be anything. It could go to another page. It could pop up a 
dialog with more information. It could be a calculator. It could sort the 
data in a previous table. It doesn't matter.


> This presents some real serious usability/accessibility issues for those 
> users who, through no fault of their own, *must* await the final load of 
> the document so that the technology that they use to interact with 
> *that* mainstream browser will function.  Here I do see *harm*, if not 
> technical certainly in the fact that you have now given preferential 
> treatment to the sighted over the none-sighted - all in the name of 
> saving nano-seconds.

There is nothing forcing ATs from having to wait for the entire page to 
have completed rendering. If they do, then that is a bug in those systems.

Also, even if it _was_ the case that sighted people were being given an 
advantage of blind users -- which it is not, in this instance -- why would 
that be a problem? If it requires longer to render the page for one class 
of users than another, why should we drag *all* users to the lowest common 
denominator? Surely each user should be given the best experience possible 
for that user, even if other users can't get that experience.


> Now the simple fact of reading these instructions will consume some of 
> these precious nano-seconds we are apparently trying to save in the 
> user's life; perhaps by the time they are finished mentally scanning the 
> whole page and reading these instructions the page still hasn't 
> completely downloaded, but I really think you are attaching way more 
> "frustration quotient" here than is really warranted.

Users, as a general rule, simply don't real the majority of the text 
presented to them. This is obvious from watching any user for any length 
of time. So your argument is based on an incorrect assumption.

Even if it wasn't, yes, users want those precious milliseconds. It may not 
be rational, it may not be your own personal desire, but study after study 
that I have watched, bug after bug that I have seen filed, all point to 
the fact that users prefer browsers that let them interact with content 
before it has finished loading.


> And again, I am having a real hard time understanding what this *cost* 
> really is... User frustration for a nano-second?  How serious is this 
> really?

In practice, I believe that any browser that actually waited for the page 
to completely load before allowing interaction, when faced with competing 
browsers that are otherwise equal but _do_ allow interaction with 
incompletely loaded pages, would find itself losing all marketshare.


This argument is highly academic. There's no way you'll convince browser 
vendors to follow a "wait for load before interacting" processing model, 
whether for HTML or XML.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 3 August 2006 05:04:12 UTC