[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Microsoft's deeply cynical appealto"standards compliance"
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>
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|