Re: [xml-dev] Microsoft's deeply cynical appealto"standards compliance"

[Dennis Sosnoski <dms@sosnoski.com>]

Elegant execuses for incompetence, Joshua.

Personally I think it's wonderful when MSNBC breaks with different browsers, I
wouldn't trust anything from the site anyway and avoid it like the plague.
What's scarier is when supposedly sophisticated corporate sites break with
server-side errors. A good example is Compaq - trying to get to their "At Home"
notebooks description at
http://athome.compaq.com/default.asp?ProductLineId=440&page=families using
Mozilla gives:

  Microsoft VBScript runtime  error '800a000d'
  Type mismatch: 'Cint'
  /default.asp, line 172

This isn't exactly encouraging for a site that bills itself as an ecommerce
leader (if they can't get this straight, I shudder to think what their security
is like on the purchase pages). I've emailed them twice about this over a period
of weeks - I'm shopping for a new notebook right now and wanted to view their
product information - but haven't even received a reply. I've seen the same sort
of thing at other sites, too.

Mozilla is the base for Netscape 6+, so there's really no issue of compatibility
here - the two are at least as compatible as different patch levels of a single
IE version. The real issue is that the developers building these sites are
incompetent and the management either doesn't know or doesn't care.

  - Dennis

Joshua Allen wrote:

> > > I'm inclined to agree with Joshua Allen:  this was probably
> nerd-level
> > > decision by someone who doesn't see the big picture, and who is
> about to
> >
> > But even that would still show a culture in which some employees  feel
> > free to screw people to win.   I hope the new judge in their
> sentencing
>
> I'm not certain that "screw people to win" follows.  Now that the
> "clarifications" and "adjustments" have been made [1], I can share my
> experience with similar situations. From work with a number of
> non-Microsoft customers who are managing high-volume web sites, I have a
> feeling that the issue of how far to go in supporting all browsers is a
> common thing that IT managers worry about.  Here is the way I think most
> sites view the problem:
>
> A. If a site uses even moderate JavaScript and CSS, the site has to
> maintain different code for different browsers.  Typical would be one
> set of routines for IE5, one for Netscape 4.x, and another for Netscape
> 6 and IE6 (since IE6 and Netscape 6 *finally* can share most of the same
> code).
>
> B. Between IE 5+ and Netscape 4+, you have more than 90% of the browser
> market.  To target this 90%, you are probably going to be maintaining
> three separate branches of code.  Any IT manager is going to be weighing
> the cost of maintaining custom workaround code against the number of
> incremental users she will get.  This is not necessarily about standards
> -- for example, if Netscape 6 and IE 6 let you use the same non-standard
> code to do something, and some browser with 1% market share is the only
> one to support the functionality using the correct standards approach,
> the IT manager is still going to put more priority on the 90% of users,
> even if it means a non-standard implementation.  Taking this idea
> further, how about WML/HDML devices?  They represent a pretty huge
> number of devices, but are a *tiny* portion of web traffic.  Targeting
> these web clients is expensive in terms of learning curve, dev effort,
> and test (talk about behavior that differs from device to device).
> Making a decision to get to the extra 0.1% of users who might use a WML
> browser is probably a more than 100% cost increase.  Most sites don't
> bother.
>
> C. Besides the cost of maintaining three separate implementations of the
> same functionality, every new browser and platform you support adds
> significant testing cost.  IE for Mac and IE for Windows didn't always
> behave the same (maybe still don't).
>
> D. There are probably less than 1% of public Internet sites that test
> their functionality against all (or even 99%) of the web browser and OS
> combinations that their users will be using.  This means that there will
> always be certain browser/platform combinations that will have NEVER
> BEEN TESTED for a certain site.
>
> E. Depending on the nature of a web site, the possibility that users
> could be "muddling along" using a browser that is completely untested
> can be very worrisome.  Banking sites, sites that sell expensive items,
> etc. can be very paranoid about this.  For example, if the site
> developers are relying on some non-standard behavior without realizing
> it, and have tested with Netscape and IE and it works, then they feel
> comfortable committing to support orders that are placed with Netscape
> and IE.  But then suppose a user comes along with a browser that
> actually implements the standard *properly* (the bank never tested with
> that browser), and the user gets 10x the proper amount deducted from his
> bank account.  Obviously this is a contrived scenario, but the point is
> that some IT managers will be very paranoid about committing to support
> something that they have not explicitly tested, and they will prefer to
> reject everything that doesn't match what they designed and tested for,
> so as to not take any risks.  Another reason that people get worried
> about supporting other platforms is simply for tech support costs.
> Quick example would be some site that uses JavaScript to post an order
> confirmation.  This is a bad design, but it happens; maybe they did it
> because they didn't know any better.  So anyway, they test the site with
> the 90% case, and it works in all their test cases.  Then they start
> getting phone calls from people who are upset about the order form not
> working.  They cannot figure out what the heck is wrong, and churn
> through tons of troubleshooting effort and loss of customers before they
> realize what is wrong and fix it.
>
> Anyway, I am in no way implying that this path of reasoning had anything
> to do with MSN, but am simply saying that these are some common and
> fairly innocent reasons why people choose to leave certain browsers
> unsupported on high-volume sites.  I also think that there are better
> ways to approach the problems than to block arbitrary useragent strings:
>
> * First, site developers can test for browser capabilities using code
> that silently attempts "testing" the things the site needs to do.  Using
> a useragent string to determine capabilities is horribly unreliable, but
> just reliable enough that it makes you think that your site is working
> and makes it impossible to figure out why when it breaks ("What?!? You
> mean that version X of Browser Y claims to be running on a PC when it is
> running on a Macintosh?!?" -- true story).  I have been burned too many
> times; never trust the useragent string.  People spoof it, and vendors
> screw it up.
>
> * Next, if your site is not tested with certain browsers and you care
> about your users' browsing experience, have the site warn them that they
> are using an untested configuration.
>
> * If you absolutely can't risk untested behavior, go ahead and try to
> control what browsers are used.  Not many places can get away with
> this..
>
> So the questions that most IT shops have to balance are:
> - How much do I want to spend designing and maintaining this site?
> - What percentage of potential web clients do I need to target?
> - What are the potential consequences of letting an untested client hit
> the site?
>
> [1] http://news.cnet.com/news/0-1005-200-7660935.html
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>