'Tech' is just too broad. If you're developing for KDE, then ignoring IE is very safe. If you're developing an addon for Visual Studio, then I'd probably not ignore IE.
For a generic 'tech' answer, I'd make sure the basic functionality works on IE, if ugly, and concentrate on Firefox and Chrome. (And if you do, Opera and Safari usually work without changes.)
In the same vein, this applies to demographics outside the 'Tech' world too. We build several products for a film festival market. Our support for IE is very product specific even within this niche domain and not something you would risk generalizing without testing the hypothesis out yourself.
For example, two of our products are (i) A film submission form field and (ii) A schedule for the screenings at the festival.
With basic IE support for both, we noticed <3% of the traffic using IE for the "Submission forms" and ~40% of our traffic to the "Schedules" use IE for a festival in Phoenix.
In hindsight this makes sense. Most people submitting films are the filmmakers or their crew- think Apple's primary target market, hence Safari and FF is what we see a lot of. We've stopped incremental updates for IE on the submission form as long as it remains functional.
However, people looking at schedules are at their enterprise jobs possibly in Phoenix during the day and trying to figure out what films to catch after work. That might explain the high prevalence of IE.
While it is obvious in hindsight, these are not assumptions I would be willing to make without looking at hard data specific to my product. Regardless of whether it's Tech or Filmmaker centric.
Within the last two weeks code was checked in to allow non-admin level installs, so when that debuts everyone that gets prompted can actually install it.
I can tell you this is also true for historious, Chrome is at 46%, Firefox 27%, Safari 20% and IE 3%. Opera is 1.8%, but that's probably all me :(
We can't really justify much effort (it's usually large, too) to accommodate 2% of users. Hell, until very recently, our bookmarklet didn't work with IE (some XSS security settings? We never figured it out), but now it eschews the nice overlay it uses for other browsers and just bookmarks stuff. It's ugly, but it works, if our users want a better experience we recommend switching to a better browser.
How do you know whether it was not supporting IE and a broken bookmarklet that caused your IE numbers to be so low? If I used IE and your service had a poor experience I'd probably use another bookmarking service.
edit: also, if the service is still new, you might largely be getting early adopters and not supporting IE could inhibit growth.
We do support IE now, so those numbers should start to stabilise, but still, the percentage is very low. It probably is early adopters we're getting, but I don't think there's a way for the bookmarklet to work with IE in the way it works with other browsers. I've tried disabling all security settings, but IE still won't allow JS access to the iframe.
I did a quick test with google's "Note In Reader" bookmarklet in IE8. The first time I clicked it I got an error about a pop-up being blocked. I clicked to allow the pop-up (which caused the page to refresh) and then it seems to have worked. It brought up a pop-up window which let me add a comment on the page I was on. It's definitely functional, but not ideal.
Hmm, I wonder how they did that. Maybe the popup has different permissions than the iframe, or maybe they pass the selected text. Unfortunately, their code is obfuscated, but thanks for the tip.
> We can't really justify much effort (it's usually large, too) to accommodate 2% of users.
I totally understand and agree with this sentiment. I do find it rather ironic, however, that developers today are using the same arguments for ignoring IE that were used for ignoring Firefox users 5+ years ago. Firefox users made a huge fuss about sites that were IE-only, and now many of those same users are returning the favor.
I can understand that, given that effort is finite. When Firefox users were enough to support, it made sense for apps to do so.
We're not trying to be mean, we'd love to support everyone, but when it comes to spending a day trying to find and fix an IE-only bug that affects 2% of your userbase (sure, it might be a bit higher if we didn't have the bug in the first place) or write a feature that will improve the service for 100% of the userbase, the latter takes priority...
My theory is that people browse Minecraft wiki / forum during work hours, in lieu of playing Minecraft, leading to a 13% share. Is there any way you could provide a browser by time of day graph that would support or refute my theory?
Sorry if I'm asking too much; it's really great when people post "private" statistics.
We did this for our app, quplo, which is still in public beta as we figure out payment (like these guys describe). Our app involves some complicated javascript for a syntax highlighted, code completion-supporting HTML editor. Common sense indicated it wouldn't be a good idea to invest lots of time making things work in IE when a) Analytics showed less than 2% IE visitors, b) our target audience is web designers and developers who by and large don't use IE as their preferred browser, and c) the app is an enclosed environment where it's okay to say "use these browsers for the app".
So what to take away from this? If you're a startup, you should be prioritising, not obsessing. And high on the list is making money, not making a marginal number of users happy, handling politics, or premature optimisation (eg. writing code that works across all browsers).
One thing we messed up on: not creating a kick-ass UX on Mac from day 1. We fixed it in the meantime, but we're developers using Windows, and a significant portion of our userbase is designers on Macs. So Safari, Firefox, Chrome and especially things like Mac font rendering and UI controls needed to be lickety-split.
I made the decision to go ahead and use tech IE doesn't yet support in my app. I'll see how it works out in the end but currently I have users all over the world and none of them complained about this. In fact to be able to use some of the features they have to install a webgl enable browser which hasn't been an issue for my users either.
My users are scientist and researchers, but not all of them are completely computer literate. I hand hold them a little bit with the setup.
It's a 3D visualization app for a neuroimaging dataset(can't say much more, should be public soon). We wanted to make that dataset available online to a lot of users and provide a good interface to use it. I started building it with O3D which provided a plugin for IE and really good performance but now that Google moved O3d to WebGL I followed. I'd love to support IE but that's not possible with the current tech and WebGL has served us well so I we won't abandon it just for IE.
That sounds really interesting. For a niche app like that, I guess you would need to run with the best technology available. Hopefully, your users will see the value and not mind switching browsers.
I think that even with something for a general audience, sometimes to choose between spending time trying to support everyone or spend the time building something really good for most people.
At least that how I see it.
Thanks for finding it interesting.I'd like to show this app around cause it's so much fun even with no knowledge of the science. A few things need to be resolved before the data set is completely open.
It depends on your target market. My start-up, http://www.MORExchange.com, targets mortgage borrowers. Real estate agents are an important referral channel.
We're currently in an invite-only beta. But among our few hundred users, we're definitely seeing a skew towards Firefox / Webkit and away from IE. That said, the combined versions of IE are still 40% of our traffic. And I'm fairly convinced that IE share will grow as our product enters open registration.
That said, we decided to abandon IE 6 support during development. Metrics so far indicate that this was the right decision. We're only seeing 2% of our requests coming from that abomination.
We're also not doing anything special for IE 7 & 8. They get the uglified version of the UI sans opacity, drop shadows, gradients, rounded corners, etc. I'm setting up analytics right now to see if browser version affects our conversion rate. I'm betting it doesn't.
Of course, we're not doing anything terribly unusual. We have no burning need for the canvas element, for example. So supporting IE 7 & 8 hasn't been terrible for us. I'd imagine that's a significant limitation for other start-ups.
We're also a traditionally funded company. So we have the luxury of being a bit more ambitious with our initial product. If we were bootstrapping and attempting to find customer fit, I'd probably just target the latest Firefox / Webkit.
I think if you use a modern javascript framework (i.e jQuery), and test regularly, it shouldn't be that difficult / time costly anymore to support IE7 and IE8.
In my experience jQuery abstracts away most of the incompatibilities.
It's mostly style that's the problem. IE8 is better but you don't get any niceties (rounded corners, etc). IE9 looks like it will be marginally better (eg, you now get rounded corners, but not much else).
Why is it that people should expect home pages to be the same pixel-for-pixel between different browsers? As long as the functionality is there, why do a few rounded corners matter?
Well, it's not only about style. IE9 adds rounded corners but still skips a lot of modern features in HTML5 that simply can't be used reliably by anyone due to IE not supporting them. IE is like a over-turned transport truck across 3 lanes of the highway to a better web. They cleaned up some of the spillage, but... well we're still not going anywhere :)
Styling is the most obvious issue, but it's just the surface of the problem.
My customers also remain committed to the "blue Googles."
There are blue Googles and green Googles. The blue Googles and green Googles can't talk to each other. This is why you need to use only your school website number to sign into BCC when you're on the blue Googles but you should use your AOL website number to sign in when you're on the green Googles.
Technical support in non-technical markets often involves very interesting forensic reconstruction of customer mental models.
Seriously though, "forensic reconstruction of customer mental models" sounds like a blog post I'd love reading, especially if it were an ongoing series.
A Google is an Internet. There are multiple, physically distinct Internets, because if one uses search as the only navigation, the blue Google (IE on work PC, hone page Bing) does not let you see all the sites on the green Google (home PC, home page google.com). This makes sense because clearly work made it so you could only pick the educational Googles.
There is a BCC site on both Googles, but because Googles are physically separate, they must be copies of each other, like how Word at home is a copy of Word at school. If you save docs in one, they don't show up at the other. So you need one login for the blue Google BCC and one for the green Google BCC. Duh. You use your website number as a login name. It is like a telephone number: it lets you contact people, except instead of ringing their phone your message shows up on their website.
A guess (until Patric comes back): the blue Googles is the internet explorer icon, which is used to start Google (really go Googles website). The green Googles is what ever the hell people use to sign into AOL with, they can't talk to each other because the computers are behind different nats.
I am hoping that the "website number" is not the http adresse, but the number they have to dial to connect to the internet (yes dial like it was 1995 and you could still go on a plane with a bottle of water) because it would be disturbing if the teachers called "www.bingocardcreater.com" a "website number".
I would guess "website number" does mean the web address. My 50 year old landlady gave me her "email number".
I'd also saw Patrick is talking about 2 different browsers on the same computer. "don't talk to each other" probably means they don't share cookies. If the user logs into one website with one browser, then the other browser doesn't become aware of each other. Clearly the 2 browsers don't talk to each other.
I'm reminded of statistics showing X website doesn't support mobile because only Y% of their traffic comes from mobile. Guess what? If the site doesn't work on a given browser, you're biasing you sample size. I think it was in Coupland's Microserfs that there was the story of corporate waiting until all the soda was gone to restock the fridge -- how can you know what people actually want if you articifically restrict their choices.
Now, the premise seems plausible, but you can't back up that premise with data that I know a priori is skewed to support that premise.
Some more anecdotal evidence, my company (not mine; http://getglue.com) actually originally launched solely as a Firefox extension (primarily distributed through Firefox AMO).
This actually played some role in my decision in taking the job- this was still in 2008, when ignoring IE was essentially almost never an option. Better, was that the extension views were developed in CSS- so I was free to explore CSS3 much earlier in live projects.
More timely, even as a website we still have very little focus on supporting IE users.
IE makes up for < 7% of our total visitors, and IE6 only 4% of that. More interestingly, a lot of our visitors now come through consumer markets like HBO and Fox. I think the numbers are surprisingly low for IE already; but considering our market is no longer a techie market (quite the opposite), the numbers are somewhat more interesting.
That all said, I think this speaks true to the title of the article. It's just a careful decision you need to make- but fortunately not one that is impossible to solve quickly, should you make the wrong one.
That's a ridiculous overgeneralization. You need metrics for your own site, you need to know the expectations of your users, you need to judge how much time and effort supporting IE will take for your app, etc.
I agree that your own stats are the best source, but not when you've only been public for less than a month and half your audience is coming from the likes of HN and Techcrunch.
As a blog directed towards programmers, I have to ask what your visitor browser breakdown is; I don't know why you'd think 40% is bogus for this type of audience.
If you mean my personal blog, Chrome is at ~15%, less than IE. It's only been up for 2 months though, so I wouldn't put much trust in my stats.
I think it's bogus because global Chrome usage is around 10%, according to the sources I linked to above. The fact that 40% of their visitors use Chrome now, does not mean that their potential future visitors will match that statistic.
Discounting a lot of future users that use IE based on one month's worth of analytics is madness.
It's not just a statistics problem, it's also a logic problem. I don't think it's in poor judgement to assume their audience, given their function and distribution channels, are largely Chrome and Firefox.
The key part of this post is that it is directed to startups. They're not suggesting they should dismiss IE users forever, but like many comments say it is about delegating resources properly where they matter.
When launching a new version of our website earlier this year we ran the numbers for the previous six months and found that 10% of our sales were not only IE, but IE 6. We're a small manufacturer that sells direct to customers and that 10% more than covered the extra time developing and testing for IE6. There was nothing sexy about the task, but none of use were willing to walk away from 10% of our sales.
If your product is futuristic and really needs stuff IE doesn't support (say, advanced HTML5 stuff) - OK. But if you're just doing it out of laziness then it's a bit silly. All the major CSS and JS frameworks pretty much eliminate the cost of supporting IE. These days the cost of supporting IE7/IE8 for me in a standard web site is fairly negligible. IE6 is another matter.
It all depends on your market. You can't ignore IE if your customers are on locked down, corporate workstations with guerrilla IT departments dictating IE only. Know your market, then decide accordingly.
I agree, but the author says they build for 'tech' companies and they want the product out the door fast. In that case, I would care less about IE when the market is around 2%. IMO you can gracefully decrease your support for IE when the traffic is below 10%. The amount of work you do to make your sites work of IE does not justify for the 10%. Just my opinion.
I haven't found supporting IE7/8 to be difficult at all. I suppose I'm quite conservative about using the new functionality supported in webkit or firefox, however.
The sample of visits is probably too small and misleading. Developers (e.g. you and guys on the team developing the product) tend to use FireFox and now, Chrome, whereas most users will use the stock browser they have by default - IE.
I am running a company in a similar sector (tech related util software), and IE visits are more than 60%. Not to mention, that most corporate users have as a rigid requirement and you are effectively killing a lot of revenue potential.
I run some fairly popular tech focused sites, I have IE running at 15% on the most popular, down to 3% on the least popular.
At the very least the advice is to take your audience into account, and if you are in this particular sector not supporting ie is a doable tradeoff.
if anyone gives an absolute statement that you should support ie, or you shouldnt support ie, unless they understand both the exact demographics you are targeting, and the internal structure of your company as well as the technical details of your product, they are wrong.
This is correct, demographics/industry specifics should be taken into account. What I was trying to say is that we also had something similar (IE stats very low)when we developed our product/service - when you are in Beta, your team and the early adopters are typically more tech savvy and do not use IE.
However, once you launch, IE visitors become the majority - at least in my particular case (in a sector that seems similar to what the blog post says). Even if the purchasing decision makers are not using IE, in my particular case many of the licensed users will be just corporate/normal job types, and IE is the majority there.
For a generic 'tech' answer, I'd make sure the basic functionality works on IE, if ugly, and concentrate on Firefox and Chrome. (And if you do, Opera and Safari usually work without changes.)