Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Accurate Browser Statistics?

Cliff posted more than 7 years ago | from the determining-browser-share dept.

The Internet 137

zyl0x asks: "A co-worker of mine has been made responsible for a large web application for our software product, and he was having a hard time deciding what functionality to implement, and whether or not to sacrifice functionality for a larger user base. With Walmart's harsh stand on browser compatibility, we got to thinking, exactly how many users would we be alienating by using some IE-only functionality on our website? We tried crawling the internet to get some current, accurate browser usage statistics, but we could only find stats for specific websites. I thought I'd try sending Google a request, since we imagine they'd have the lowest-common-denominator in terms of types of users, but I received an email from their press department telling me that they 'don't make that kind of information available.' Where can one get a current, accurate, and un-biased measurement of browser usage? Is it even possible?"

cancel ×

137 comments

Sorry! There are no comments related to the filter you selected.

Depends on your audience (5, Insightful)

Kelson (129150) | more than 7 years ago | (#17986624)

Browser marketshare varies widely according to audience. And by audience I mean not just people's interests, but their geographic location. Opera is used more in Europe than North America. Firefox is used more by visitors to techie sites than by visitors to entertainment sites. I've got one site where Firefox accounts for 20% of visitors, second to IE at 70%, and another where Firefox is #1 at 44% and IE is #2 at 40%.

Firefox, the second-most-used browser, seems to have a marketshare of 10-20% depending on where you look. So you'll probably be blocking at least 10% of potential users, if not more, by restricting your site to IE users only. And that percentage continues to grow.

Keep in mind also that IE is only available on Windows (not counting emulation, which is of limited use). The Mac version has been discontinued. Unless you want to block all Mac users, you'd better provide at least Safari or Firefox compatibility.

Also, any site that already restricts browser access is going to have skewed results, because the potential audience using other browsers has either cloaked their browser to look like the supported one, or has gone somewhere else.

Since you say this is a new application, you'll want to get statistics from a similar product that works cross-platform.

Re:Depends on your audience (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#17987004)

macs, lol.

Yes, Macs (2, Insightful)

Kelson (129150) | more than 7 years ago | (#17987118)

macs, lol.

Hey, if you want to block millions [lowendmac.com] of potential visitors, that's your prerogative. Personally, I'd like to keep the doors open for them.

Re:Yes, Macs (4, Interesting)

99BottlesOfBeerInMyF (813746) | more than 7 years ago | (#17987344)

Hey, if you want to block millions of potential visitors, that's your prerogative. Personally, I'd like to keep the doors open for them.

I've always felt that online retailers who neglect the mac Web share are really making a big mistake. Say they are 5% of Web users. Which 5% are they? Well, they are the ones with disposable income who can afford to shell out more for a computer. That means you've eliminated the 40% of Windows users who are pirating it in a country that does not enforce copyright law well. When it comes to potential customers, unless you're selling a product that only works on Windows you are actually cutting out more like 10-15% of your potential customers, and it is one of the most affluent chunks of that total market. It seems like a pretty poor idea to me.

Re:Yes, Macs (0)

Anonymous Coward | more than 7 years ago | (#17989178)

Totally; retailers that block out Mac users are definitely making a mistake.

Don't want to block the all-important "more money than sense" demographic...

Thank you, I'll be here all night. Try the veal.

Re:Yes, Macs (1)

KDan (90353) | more than 7 years ago | (#17990218)

Wtf is wrong with y'all? Haven't you heard of W3Schools? There's your answer:

W3Schools Browser Stats [w3schools.com]

Full breakdown, data going back to 2002, good selection of sources... what more do you want???

Daniel

Re: Wikipedia Browser Stats (2, Informative)

bunratty (545641) | more than 7 years ago | (#17990398)

A wider range of visitors than "people with an interest for web technologies" perhaps?

How about Wikipedia's browser stats [wikipedia.org] ? It lists stats from many different sources, not just one web developer oriented site.

Re:Yes, Macs (0)

Anonymous Coward | more than 7 years ago | (#17987418)

Yeah but, they wouldn't want my software anyway because it's customizable. They hate that.

Like a Mac user would shop at Walmart! (0)

Anonymous Coward | more than 7 years ago | (#17987598)

lol

More than Firefox (2, Informative)

Kelson (129150) | more than 7 years ago | (#17987038)

I forgot to mention in the first post, that it's more than just Firefox growing [informationweek.com] . Safari and Opera may be relatively small, but they're gaining as well. And there are quite a few other modern browsers [alternativ...liance.com] around. You can expect several of them to grow over the next couple of years, probably at IE's expense.

So even aiming for just IE+Firefox support isn't enough to be sure that you're not still turning people away. Fortunately, many of the lesser-known browsers share the same rendering engine (or a variation thereof) with Firefox or Safari, making it easier to keep compatible. You basically have to target the standards and test in Gecko, IE, Opera and KHTML/Webkit.

Re:More than Firefox (2, Informative)

JuliaNZ (17473) | more than 7 years ago | (#17988446)

Safari and Opera may be relatively small, but they're gaining as well.

I don't see this. I look after about 20 recruitment websites in Australasia across a number of industry sectors. (The sites are almost all designed and tested for a wide range of browsers, screen sizes and platforms so I'm not trying to exclude anyone at all.)

IE is still a solid 85-86% on our sites, with Firefox breaking the 10% barrier recently. Firefox has been slowly and steadily growing in an almost perfect linear fashion during the whole time I've been running these sites, but a fair bit of that growth seems to have come at the expense of other "alternative browsers". Things like the Mozilla suite and Netscape 6+ are dropping completely off the graphs now. Opera now barely ever registers more than half a percent, and Safari has been fixed at about 1.6 - 1.8% for a long time even though Mac usage has (just) broken the 2% mark.

Re:Depends on your audience (5, Informative)

99BottlesOfBeerInMyF (813746) | more than 7 years ago | (#17987168)

Browser marketshare varies widely according to audience.

I'll second this. I do a little work on a Web based interface to a security product for very, very large network operators who can afford to shell out the big bucks. A major portion of our interface was nonfunctional in IE for about a year and a half before anyone noticed because all our customers use Firefox or Safari or Opera or Lynx. If you're actually trying to find information that is practical for your application you need to look at your market segment and similar sites.

Also, any site that already restricts browser access is going to have skewed results, because the potential audience using other browsers has either cloaked their browser to look like the supported one, or has gone somewhere else.

Yeah, IE only sites skew numbers because people fake it or go elsewhere. Likewise, sites that are defaults for a browser (like Google for Firefox or MSN for IE) will have results skewed towards that specific browser, so Google's numbers would not have been all that useful to you. Look for a Web site that targets the same demographic, but does not have any of these factors to muddle the numbers.

I'd also like to echo other people here in voicing another argument against IE specific Web services. No one knows what the market share in five years is going to look like, and ripping out your working solution because IE is down to 50% would be a horrible snafu. Further, as more and more devices start to provide Web browsing capabilities, like phones, PDAs, PVRs, and televisions, standards become more and more important. Your company itself could standardize on Linux from some vendor in the next 5 years. It doesn't hurt to be a little forward thinking and keep your tools flexible. There just isn't much you could not implement to be cross-platform if you have a competent developer, and if you don't you're likely to have all sorts of other problems as well.

Re:Depends on your audience (1)

jimstapleton (999106) | more than 7 years ago | (#17987592)

Very good poitns here.

Also, I know Safari is based off of Konqueror, and both are pass ACID2 (I think Opera does as well?)

So by having one of these in your compatability list, that should implicitly add the rest, even if all are a relatively lower market share compared to IE/Firefox.

Re:Depends on your audience (1)

great throwdini (118430) | more than 7 years ago | (#17987848)

Also, I know Safari is based off of Konqueror, and both are pass ACID2 (I think Opera does as well?)

So by having one of these in your compatability list, that should implicitly add the rest, even if all are a relatively lower market share compared to IE/Firefox.

This reasoning is nonsensical. The relation between "passing ACID2" and real-world site development isn't automatic. The scope of the ACID tests is narrow, and it's a trivial exercise to produce content that adheres to existing recommendations that browsers "passing ACID2" handle in varying and deleterious fashion.

Not to mention that ... (1)

hummassa (157160) | more than 7 years ago | (#17988786)

After one version of a browser passes ACID2, regressions can make it not pass again after a while (konqueror/kde3.5.6 does not pass ACID2 -- at least on my machine)

Re:Not to mention that ... (1)

great throwdini (118430) | more than 7 years ago | (#17989194)

After one version of a browser passes ACID2, regressions can make it not pass again.

While this is certainly true, it doesn't validate ACID2 as a reliable (let alone sole) measure of any browser's competence in handling recommended development guidelines.

Re:Depends on your audience (0, Flamebait)

MaggieL (10193) | more than 7 years ago | (#17987608)

Browser marketshare varies widely according to audience. And by audience I mean not just people's interests, but their geographic location.

Not to mention IQ and gullibility index.

Re:Depends on your audience (1)

evought (709897) | more than 7 years ago | (#17988466)

Browser marketshare varies widely according to audience.


Another thing to consider is the reverse: audience may vary by browser. For instance, some studies have shown that Mac users spend more on software and peripherals per capita. Certain categories of users may have different amounts of disposable income and different amounts of interest in your product and that may be correlated to browser use, so alienating certain categories of users may have more (or less) effect than the raw percentages suggest. I would suggest being very careful before considering a business strategy which includes standing at the door to your store and telling one in ten or even one in twenty of your customers that their business is simply not wanted. Consider a bank drive up which did not do business with customers who drive up in a Mercury.

These aren't the browser stats you're looking for (4, Insightful)

Tumbleweed (3706) | more than 7 years ago | (#17986648)

Unless you are Google, don't worry about what Google's browser stats are. Instead, look at the browser stats of your OWN web site. Those are your customers.

I''ll mostly refrain from talking about the monumental stupidity of using IE-only functionality because I know the Slashdot crowd will be (justifiably) beating your head in over that momentarily. Good luck with that.

Re:These aren't the browser stats you're looking f (1)

hobo sapiens (893427) | more than 7 years ago | (#17987046)

Dang, and I was gonna beat him over the head, too. Too busy laughing at your reply to beat anyone. Well played.

Re:These aren't the browser stats you're looking f (1)

Scyber (539694) | more than 7 years ago | (#17987222)

Unless you are Google, don't worry about what Google's browser stats are. Instead, look at the browser stats of your OWN web site. Those are your customers.

Well if you have a website that doesn't work well enough in non-IE browsers, most likely those users won't return. Which means that using your own statistics will only reinforce your perception.

Re:These aren't the browser stats you're looking f (1)

Real_Reddox (1010195) | more than 7 years ago | (#17987782)

I see your point, but most people use google, no matter what their interests are and if they are advanced users or n00bs.

Re:These aren't the browser stats you're looking f (2, Insightful)

Bogtha (906264) | more than 7 years ago | (#17987970)

Unless you are Google, don't worry about what Google's browser stats are. Instead, look at the browser stats of your OWN web site.

No, this is bad advice too. Walmart's just built a web service that only works in Internet Explorer. How many non-IE users do you think they are seeing in their logs compared with IE users? Looking at your current users can only tell you to keep doing more of the same.

What you need to measure is not what your current visitors use, but what your target audience uses. Unfortunately, the web wasn't built around this kind of need, HTTP is a stateless protocol with unreliable user-agent identification. What you need is good old-fashioned polling. In-band data can be skewed beyond usefulness.

Re:These aren't the browser stats you're looking f (1)

Tumbleweed (3706) | more than 7 years ago | (#17988740)

No, this is bad advice too. Walmart's just built a web service that only works in Internet Explorer. How many non-IE users do you think they are seeing in their logs compared with IE users? Looking at your current users can only tell you to keep doing more of the same.

That's a good point, but I was thinking from the point of view that they hadn't already implemented IE-only stuff.

It IS really annoying that Google doesn't release their browser stats; I don't know what their reasoning is on that one. I'd also like their stats on screen resolution (and window) resolution.

Re:These aren't the browser stats you're looking f (1)

Bogtha (906264) | more than 7 years ago | (#17989728)

Google used to include some of this information in their Zeitgeist, for example see December 2001 [google.com] . But just because they have representative users, it doesn't mean they can collect representative data from traffic analysis. Browser market share data culled from web statistics is good for entertainment, not for basing important decisions on.

Re:These aren't the browser stats you're looking f (2, Interesting)

tverbeek (457094) | more than 7 years ago | (#17990000)

But just because they [Google] have representative users
Actually they don't. Their user stats are skewed away from IE users, because IE's default home page (which a surprisingly large number of people leave as their browser's home page) is MSN.com and its default search is Microsoft's; and they're skewed toward Firefox users, which have Google as their default home page and search engine, and slightly skewed toward Safari which uses Apple.com as its default page but Google as its default search engine.

Re:These aren't the browser stats you're looking f (1, Funny)

Anonymous Coward | more than 7 years ago | (#17988094)

Thus retorted the owner of the 10th floor stairs-only accessible wheelchair store out the window to a customer on crutches at ground floor:

"Only abled bodied people buy wheelchairs! What the hell do you want one for?"

And so ignorance becomes truth.

Re:These aren't the browser stats you're looking f (1)

rainman_bc (735332) | more than 7 years ago | (#17988670)

Unless you are Google, don't worry about what Google's browser stats are.

Thing is Google probably has the largest sampling available meaning that their numbers will be most accurate about true browser market share.

As another poster pointed out, your web server logs will reinforce the policy your web site's already had, proving nothing to PHB's about enhancing your compatibility.

A good conversation with a PHB would be: Our users on our sites are 99% IE. IE is 80% of the market, therefore in the long run we stand to grow our business by 20% if we start supporting all browsers, and you stand to make 20% more money.

Re:These aren't the browser stats you're looking f (2, Insightful)

Tumbleweed (3706) | more than 7 years ago | (#17988788)

I wonder if Google's stats might be a bit non-IE-centric, though, as IE browsers default to MSN searching, don't they? I guess that might apply to any non-MSN site, though. It would be interesting to base stats on router traffic rather than web sites. Is anyone making that kind of info available for free?

It almost doesn't matter what percentage... (5, Insightful)

ivan256 (17499) | more than 7 years ago | (#17986732)

Is 1% of your expected revenue greater than the implementation costs of supporting multiple browser platforms?

For almost every site out there, the answer to this question is "Yes". If you are in that situation, it would pay for you to use technology that would work on all browsers, or have a browser specific page with equivalent functionality for non-IE browsers. You often see Slashdot comments in these types of threads that say the "extra 5% of the market is too small for the company to care about". Sure, 5% seems small, but the costs of developing cross-platform support for web applications is usually so low that you're throwing away free profit by ignoring even the least-used browsers.

There are other arguments too... Many IE specific features are annoying even if you are an IE user, Using technology that isn't standardized across the industry make maintenance more difficult across platform versions, etc... But really it comes down to the money.

Re:It almost doesn't matter what percentage... (0)

Anonymous Coward | more than 7 years ago | (#17987674)

I don't think I'd go quite as far as supporting the least-used browsers personally (too much testing, too much browsers and OSes out there), but developing for all the main ones is rather easy (and not that expensive).

I develop for/using firefox primarily (mainly because of all the dev tools, like the web developer toolbar, firebug, etc), and use hacks where necessary to make it work in IE. Then we test on most of the others (opera, konqueror, galeon, epiphany, netscape, etc), and they almost always all work fine on the first attempt.

But testing for lynx, webtv and things like that? No way. We never see anything like that in our logs, and I believe there's a limit to how accommodating one can be to esoteric platforms. It's THEIR choice to use something weird, and they have to put up with the consequences. We develop using standards, and test using perhaps more browsers/platforms than we should bother with in the first place. If they chose something else that's not so much standards compliant and doesn't work right, it's their own fault, and most likely 99% of the other websites don't work right on that either.

Re:It almost doesn't matter what percentage... (3, Insightful)

dvice_null (981029) | more than 7 years ago | (#17988268)

> But testing for lynx, webtv and things like that? No way.

Testing with Lynx is actually quite a good idea. Not only will you make sure that blind people can see your site, you can also confirm the complexity of your website and how easily information can be found from there.

Re:It almost doesn't matter what percentage... (1)

Johnny Mnemonic (176043) | more than 7 years ago | (#17989062)

It's THEIR choice to use something weird

It's YOUR choice to ignore customers. If the support and dev costs for WebTV is less than what you'd gain by including them as customers, you're simply making a bad business choice. Serving customers and making sound business decisions is usually not about convenience.

Re:It almost doesn't matter what percentage... (2, Insightful)

FLEB (312391) | more than 7 years ago | (#17989940)

I don't know as if I'd go as far as developing for Lynx, but it's definitely good to see that your site maintains some sort of semantic sensibility when viewed in Lynx-- when you're using it, you get text and only text, and that's how screen readers and (most importantly) search engines will be reading your pages.

Bad faith (1)

Rob T Firefly (844560) | more than 7 years ago | (#17986766)

The reason there is such a thing as IE-only functionality is the fact that one powerful company wants to break the open platform and force people onto theirs, in order to fill their own pockets. This is not something I wish to support in the least, so I don't create, use or promote any web-based things that require IE.

Re:Bad faith (0)

Anonymous Coward | more than 7 years ago | (#17990084)

I've taken it 1 step further by inserting some HTML known to crash I.E. in my top level page.

If they skip the top page, my picture gallery doesn't work with I.E. for some reason that I haven't bothered to figure out. Not my problem since I follow normal HTML standards.

Yes, I am easily amused. I recognize this.

Compatability still a big problem? (3, Insightful)

LighterShadeOfBlack (1011407) | more than 7 years ago | (#17986790)

Just curious, what kind of IE-only content are you talking about here? Granted I've never developed a commerical web app but I haven't come across any major obstacles to implementing cross-browser functionality in anything I've written in recent years. OK so I usually end up with a couple of dozen IE-specific fixes that have to be made and maybe some browsers get less functionality than others but I've not come across anything which worked on one browser that couldn't fail gracefully on another.

Or am I just being ignorant in thinking this isn't really a major problem anymore?

Re:Compatability still a big problem? (4, Insightful)

hobo sapiens (893427) | more than 7 years ago | (#17987154)

Or am I just being ignorant in thinking this isn't really a major problem anymore?
It shouldn't be. These days, coding websites for IE only reflects the web developer's utter lack of current knowledge. It's like saying "Help me! I seem to have fallen in 1997 and can't get up!" It takes virtually no extra work to write stuff cross browser (or at least close enough), and if you think it does take too much work then your skills aren't what they should be. Just use web standards. Couple that with the good ole KISS* principle, and presto. Anyone who doesn't get that should never ever again write another web interface, IMO.

*you know: Rock and Roll all night, Party everyday! (yes, I couldn't resist)

Mod parent up (1)

Dadoo (899435) | more than 7 years ago | (#17987278)

Wouldn't you know, I just lost my mod points. :-(

Re:Compatability still a big problem? (2, Interesting)

AKAImBatman (238306) | more than 7 years ago | (#17987878)

It takes virtually no extra work to write stuff cross browser (or at least close enough), and if you think it does take too much work then your skills aren't what they should be. Just use web standards.

Correction: It takes virtually no extra work to write stuff for all browsers except when you need to support IE for non-trivial work. Getting things working in IE is a pain due to its lack of standards support, and shouldn't be necessary. Thankfully, it's possible to maintain a small list of Javascript and CSS patches that can take care of 95% of the issues. The rest can be fudged so that IE works "ok". It's just that it's not pleasant to do things like maintain an IE-specific style sheet.

Re:Compatability still a big problem? (1)

hobo sapiens (893427) | more than 7 years ago | (#17988114)

thank you for the refinement. damn straight!

Re:Compatability still a big problem? (1)

anomalous cohort (704239) | more than 7 years ago | (#17989702)

Getting things working in IE is a pain due to its lack of standards support

There are lots of folks who have already incurred this pain for you and have written books and/or javascript libraries that you can use to mitigate the pain.

Re:Compatability still a big problem? (1)

davido42 (956948) | more than 7 years ago | (#17988344)

I wrote my code using alleged "web standards". I used Firefox as my development browser. I'll give you 1 guess as to which browser was not compatible with my code. (Hint: starts with the letter 'I' and ends with the letter 'E')

To be fair, it is more accurate to say that IE was not as resilient to my bugs as Firefox and the other browsers (Safari and Opera were also tested). It's still not completely compatible, but I bludgeoned it into submission so that IE is functional. I'm really looking forward to checking it out on Mom's Win98 machine. Ugh.

http://www.bitworksmusic.com/ [bitworksmusic.com]

Re:Compatability still a big problem? (1)

hobo sapiens (893427) | more than 7 years ago | (#17989138)

Welcome to life as a web developer. IE sucks. Repeat that like a mantra and you'll get by just fine.

In all seriousness, you will in time learn what to do and what not to do in order to appease IE, the worst piece of software ever invented. Stay the course and code to standards and 99% of the time you'll be just fine.

This is also why I alluded to the KISS principle: if you can, avoid complex stuff. Less for IE to break. Part of coding to standards is, at least in spirit, simplicity.

For times when you just have to get fancy, you just have to learn what IE wants. An example: building table rows via javascript. didjaknow IE *REQUIRES* that you use a tbody tag when appending table rows? IIRC failure to do so won't give you an error, but it sure won't work. So before you get happy and appendChild(myrow) into the table, you gotta have a a tbody. Not sure if that's a misinterpretation of standards or what, but no other browser requires that you do this. Again, that's what sometimes happens when you get fancy. Far worse would be to avoid standards and use IE-only code. Strictly speaking, one could argue that what I mentioned has little to do with the standards you use when writing markup. True, but it does illustrate that IE is a very odd browser. Good web developers have to take the shotgun approach and code to standards, and then fill in the holes IE creates for you. And Microsoft shows little interest in fixing things. They have the market share and to hell with everyone else including the people who develop the software that runs in their browser. I hope IE gets displaced very soon, but I am not optimistic that it ever well.

The short of it: blame IE and not the standards. Learn to deal with it.

Re:Compatability still a big problem? (1)

Bogtha (906264) | more than 7 years ago | (#17989862)

So before you get happy and appendChild(myrow) into the table, you gotta have a a tbody. Not sure if that's a misinterpretation of standards or what, but no other browser requires that you do this.

That actually sounds like every other browser has it wrong and Internet Explorer has it right (yes, in certain rare occasions, it has been known to happen). In HTML, every table with one or more rows has a <tbody> element. Just because the tags aren't in the HTML, it doesn't mean the element isn't there. <tr> elements cannot appear as direct children of <table> elements, the HTML parser understands that there is an implied <tbody> element and inserts it automatically. This is correct behaviour. If you don't believe me, start Firefox, open a test page, and fire up the DOM inspector. The <tbody> element will be there.

Now, that's all well and good, but the DOM doesn't have any concept of implied elements. That's a feature of the HTML parser, not the DOM. So if you are trying to table.appendChild(row), then it literally means that you want the row as a direct child of the table. That's not correct HTML.

Re:Compatability still a big problem? (1)

hobo sapiens (893427) | more than 7 years ago | (#17990714)

Interesting. I figured that the thead/tbody/tfoot were optional. However, using Firebug's DOM inspector (If you don't use Firebug for Firefox, get it!), I see that the tbody is implicitly created despite the fact it's not in the actual source code. Oddly enough, thead and tfoot are not. But that does seem to support what you are saying, namely, that the HTML parser implicitly creates it. Personally, I don't like implicit in cases like this. Anyhow, I think you are right.

Well, then here is yet another argument in favor of confining your coding practice to one browser. Writing code for just one browser is bad regardless of browser.

Re:Compatability still a big problem? (1)

Bogtha (906264) | more than 7 years ago | (#17990922)

I figured that the thead/tbody/tfoot were optional.

Well <tbody> is optional in XHTML, and <tr> elements can appear as direct children of <table> elements. This is one of the things that trips up people who think that the difference between HTML and XHTML is just in the error handling, lowercase element type names and closing every element explicitly. The following code actually means different things depending on whether it's parsed as HTML or XHTML:

<table>
<tr>
<td>...</td>
</tr>
</table>

That's why, if you are writing XHTML, you actually have to test it in both text/html and application/xhtml+xml modes before you can say with any confidence that your code is bug-free. Sure, validation helps, but a validator isn't going to catch when your JavaScript expects a <tbody> and it's only there when you serve your pages as text/html.

Re:Compatability still a big problem? (1)

8-bitDesigner (980672) | more than 7 years ago | (#17989454)

Now, I wouldn't say that it's just as easy as "Use web standards" as IE6 does a good job of buggering that up. Honestly, it requires a bit of time and dedication, and depending on the complexity of your layouts, a near encyclopedic knowledge of IE6 specific bugs and accoutrement workarounds, but it's sure as hell worth the effort when you're re-laying content and adding new pages daily.

Yeah, internet Explorer 7 is still shit. (1)

Colin Smith (2679) | more than 7 years ago | (#17987224)

IE 7 is better, but the support for Cascading Style Sheets is still shite.

 

Re:Compatability still a big problem? (1)

Student_Tech (66719) | more than 7 years ago | (#17988174)

I'm not sure if this is an IE-specific, but it does limit who can use their page.
OK full details:
1. Mom finds sight that sells stuff to only retailers (not a problem as she runs a store and this would be good for the store).
2. Fills out stuff, gets a username and password.
3. Go to sign in, prices don't work. She complains and they ask what version of IE she is running? (She's running Firebird 0.7 aka Firefox 0.7 IIRC)(It's a Win95 machine that my parents don't feel like moving off of quite yet. It is hidden behind a firewall)
4. I look at it. Sign in page is located like "/sys/login/" or something.
5. When You login the cookie sent back from their server has "path=", So no path. (Yes, it has "path=;" in it) Spec I can find (and Firefox and Opera seem to follow) is that if no path is specified, then you use the path of the page. IE does something else.
6. Attempt to view page with prices located at like "/catalog/". IE shows prices because it is sending the cookie. Firefox and Opera don't send the cookie because the path is different.
7. We email back to them what I found, haven't heard anything back yet.

At least, this is my best guess as to why the prices show up in IE (tested with 5.5 and 6, don't have access to 7), and not Firefox or Opera.

An IE requiring site because of the way the path in the cookies is set.

Enter webcomics... (4, Informative)

strredwolf (532) | more than 7 years ago | (#17986804)

Take it from a site that hosts 6000+ webcomics, so you get a good sense of what's being used out there.

On average from CG, from the top of my head (not accurate!!!):

* Firefox/IE are major contenders -- ether one or the other flops back and forth the lead.
* Safari rounds out the third
* Konqueror, Opera, Netscape 4, and web spiders scrape out the distant rest.

What I would do is follow Google Mail's lead: Make a javascript version and a non-js version, and if there's a browser not on the tested whilelist, go non-js.

Re:Enter webcomics... (2, Funny)

CrimsonBadger (983178) | more than 7 years ago | (#17986886)

I think that readers of webcomics are significantly more likely to use Firefox than the average internet user.

Well dùhh! (1)

JamesTRexx (675890) | more than 7 years ago | (#17990134)

That's because Firefox has something that IE doesn't have: cool wallpapers [vegard2.no] ! (warning: NSFW!)

Re:Enter webcomics... (3, Informative)

Bogtha (906264) | more than 7 years ago | (#17988036)

Make a javascript version and a non-js version, and if there's a browser not on the tested whilelist, go non-js.

In the particular case of JavaScript support, this is poor design. Identifying and testing in browsers is a slow, unreliable process, and needs constant maintenance as new browsers come out. It's been best practice for years to use feature/object detection [quirksmode.org] .

use the w3c validation service. (0)

Anonymous Coward | more than 7 years ago | (#17986874)

validator.w3.org is your friend. if it validates, its good. just do that.

These seem fairly accurate (2, Informative)

jdcool88 (954991) | more than 7 years ago | (#17986914)

They are certainly not perfect, but it should give you some idea.

http://marketshare.hitslink.com/report.aspx?qprid= 0 [hitslink.com]

Re:These seem fairly accurate (2, Insightful)

Bogtha (906264) | more than 7 years ago | (#17988104)

How are you judging the accuracy of these statistics? I don't see any estimated error or confidence level. They don't describe their methodology. Are you doing what most people do and considering statistics "accurate" just because they reinforce your existing beliefs?

Is this just because it's easier? (0)

Anonymous Coward | more than 7 years ago | (#17986970)

Are you wanting to use IE-only functionality because it's easier to implement? The possible loss of revenue by not providing service to people who aren't on IE is probably enough of a reason to spend the extra development time. That's just one initial cost, and maybe some extra maintenance if it proves to be tricky to maintain, but it means you've openned yourself to what could amount to a large amount of revenue. Of course, it depends on your individual user bases particulars when it comes to Browsers.

I tend to use IE-only functionality only when it's for our Intranet. In that case, I know that every user is running IE, because that's the mandated standard for company computers. They can have FireFox, but they all have IE. And at that point, the extra development can result in a minimal amount of advantage, depending on the situation.

Google may not be the best choice (1)

jonbryce (703250) | more than 7 years ago | (#17986974)

as it is the default search engine for pretty much every browser except internet explorer. A lot of ie users do change their search engine settings to google, but many will stick with live.com or msn.

u-r rite! (1)

mookie da wookie (919403) | more than 7 years ago | (#17987020)

i maek websiets all da tiem and i jus use fruntpage and stuff. i lke making lots of activex objets and stuff. i have teh cool sites and u will 3 if u maek it so thah it works with ie only. i jus lerned how to use tables an spacer gifs to maek teh websites but i think i;; stik with ie thank u. its whta peoples use thees daes.

Am I missing something here.... (2, Insightful)

Anonymous Coward | more than 7 years ago | (#17987042)

Whatever happens to standards?
http://validator.w3.org/ [w3.org]

You can make anything you like available on a web server. If someone complains, and it follows the standards, then it's their fault. If it doesn't, then it's yours.

Re:Am I missing something here.... (1)

LighterShadeOfBlack (1011407) | more than 7 years ago | (#17987392)

Responding to the majority of your customers' complaints about your site not working with "aha! but your browser doesn't follow web standards" is a fast way to get rid of all your complaints. And all your customers. The "just use web standards and screw everyone else" viewpoint is not a practical one. Especially if we're talking about a business. Bottom line, most people use IE and most people don't give a damn about web standards, they just want things to work. You don't tell ~80% of your customers it's "their fault" they can't get to your webpage. Or at least you don't if you still intend to be in business a few months down the line.

Having said that, standards are obviously the way to go. As long as you don't do anything too radical IE will follow along for the most part, and generally speaking even when you do push it too far workaround can be made so that everyone can make use of the site even if they don't all get quite the same experience.

Re:Am I missing something here.... (0)

Anonymous Coward | more than 7 years ago | (#17987394)

Maybe you'd have a point if the w3 standards were reasonable, but they're not. For example the standard won't let you write a table-row generator in Javascript: the code has to sit outside a <table> or inside a <td> but not inside a <table>. Gratuitous limitation.

Re:Am I missing something here.... (1)

TheSunborn (68004) | more than 7 years ago | (#17988096)

Are you trying to use innerHTML to generate a table? (InnerHTML is afair not even w3c)

There should be no problem trying to do what you want, if you just use javascript to manipulate the DOM directly.

Standards compliance is cheap. (3, Informative)

SatanicPuppy (611928) | more than 7 years ago | (#17987084)

If you follow the standards your site will look good on most browsers, including IE.

On the other hand, if you jump on all the IE specific functionality you have a few issues. Will it work on old versions of ie? Will it work if people have their active X controls set to "high security"? Will IE break your sites functionality in a security upgrade?

Either way, you're writing off Mac's and all cellphones and pdas, you're writing off a lot of /.ers, and pretty much everyone who has a non-ie browser.

Now, I think Walmart gives as much of a shit about me as I do about them (if I were bleeding to death I'd drive 10 more miles to get some bandages rather than go to Walmart), so no loss for either one of us. But your company isn't Walmart, whose main customer base isn't remotely online.

If it were me, I'd stick with standards.

IE Upgrades (2, Informative)

Kelson (129150) | more than 7 years ago | (#17987188)

On the other hand, if you jump on all the IE specific functionality you have a few issues. Will it work on old versions of ie? Will it work if people have their active X controls set to "high security"? Will IE break your sites functionality in a security upgrade?

This is a good point. In case the submitter isn't aware, IE7 removed or disabled a lot of IE-specific functionality relied on by web apps. Functionality based on the standard specs, however, not only worked across IE6, Firefox, and others, but needed minimal adjustment -- if any at all -- to work in IE7.

In my own experience, most of the changes I needed to make with IE7 involved disabling workarounds for IE6-specific bugs.

Re:Standards compliance is cheap. (1)

hobo sapiens (893427) | more than 7 years ago | (#17987294)

Standards compliance is cheap
Says it all. I am so sick of the misconception "We are gonna do it on the cheap and make it IE only".

On the other hand, if you jump on all the IE specific functionality you have a few issues. Will it work on old versions of ie? Will it work if people have their active X controls set to "high security"? Will IE break your sites functionality in a security upgrade?
Yes I've seen it all. I have a team member whose coding skills are stuck in 1998 and he writes stuff (on the intranet) that uses all kinds of proprietary IE crap. Every time IE gets an upgrade, or my company implements some new security patch, he has to test everything. Yet he always ridicules others who write using standards claiming that "IE is the company standard browser!". What a fool. Some people never learn.

Re:Standards compliance is cheap. (1)

poopdeville (841677) | more than 7 years ago | (#17990340)

I have a team member whose coding skills are stuck in 1998 and he writes stuff (on the intranet) that uses all kinds of proprietary IE crap. Every time IE gets an upgrade, or my company implements some new security patch, he has to test everything. Yet he always ridicules others who write using standards claiming that "IE is the company standard browser!". What a fool. Some people never learn.

Sounds like he's getting paid not to.

Re:Standards compliance is cheap. (1)

quinnharris (450919) | more than 7 years ago | (#17990450)

I bought into the coolaid that "If you follow the standards your site will look good on most browsers, including IE."
It should read "If you follow standards your site will look good on most browsers, EXCEPT IE."

Being a Linux user I made the mistake of initially designed a site using Opera, Konqueror and Firefox following the w3c recommendations. The differences between how these browsers render are relatively minor and its usually easy to find a good common denominator. Then there is IE, especially 6 but 7 still isn't in the same league as those other browsers. I had to restructure my HTML to get it to work good enough in IE. I wanted a tabular layout for screen rendering for one part but I thought divs would be better markup. This isn't a problem in all modern browsers except IE. And IE 6 had this really weird bug where part of the page background would turn grey when you scrolled the page down then up again. I never seen something that pathological in the other browsers. I shuffled the markup around a bit and it went away.

If you need to support IE, you should test with it from day 1 (it will shape how you implement a site). If you need to support Opera, Konqueror and Safari you can test with just Firefox (following w3c recommendations) and fix the minor problems at the end.

And using a w3c validator is not enough to verify if a page will render right on all browsers. There are many little gotchas in CSS that can vary between browsers, especially with IE.

I personally prefer Firefox for development (firebug ...) and Konqueror for daily browsing.

check your own stats (0)

Anonymous Coward | more than 7 years ago | (#17987186)

check the stats of your current website and the percentages of bowsers being use. Be aware that some browsers have settings to look like another when online.

The important ones... (2, Insightful)

RealGrouchy (943109) | more than 7 years ago | (#17987194)

Perhaps 'only' 10-20% of your visitors will use non-IE browsers. However, perhaps only 5% of visitors to your website will purchase your product.

Do you want to gamble on which 5% that is?

- RG>

Count users, not hits. (1, Insightful)

Anonymous Coward | more than 7 years ago | (#17987214)

I manage all web services for my employer. Not surprisingly, there are many ways to count "browsers" - by hits, by IP, by "user sessions", by "known users", or something else.

I only count "browsers per known user per day". So users that come in more than once per day are only counted once; anonymous users (and robots/crawlers without a credit card in hand) are excluded.

This, not surprisingly, results in a number that's quite different than traditionally published "browser" numbers. The net result is that the browsers I must support are IE6, IE7, Firefox, and Safari.

But of course, being standards-compliant, it's easy for us to support any browser.

Your numbers will be different, because you're in a different industry with a different customer base.

Re:Count users, not hits. -- you can't (1)

Wilk4 (632760) | more than 7 years ago | (#17987408)

The parent post said: "I only count "browsers per known user per day". So users that come in more than once per day are only counted once; anonymous users (and robots/crawlers without a credit card in hand) are excluded."

And *how* do you count users/day accurately? With proxy servers, you *can't* always know that kind of information from server logs, though many logfile analyzer s/w packages will try to make you think you can...

See the Analog logfile analyser docs: What the results mean [analog.cx] , and particularly How the web works [analog.cx] .
"This section discusses what happens when somebody connects to your web site, and what you can and can't find out about them. If you think that you can get statistics on how many people have visited your web site (or want to know why you can't), then this section is for you."

Re:Count users, not hits. -- maybe you can (1)

Kelson (129150) | more than 7 years ago | (#17988058)

Judging by the GP's remark about "robots/crawlers without a credit card," I'm guessing it means they're counting "known users" who have logged into the site. In that case, you can track them pretty accurately, as long as you're willing to ignore traffic from people who have an account, but aren't logged in.

Re:Count users, not hits. -- maybe you can (1)

Wilk4 (632760) | more than 7 years ago | (#17989574)

hmm, perhaps that's what he meant. If so, that's useless for most sites of course.

As I mentioned, many logfile analyzers unfortunately mislead uers into thinking their "user" counts have any validity or mean anything, so he might think he really is counting users.

We always use fake IE headers in Firefox (3 units) (0)

Anonymous Coward | more than 7 years ago | (#17987256)

On all three of our computers at this office, (XP, OSX, Linux) we always use fake headers that look like IE just so that some sites will "let us in." Not all features work on "IE only" sites, but we end up blacklisting them from our office use and do not bookmark them for return visits.

Hope this helps. Lots of techies out there would agree that running an "IE only" website just hurts business.

Check your competitors (1)

PerfectSmurf (882935) | more than 7 years ago | (#17987312)

Do you have any competitors, or are there any companies offering reasonably similar services? Visit their support or forums or Google for complaints that they don't support particular browsers. Also install the various browsers and visit their site(s). Just like features, the more they support the more you probably should. Likewise, if they have big holes in browser support it means something... it could be that you could fill a void for potential clients...

A Modest Proposal (4, Funny)

Sloppy (14984) | more than 7 years ago | (#17987352)

If you're even willing to entertain the idea, then why not take it to the next level? Instead of having an interactive ActiveX-heavy website, just have a website that contains one file, a MS Windows-only executable, for your "audience" to download and execute as administrator. Then you won't have to worry about "giving up functionality" at all.

(BTW, you're never going to find the statistics that you want. Having MSIE be in the user-agent header, is practically part of the defacto http standard now. Why? Exactly because of the kind of abuse that you're contemplating. 10 years after the last copy of MSIE has been erased, it will still have 90% marketshare, at least according to the server logs.)

A Suggestion (2, Insightful)

webheaded (997188) | more than 7 years ago | (#17987434)

If you've already got some sort of website going, start logging statistics for it. Get a counter of some kind (like the kind at http://extremetracking.com/ [extremetracking.com] and you can look at who goes to your site. As you start to build the real meat and potatoes you will know what your primary audience. I look at these stats all the time for my websites to make sure that my site look good to the majority of my audience.

Engineering VS Development (2, Informative)

Vardyr (947047) | more than 7 years ago | (#17987540)

I'm not privy to what exactly "IE-only functionality" is in your case, but perhaps you should rethink your application design if you can't find a way to create a cross-platform solution. With AJAX, Java, and various other technologies with excellent cross-platform support, the only justifications for creating an IE-only site seem to be either DRM systems or laziness. Then again, we could also be dealing with the difference between a developer and an engineer. If you're hitting a point where IE-only functionality is appearing to be a good option, try rethinking what you need the application to do, and how it can do it, from the ground up. You'll probably find a much more future-proof and robust solution without sacrificing end-user functionality. You're right in stating that the audience is what matters, but platform lock-in also requires you to be absolutely certain that your audience doesn't change, the platform you're on won't drastically change, and that you can live with absolutely no assurance of future-proofing by avoiding standards.

Re:Engineering VS Development (1)

alphamugwump (918799) | more than 7 years ago | (#17990294)

AJAX is by no means cross platform. AJAX, for all intents and purposes, is a firefox platform. I can't count how often I get web2.0 sites that are broken with Konqueror, simply because they use firefox JS extensions. Hell, look at the poster child for AJAX, gmail. It doesn't use AJAX for IE, it uses activeX. For firefox, it uses JS. It is just broken with everything else.

Java and flash are better at this sort of thing, but they open up another bag of worms by requiring your users to download plugins.

Accurate usage? (1)

Sciros (986030) | more than 7 years ago | (#17987546)

Bowser is bottom-tier, so he doesn't really get used much. Luke (grabfestbowser) is pretty hardcore with him, as are a couple of other folks like Magnum, but for the most part he doesn't see much play.

Makes no sense (0)

Anonymous Coward | more than 7 years ago | (#17987584)

The question is not "Why code for non-IE" it's "Why not?" The fact of the matter is that if you use open standards (XHTML, XML, CSS, Javascript, XSLT, XPath, or something that will run 3rd-party in all browsers (Java, flash/shockwave *gag*) it will work not only in IE but in all other browsers simply because you are coding to standard. This seems like a no-brainer unless you're microsoft. Also keep in mind that if you code properly with CSS you don't even need to do much more than CSS-hacking in order to make your site work seamlessly with PDAs, phones, 508 (accessibility for people with disabilities), etc. If you can find something that is IE-only (in functionality, not in feature-name like ActiveX) then I'll be surprised but I don't think those things exist. Even ID is using the standard AJAX stuff now instead of their own proprietary one so the reasons to move to IE-only are really dumb.

E-mail harvestors make a mess of statistics (0)

Anonymous Coward | more than 7 years ago | (#17987736)

If you ever looked through web site logs, you could probably notice e-mail harvesters (and other junk robots). They identify themselves using a popular OS/browser combination (such as MSIE 6 Windows XP), but you can tell they are robots by their behavior (time between requests, systematic way of browsing links, etc.).

So, do the statistics have a reliable way of telling apart email harvesters? Do the statistics even try?

81% (5, Informative)

mshmgi (710435) | more than 7 years ago | (#17987738)

I manage dozens of websites reaching multiple demographics (i.e., business, home users, education, medical, engineering, agri-business, sporting goods). Our sites see roughly 1,000,000 unique visitors each week.

Removing bots out of the stats, on average, I see:

  • Windows IE: 81%
  • Windows FF: 11%
  • Windows NS: 0.1%
  • Windows OPERA: 0.1%
  • Linux (all browsers): 1%
  • Mac OS X (all broswers): 6%

If your site is geared towards highly technical people, expect to see double the FireFox & Linux traffic. If the site is geared towards the average home user, you might only be pissing off 10-12% of your potential customer base by having IE only components. I can't imagine many businesses surviving very long by pisssing off 1 out of every 9 customers ... oh, wait, Microsoft ... forget I said that.

Get some good analytics and tune accordingly (4, Informative)

Selanit (192811) | more than 7 years ago | (#17987740)

For a snapshot of the web population at large, check this site:

http://marketshare.hitslink.com/ [hitslink.com]

Their stats are updated regularly, they've got a reasonable level of detail, and lots of pretty graphs.

However, as others have pointed out, you need to be worrying about your particular audience more than anything else. A site like the one I've just given isn't all that useful unless you've got a really huge web site. So here's a three step plan for YOUR web site:

1) At first, design it to work smoothly with as many browsers as you possibly can.

2) Build up a profile on the types of users who visit your site. There are lots of programs that can help you do this. Google Analytics [google.com] does a decent job, and it's free of charge. Another one is Mint [haveamint.com] , which some people swear by [mikeindustries.com] (it costs $30 USD). There are lots of others out there, of varying quality and abilities. Take your pick.

3) Once you've got a profile built up, tune your web site to suit the abilities of the browsers that most of YOUR particular users favor. You might discover that only 0.002% of your visitors are using Safari, meaning perfect compatibility with Safari is not a major concern for you. Or you might discover that the Opera users of the world swarm your web site like ants swarm spilled sugar, in which case Opera becomes a priority for you.

Lather, rinse, repeat.

All the accuracy you'll ever need (0)

Anonymous Coward | more than 7 years ago | (#17987804)

If reading Accurate Browser statistics has taught me anything it's that Snape kills Dumbledor in Harry Potter. Enjoy Accuracy! I know I do.

Browser demographics (1)

chord.wav (599850) | more than 7 years ago | (#17987880)

Browser demographics are different from site to site. You should make your own statistics. I bet you that /.'s demographics will vary a lot from, say, amazon.com

One Data Point (4, Informative)

localman (111171) | more than 7 years ago | (#17987940)

Here's the percentages for the site I work on. I can't reveal specific numbers, but we get many millions of unique visitors per day. As many other posters have mentioned, the answer of what to support greatly depends on who your audience is and what you're trying to achieve. Our audience is over 99% from the US, and represents a more average (read: less tech savvy) cross section of internet users, specifically, those that would buy shoes and apparel online. Your potential customer profile is likely much different, but here's the top 10 browsers/platform combonations we saw last week:

44.93% - Internet Explorer 6.0 Windows XP
26.48% - Internet Explorer 7.0 Windows XP
5.26% - Firefox 2.0 Windows XP
4.90% - Firefox 1.5 Windows XP
3.98% - Internet Explorer 6.0 Windows 2000
2.29% - Safari 419 Macintosh PPC
1.82% - Safari 419 Macintosh Intel
1.39% - Internet Explorer 6.0 Windows 98
0.92% - Safari 312 Macintosh PPC
0.52% - Firefox 1.0 Windows XP

We do our best to support normal operation on all of these platforms (and several others) because at our volume alienating even a fraction of a percent costs real money. And also in our case it's not hard to make things work cross browser because we use simple HTML and minimal javascript.

You ask what you lose by adding some IE only features. The equally important question is what you gain. Are the IE only features you're considering going to increase the value of your application enough to make up for what is lost in potential users? Maybe it is, maybe it isn't. In general I think people overestimate how much fancy features are going to improve usefulness, so be honest with yourself there. Good luck figuring out where to draw the line.

Cheers.

Re:One Data Point (0)

Anonymous Coward | more than 7 years ago | (#17988328)

I guess this answers the "is linux ready for the desktop" question...

Re:One Data Point (1)

Johnny Mnemonic (176043) | more than 7 years ago | (#17989212)

No Mac FFox, or Mac IE? Hm.

Re:One Data Point (1)

localman (111171) | more than 7 years ago | (#17990380)

That was just the top 10. The whole list is very long :)

FYI, Mac Firefox 1.5 & 2.0 litter the teens under both PPC and Intel. All the prominent Mac Firefox entries combined pull about 1.8%. Mac IE really is dead, coming in at #44 with 0.05%.

The version splits make some things look smaller than they should. The analytics I'm using doesn't allow very fine grained control over improving that. What I'd like would be a way to group by work-alikes. But then that concept may not really hold anyways.

dont know how reliable this is but..... (0)

Anonymous Coward | more than 7 years ago | (#17988144)

but its got a cross-section of info on browser usage and related

http://www.thecounter.com/stats/ [thecounter.com]

Philosophy is more important than browser share (1)

carpeweb (949895) | more than 7 years ago | (#17988506)

Mod me off-topic if you must, but I think asking about browser share is definitely the wrong place to start. Start by asking why you want a web-based application, and you'll probably confront the fact that "universal client" was at least an important consideration at some point in the evolution (maybe back in the naive days before MS entered the browser market). For every feature you consider, before asking about browser share, think about whether the communication or functionality objective (user can get/do X) requires something so complex or sophisticated that it has to be embedded in a proprietary browser. The vast majority of features don't need the proprietary features, and of those that really, really need them, it might be worth developing multiple options, because "really, really need" usually means revenue$.

Basic common sense (1)

Baloo Ursidae (29355) | more than 7 years ago | (#17988860)

we got to thinking, exactly how many users would we be alienating by using some IE-only functionality on our website?

I know I might be playing Devil's Advocate here, but if users alienated >0, wouldn't common sense dictate that the move in question is a pretty bad one?

You'll have to find out for your self. (1)

Zadaz (950521) | more than 7 years ago | (#17989040)

As others have said, it's really up to those who visit your site.

If I was deploying a new web application I would start by writing it to standards and making it work with IE and FF out of the box. Then I'd keep track of what browsers hit my main page.

Then I'd make a simple business decision:

if (potentialLostRevenue > costToImplement)
          implement_browser(someBrowser)

Lets say it will take $1500 worth of manpower to implement Opera. If I'm potentially turning away $5K in business from Opera users, I'd implement it. If I'm potentially turning away $200, forget it.

Despite what others have said about Mac users being flush and careless with disposable income, I've found sell-through rates to be roughly the same (within 15%) between OS/browser.

Also, maintenance (2, Insightful)

Todd Knarr (15451) | more than 7 years ago | (#17989056)

Another thing to think about is future maintenance. Take a look at what IE7 did to IE-only Web sites. Lots of IE-specific things that worked find in IE6 suddenly didn't work or worked badly in IE7 because of changes in the browser. If you'd written an IE-specific Web site that actually used IE-specific features (as opposed to "we only tested it in IE" without using anything beyond bog-standard HTML/CSS/JS), you had headaches. Sites designed to work well in Mozilla, Opera and Safari, by contrast, made the IE6-to-IE7 transition with few if any problems.

So you not only have to ask whether it's worth it to accomodate non-IE browsers, you also have to ask if it's worth it to target only IE and deal with the havoc when Microsoft moves your target again (and they will move it, the only question is when and how far).

what do you need to know.... (1)

zogger (617870) | more than 7 years ago | (#17989248)

...besides the fact the millions of people DON'T use IE? Isn't "millions" a large enough number? Now I can see if it was mere thousands, but really, this is 2007, the numbers of people who use anything but IE grows daily and it is a nice fat large number. Yes, it is not as large as IE, but IE is no longer as large a dominating factor as it used to be either and that particular trend is just continuing. If you don't give a crap about those folks-your competition sure will. Ya, it's more work, so what? You potentially want every possible set of eyeballs to hit your site, why tell a section of them to go pound sand? All you will do is save a few bucks now being picky about if it is 10% or 11%, for the fantastic business opportunity of losing business in the future, and alienating potential customers/clients. It is beyond annoying to go to some website and be told you MUST be using such and such a browser, or "go to hell", because that is exactly what you are telling folks, just "go away, we don't like you, we think you are insignificant to us, because you fail to use the most insecure browser ever with features years behind everyone else".

That is not a good way to "win hearts and minds".

There's an old saying that fits, "penny wise, pound foolish". Would a gas station have a color code to get gas "sorry, we don't serve blue or green cars, only red cars".

Ya more work, suck it up. It'll pay off in the future for you.

Subjective Editorial Correction (1)

jshackney (99735) | more than 7 years ago | (#17990012)

'[we] don't make that kind of information available for free.'

My efforts to help out (1)

bgibby9 (614547) | more than 7 years ago | (#17990910)

I'm trying to build a complete set of tracking tools and reports for free for anyone to use. By doing this, I also hope to have a better way to output the stats of Browsers and OS'es. It's not perfect but it's growing! http://tracker.buildacomputeronline.com/ [buildacomputeronline.com] I'm going to continue to improve it, but if anyone has any suggestions, I'm all ears.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>