Bootstrapped startup saves over $100K by dropping IE(techcrunch.com)
techcrunch.com
Bootstrapped startup saves over $100K by dropping IE
http://techcrunch.com/2012/04/01/bootstrapped-startup-saves-over-100k-by-dropping-ie/
118 comments
Yes, the 100K is based on a back-of-the-envelope, but for a startup with zero revenue every development and design hour we can spare helps us focus on the real task at hand: figuring out our market fit and making a great product.
This is less about supporting this browser or that browser and more about making sound business decisions and putting our users’ needs first. We’d like to think they would rather see requested features over support for a browser they don’t use.
This is less about supporting this browser or that browser and more about making sound business decisions and putting our users’ needs first. We’d like to think they would rather see requested features over support for a browser they don’t use.
Honestly, it wouldn't surprise me if the value was higher.
[deleted]
From the guidelines:
You can make up a new title if you want, but if you put gratuitous editorial spin on it, the editors may rewrite it.
So no, HN is not strict about the title.
You can make up a new title if you want, but if you put gratuitous editorial spin on it, the editors may rewrite it.
So no, HN is not strict about the title.
"strict about the title submission matching"
Is this the case?
I thought the one of the explicit rules was to remove "Insert number ways/apps to increase productivity" and similar enumerations from titles. I also thought there was a general rule of thumb to remove hyperbole?
Is this the case?
I thought the one of the explicit rules was to remove "Insert number ways/apps to increase productivity" and similar enumerations from titles. I also thought there was a general rule of thumb to remove hyperbole?
Well there was the case of one of the original airbnb scandal submissions [1] having it's title changed from:
"AirBnB: Crimes committed against a host"
to:
"Violated: A traveler’s lost faith, a difficult lesson learned"
The rational at the time was that the change was done since the original title didn't match that of the linked blog post -- see pg's comment[2]. The counterargument being that the original title helped increase awareness of an important story that would have been harder to accomplish with the generic title.
[1]http://news.ycombinator.com/item?id=2811080
[2]http://news.ycombinator.com/item?id=2814681
"AirBnB: Crimes committed against a host"
to:
"Violated: A traveler’s lost faith, a difficult lesson learned"
The rational at the time was that the change was done since the original title didn't match that of the linked blog post -- see pg's comment[2]. The counterargument being that the original title helped increase awareness of an important story that would have been harder to accomplish with the generic title.
[1]http://news.ycombinator.com/item?id=2811080
[2]http://news.ycombinator.com/item?id=2814681
So then why do the guidelines say
You can make up a new title if you want, but if you put gratuitous editorial spin on it, the editors may rewrite it.
You can make up a new title if you want, but if you put gratuitous editorial spin on it, the editors may rewrite it.
"AirBnB: Crimes committed against a host"
Is spin.
It drives up links due to an emotional reaction. If your linking to a post called 'lost sheep' and you could change it to 'efficient distributed counting' because that's more descriptive and without spin. But, 'lost sheep (distributed counting)' is more in the spirit of HN IMO.
Is spin.
It drives up links due to an emotional reaction. If your linking to a post called 'lost sheep' and you could change it to 'efficient distributed counting' because that's more descriptive and without spin. But, 'lost sheep (distributed counting)' is more in the spirit of HN IMO.
Anyone know other sites that don't support IE?
I know codecademy doesn't support ie7 and ie8.
I know codecademy doesn't support ie7 and ie8.
Many of Google's products (Gmail, Google Calendar, Google Talk, Google Docs and Google Sites) don't support IE7.
http://www.computerworld.com/s/article/9217279/Google_to_dum...
http://www.computerworld.com/s/article/9217279/Google_to_dum...
Choosing not to develop for IE makes perfect sense if you're building an app. Here's my own little anecdote:
In the last 4 months or so I've written around 10k loc for a JS app. and probably 3x that many lines of combines CSS and HTML. Number of hours troubleshooting differences between Firefox and Chrome? I'd say about 8. So one developer day's worth of work to sort out some minor issues with vendor prefixed css. I've gotten to the point now that I routinely go days without testing in FF, and when I do fire it up.... everything just works.
My estimate that supporting ie6+ would have put my progress back by about 2 months. On top of that is the ongoing technical debt of continuing to support IE.
I don't want to say goodbye to potential IE customers and that's where Chromeframe comes into play. Chrome frame is AMAZING. Takes about 60s to install. Allows you to create your own install procedure i.e Your_Site -> Install_Chromeframe -> Your_Site. Doesn't require a browser restart and no admin rights needed. Wow.
Of course if you're just building a regular website then sure suck up the few hours it takes to make it work in IE and bill 2x for the trouble.
In the last 4 months or so I've written around 10k loc for a JS app. and probably 3x that many lines of combines CSS and HTML. Number of hours troubleshooting differences between Firefox and Chrome? I'd say about 8. So one developer day's worth of work to sort out some minor issues with vendor prefixed css. I've gotten to the point now that I routinely go days without testing in FF, and when I do fire it up.... everything just works.
My estimate that supporting ie6+ would have put my progress back by about 2 months. On top of that is the ongoing technical debt of continuing to support IE.
I don't want to say goodbye to potential IE customers and that's where Chromeframe comes into play. Chrome frame is AMAZING. Takes about 60s to install. Allows you to create your own install procedure i.e Your_Site -> Install_Chromeframe -> Your_Site. Doesn't require a browser restart and no admin rights needed. Wow.
Of course if you're just building a regular website then sure suck up the few hours it takes to make it work in IE and bill 2x for the trouble.
What is this? There was no real argument, no mentioned technologies, that were the ice-breaker.
Sure, in IE6, even the PNGs weren't working properly, but, talking layout, IE7+ is mostly a question of 5-10 additional rules (on small scale websites) and IE8 actually works without any (mostly), save for a css3 features like border-radius, etc.
As for the design, having less visual effects and no rounded corners doesn't have to be a problem – most of the designs work without it rather well (not to mention 4ormat's design doesn't use plasticity, gradients and shadows that much)
This article would gain much more credibility if it mentioned at least one or two technological obstacles that take you more than 30 minutes to sort out.
Sure, in IE6, even the PNGs weren't working properly, but, talking layout, IE7+ is mostly a question of 5-10 additional rules (on small scale websites) and IE8 actually works without any (mostly), save for a css3 features like border-radius, etc.
As for the design, having less visual effects and no rounded corners doesn't have to be a problem – most of the designs work without it rather well (not to mention 4ormat's design doesn't use plasticity, gradients and shadows that much)
This article would gain much more credibility if it mentioned at least one or two technological obstacles that take you more than 30 minutes to sort out.
My feelings exactly. I would also like to know what it is that Internet Explorer 9+ "doesn't support" that is apparently such a showstopper as to merit dropping support entirely.
I don't think anyone cares about the design. They're talking about JavaScript implementations, which differ between browsers.
Okay, then it's the javascript. But what javascript (running jQuery+UI) providing async script loading and few UI elements, can cost $100.000 to debug on IE8+, for instance?
I'm not saying there [on the 4ormat] isn't technical solution that could be this expensive to debug on IE, but none is visible on 4ormat page and nothing less obvious is mentioned in the article, thus diminishing article's credibility;
You know, instead of something awesome like 'we implemented geolocation, offline aps and 20-years-too-soon-UI, so we ditched IE', they are doing 'Hurr Durr bad IE can cost up to totally out of my ass pulled $100.000'.
I'm not saying there [on the 4ormat] isn't technical solution that could be this expensive to debug on IE, but none is visible on 4ormat page and nothing less obvious is mentioned in the article, thus diminishing article's credibility;
You know, instead of something awesome like 'we implemented geolocation, offline aps and 20-years-too-soon-UI, so we ditched IE', they are doing 'Hurr Durr bad IE can cost up to totally out of my ass pulled $100.000'.
I signed up to say this:
This is the lowest quality article I have ever read for a product which virtually no-one knows (except the minute techcrunch ecosystem and out of pocket VCs) trying to trash a product which is actually used at least 5 orders of magnitude more often by 5 orders of magnitude more people.
Trashing IE was fun once, but the world has grown up in the last couple of years.
Also, that's a theoretical 100k saved now until the Windows tablet market and Windows v.next peak grows (which it will as it always does) at which point it'll cost 200k to sort it out. I worked at a Microsoft monoculture org for a number of years and that's what happened when other browsers had to be supported (Firefox, Chrome, Safari). Save now, pay later.
Welcome to the 2012 version of an IE6 only web site...
This is the lowest quality article I have ever read for a product which virtually no-one knows (except the minute techcrunch ecosystem and out of pocket VCs) trying to trash a product which is actually used at least 5 orders of magnitude more often by 5 orders of magnitude more people.
Trashing IE was fun once, but the world has grown up in the last couple of years.
Also, that's a theoretical 100k saved now until the Windows tablet market and Windows v.next peak grows (which it will as it always does) at which point it'll cost 200k to sort it out. I worked at a Microsoft monoculture org for a number of years and that's what happened when other browsers had to be supported (Firefox, Chrome, Safari). Save now, pay later.
Welcome to the 2012 version of an IE6 only web site...
Developing for ie in the old days was usually at the expense of other browsers because of stuff like active x. There was no way to port that stuff to other browsers, which is why you had ie only websites. there will never come a time when writing standards compliant code becomes the problem your predicting. But the reality of today is that writing standards compliant code for ie is somewhere between difficult and impossible defending on what you're trying to accomplish.
IE is deserving of the trashing it receives.
IE is deserving of the trashing it receives.
"Developing for ie in the old days was usually at the expense of other browsers because of stuff like active x"
Errr... no. Active X was a tiny part of the problem. IE's problem was to support basically any quality of markup thrown at it, when other browsers couldn't. Then developers rely on this, which pushes their sites into IE-only zones. As time passes it gets progressively more difficult to extract a site out of this tar-pit.
It amuses me that the arguments for not supporting IE echo the same arguments IE-only advocates were using as a reason not to support other browsers a decade ago.
Errr... no. Active X was a tiny part of the problem. IE's problem was to support basically any quality of markup thrown at it, when other browsers couldn't. Then developers rely on this, which pushes their sites into IE-only zones. As time passes it gets progressively more difficult to extract a site out of this tar-pit.
It amuses me that the arguments for not supporting IE echo the same arguments IE-only advocates were using as a reason not to support other browsers a decade ago.
I said "stuff like active x". And I wouldn't say it's a tiny part of the problem. I still encounter clients (usually in government) who are forced to use IE6 because of some legacy webware they depend on which uses Active X.
No one is using the same arguments for not supporting IE. People are saying browsers should adhere to the standards, which is totally different.
No one is using the same arguments for not supporting IE. People are saying browsers should adhere to the standards, which is totally different.
Sorry, did you actually checked the website? Your argument regarding Windows tablet market seems really shallow. They already optimize it for iOS devices and Android which is like 90% of the market. I agree, the market is webkit all over, which sounds like a monoculture. But, there is no windows tablet yet and for design professionals ( which the website targets ) this is IMHO not the target. So, no early optimization.
I am not going to comment on "actually used at least 5 orders of magnitude more often by 5 orders of magnitude more people" because this seems to be disconnected from reality.
No early optimization, but no stupidity like having only vendor prefixed versions of CSS3 features that reached Candidate Recommendation and are already implemented unprefixed in major browsers, like border-radius which was mentioned in the comments to this article.
It isn't disconnected from reality. Consider China alone - IE is still king there as it is in the majority of large organisations (who still like to have control over their users with AD/Group Policy).
I'm not saying preemptively design for it, but if you preemptively exclude its predecessors and your path will be frought with many less turds to not step in i.e:
In 2 years: "Oh shit we did it all in Webkit and Gecko features - The growing 20% of Windows tablet market doesn't support it - we're going to have to rewrite or ship an app both of which are costly".
I'm not saying preemptively design for it, but if you preemptively exclude its predecessors and your path will be frought with many less turds to not step in i.e:
In 2 years: "Oh shit we did it all in Webkit and Gecko features - The growing 20% of Windows tablet market doesn't support it - we're going to have to rewrite or ship an app both of which are costly".
> "Oh shit we did it all in Webkit and Gecko features - The growing 20% of Windows tablet market doesn't support it - we're going to have to rewrite or ship an app both of which are costly".
If Windows tablets take off (and that still seems like rather a big if), you'd hope they have a vaguely compatible browser.
If Windows tablets take off (and that still seems like rather a big if), you'd hope they have a vaguely compatible browser.
Vaguely compatible doesn't help if the site is deliberately locking out browsers that look like the current crop of Internet Explorer browsers.
Doesn't look like that they are User-Agent sniffing, so that means that maybe they are detecting features. That's kinda the right way of doing it - except for their failure to adhere to progressive enhancement best practices.
But feature detection isn't "No Internet Explorer support here" approach. So the story seems at odds with the actual behaviour of their site.
Now what happens when an Internet Explorer - either on the desktop or tablet, or phone, passes the feature detection in place on this site? You don't get the "Go Away!" message, but instead you get an insufficiently tested experience which exposes the lack of attention on quality - that's something that's going to turn away an audience geared to wanting to see quality.
If you are going to publicly stop supporting an entire browser range, make sure your developers don't leave obvious gaps in that non-support. Maybe here's one place where User-Agent sniffing actually complements the actual requirement.
Doesn't look like that they are User-Agent sniffing, so that means that maybe they are detecting features. That's kinda the right way of doing it - except for their failure to adhere to progressive enhancement best practices.
But feature detection isn't "No Internet Explorer support here" approach. So the story seems at odds with the actual behaviour of their site.
Now what happens when an Internet Explorer - either on the desktop or tablet, or phone, passes the feature detection in place on this site? You don't get the "Go Away!" message, but instead you get an insufficiently tested experience which exposes the lack of attention on quality - that's something that's going to turn away an audience geared to wanting to see quality.
If you are going to publicly stop supporting an entire browser range, make sure your developers don't leave obvious gaps in that non-support. Maybe here's one place where User-Agent sniffing actually complements the actual requirement.
You are not far off. South Korea are stuck in this monoculture tar pit: http://blog.mozilla.com/gen/2007/02/27/the-cost-of-monocultu...
Webkit is just another form of monoculture.
Webkit is just another form of monoculture.
If your business/startup is still around in 2 years, you can probably afford a redesign for IE.
If IE10 is good enough it won't be hard as long as you don't depend on WebKit-specific stuff or WebGL, and this site does support Firefox.
> and Windows v.next peak grows (which it will as it always does)
What is v.next?
What is v.next?
version.next, ie. the next version of Windows.
Leaving aside the misleading title, i am not sure how the $100k number was arrived at. Developer hours? cutting off one dedicated developer who fixed IE issues?
If you are catering to creative professionals, who are going to be using huge apple monitors and macs (66% of the site's users are on a mac), ignoring IE isn't going to be a big deal. Even many of those ~4.5% of IE visitors might be on IE9 /10 which are pretty decent browsers. I am not here to support IE, i hate it like every other developer who builds stuff for the web. Also, compete.com tells their approximate UVs for February was around 13k. Ignoring a small number of users here is not going to have a huge impact. If your are site/app with millions of users, then it will be a big deal.
PS: If you are building a hipster social network or a video post processing tool, ignoring IE is going to save you significant time but if you are catering to e-commerce/finance or any other common demographic even thinking about ignoring IE isn't wise at this point.
If you are catering to creative professionals, who are going to be using huge apple monitors and macs (66% of the site's users are on a mac), ignoring IE isn't going to be a big deal. Even many of those ~4.5% of IE visitors might be on IE9 /10 which are pretty decent browsers. I am not here to support IE, i hate it like every other developer who builds stuff for the web. Also, compete.com tells their approximate UVs for February was around 13k. Ignoring a small number of users here is not going to have a huge impact. If your are site/app with millions of users, then it will be a big deal.
PS: If you are building a hipster social network or a video post processing tool, ignoring IE is going to save you significant time but if you are catering to e-commerce/finance or any other common demographic even thinking about ignoring IE isn't wise at this point.
These "developers" would have saved company X a fair bit of money by actually researching IE. Microsoft has graciously provided a massive amount of documentation covering most Internet Explorer variants and their quirks (via MSDN)[0].
One of the main problems in web development today is the creation of browser-specific code; "IE6" in particular is a scapegoat for poor code. I found that once I studied MSDN and wrote no browser-specific code that IE 8 became elementary to support. IE 7 soon followed. IE 6 & 5.5 were close behind.
For CSS, the key is understanding that every page does not need to look the same. Furthermore, reading MSDN's CSS compatibility grid[1] provides more insight.
For JavaScript, the key is simplification. Using DOM 0 events over fancy DOM 3 events yields big gains. Avoiding selector engines will also yield gains.
I'm getting very tired of incompetent web developers and their browser elitism. Do your homework.
[0]: http://msdn.microsoft.com/en-us/library/ms533050(v=vs.85).as...
[1]: http://msdn.microsoft.com/en-us/library/cc351024(v=vs.85).as...
One of the main problems in web development today is the creation of browser-specific code; "IE6" in particular is a scapegoat for poor code. I found that once I studied MSDN and wrote no browser-specific code that IE 8 became elementary to support. IE 7 soon followed. IE 6 & 5.5 were close behind.
For CSS, the key is understanding that every page does not need to look the same. Furthermore, reading MSDN's CSS compatibility grid[1] provides more insight.
For JavaScript, the key is simplification. Using DOM 0 events over fancy DOM 3 events yields big gains. Avoiding selector engines will also yield gains.
I'm getting very tired of incompetent web developers and their browser elitism. Do your homework.
[0]: http://msdn.microsoft.com/en-us/library/ms533050(v=vs.85).as...
[1]: http://msdn.microsoft.com/en-us/library/cc351024(v=vs.85).as...
Its not browser elitism when you have 4 browsers that work and 1 that doesn't. If you are doing trivial ui work, it is not hard to support IE. If you are doing anything close to innovative or competitive with what is out there, it is a huge pain.
s/browsers/platforms/. Don't lump all browser versions into one pile.
I can grasp what you're referring to. Bleeding-edge features are tough to support in large part because of Internet Explorer's slow release cycle.
However, the decision has still been made to jump onto a runaway train. All users should be treated the same. Choose an approach that doesn't pick favorites.
I can grasp what you're referring to. Bleeding-edge features are tough to support in large part because of Internet Explorer's slow release cycle.
However, the decision has still been made to jump onto a runaway train. All users should be treated the same. Choose an approach that doesn't pick favorites.
"Graciously", when IE browsers are the odd ones out, the most non-standards-compliant ones? I'd kind of take it as a given, and it still wouldn't remove the strikes against older version of IE.
BTW, when you refer to code that isn't "browser-specific", do you mean compliant to web standards? Or to the minimum working set between all browsers? Aren't most of the IE hacks people use "browser-specific" to IE?
BTW, when you refer to code that isn't "browser-specific", do you mean compliant to web standards? Or to the minimum working set between all browsers? Aren't most of the IE hacks people use "browser-specific" to IE?
The problem here is you're simply comparing applies to oranges. Internet Explorer 6 was released in 2001. For its time, it was a very nice product. IE 7 may have faltered a bit, but IE 8 was strong. Of course IE versions 6-8 are going to smell like manure vis à vis Chrome 27; a decade's elapsed. A proper comparable for IE 6 would be Opera 6.
Regarding your aside, I'm referring specifically to a generalized approach based on observations and not assumptions. I don't consider something trivial such as `event || window.event` browser-specific; it's a strategy used in accordance with multiple event models. You might be surprised to know that Microsoft created the blueprint for the DOM 3 event model (via attachEvent, etc.). They also were the first to use `innerHTML`, `innerText` and `Element.children`.
Regarding your aside, I'm referring specifically to a generalized approach based on observations and not assumptions. I don't consider something trivial such as `event || window.event` browser-specific; it's a strategy used in accordance with multiple event models. You might be surprised to know that Microsoft created the blueprint for the DOM 3 event model (via attachEvent, etc.). They also were the first to use `innerHTML`, `innerText` and `Element.children`.
I think the argument of what browser(s) you do/don't support really depend upon your site's focus.
I'm pretty sure if Gruber/daringfireball.net dropped all IE support, his traffic decline would be close to 0.
On the other hand, if codeguru.com did the same, their traffic would probably drop off close to 75+%.
If your budget is tight or skills limited, focus on your target market first and make that experience the best you can. Though, that pretty much applies for browser support as well as many other things.
I'm pretty sure if Gruber/daringfireball.net dropped all IE support, his traffic decline would be close to 0.
On the other hand, if codeguru.com did the same, their traffic would probably drop off close to 75+%.
If your budget is tight or skills limited, focus on your target market first and make that experience the best you can. Though, that pretty much applies for browser support as well as many other things.
Absolutely. I work for a 'start-up' in the insurance sector, where everyone uses IE (the only non-IE entries in the access logs are myself on the development sites). If we ignored IE (and I'd love to, given the number of headaches over the years) we wouldn't have any customers.
We could get away with not supporting Chrome and Firefox though as I doubt anyone would notice.
We could get away with not supporting Chrome and Firefox though as I doubt anyone would notice.
> Recruitment secret weapon. It warms our hearts to see the look of incredulous joy on the face of a job candidate when we assure them “You heard right, we really don’t support IE.”
I can imagine that look so well...
I can imagine that look so well...
I know that look myself. But most experienced web coders know how to whip IE into submission, so I'm very skeptical about the 30-100% figure. (I usually guesstimate it at around 20% for a normal website.)
65% of their traffic is from Mac users, so this sounds like a good decision given their audience.
65% of their traffic is from Mac users, so this sounds like a good decision given their audience.
Nah ... that's about right, I've been doing html/css for almost 9 years and hard core javascript/ui stuff for another 4 or so.
Almost without fail, fixing stuff for IE takes as long as it does to just build the feature in the first place (so 4 hours to do a layout then another 3 or 4 to get it working properly in IE), with CSS/html layout that number has dropped as IE6 has been phased out, but I find that its actually moved over into doing js stuff in IE8 and 7.
Almost without fail, fixing stuff for IE takes as long as it does to just build the feature in the first place (so 4 hours to do a layout then another 3 or 4 to get it working properly in IE), with CSS/html layout that number has dropped as IE6 has been phased out, but I find that its actually moved over into doing js stuff in IE8 and 7.
The solution may be to design your site and test in Internet Explorer before even looking at it in any other browser. It might be faster for you to resolve the quirks in FireFox & Chrome then IE. Reversing your process might speed up your development time by 20%.
No, that introduces the same type of bias, just from the opposite direction. The key is to keep a broad range of browsers quickly on hand to regularly check _while_ you develop.
There's no reason not to have multiple browsers quickly available - modern computers have sufficient processing power to run multiple applications simultaneously these days.
There's no reason not to have multiple browsers quickly available - modern computers have sufficient processing power to run multiple applications simultaneously these days.
how do you fix ie7 and 8 css issues? Do you use hacks?
That's what I have been doing but would like to get away from this as some employers frown on it.
That's what I have been doing but would like to get away from this as some employers frown on it.
Can't you surround your CSS includes with conditional comments to load ie-specific stylesheets? I'm not a web-designer by any stretch, but I thought that was the usual way to work around IE-specific quirks.
UNfortunately that still takes time and possibly more time then using css hacks, which are quick and dirty.
I saved many $100K by not porting our civil engineering and mine planning apps to Mac
It all depends on your market!
It all depends on your market!
Yup. I worked a web marketing/branding firm as a web developer for a while last year and we started telling our clients that any IE support would cost 25-40% more.
If they had an existing web presence we'd get their logs and figure out about how much traffic they'd lose by dropping IE. Few were willing to pay for it.
(And I was happy to cut my headaches down by an order of magnitude)
If they had an existing web presence we'd get their logs and figure out about how much traffic they'd lose by dropping IE. Few were willing to pay for it.
(And I was happy to cut my headaches down by an order of magnitude)
There seems to be a common sentiment that experienced devs can tame IE, thus it's not really an issue.
Speaking as someone who can tame IE, I can categorically state that I don't want to. I'd much rather have that time back so I could do something much more fun.
Speaking as someone who can tame IE, I can categorically state that I don't want to. I'd much rather have that time back so I could do something much more fun.
"not a single person has ever contacted us requesting support for Internet Explorer."
While that may be considered evidence of potential customers switching browsers just to use 4ormat.com, it may also be considered evidence that potential customers using IE are very much put off by being told to use another browser.
Just running the numbers on a back of envelop:
The company was founded in 2008.
Not supporting IE has saved $25,000 per year.
12 months x $7 per month = $84 per user.
330 lost users = $25,000 +/- per year
10,000 responses to the call for action * 4% using I.E. = 400 visitors who are much more unlikely to use 4ormat.com because the call to action doesn't work. Their negative experience is much more likely to lead to negative network effects than positive ones.
Even worse the lost revenue scales as the customer base grows, but the work to support IE is roughly fixed and is relatively modest.
$25,000 is 4% of $625,000 a year. Above that, the company is losing money (on the back of an envelop). With four founders, one would expect that 4ormat.com's revenue is projected to exceed that or has already.
While that may be considered evidence of potential customers switching browsers just to use 4ormat.com, it may also be considered evidence that potential customers using IE are very much put off by being told to use another browser.
Just running the numbers on a back of envelop:
The company was founded in 2008.
Not supporting IE has saved $25,000 per year.
12 months x $7 per month = $84 per user.
330 lost users = $25,000 +/- per year
10,000 responses to the call for action * 4% using I.E. = 400 visitors who are much more unlikely to use 4ormat.com because the call to action doesn't work. Their negative experience is much more likely to lead to negative network effects than positive ones.
Even worse the lost revenue scales as the customer base grows, but the work to support IE is roughly fixed and is relatively modest.
$25,000 is 4% of $625,000 a year. Above that, the company is losing money (on the back of an envelop). With four founders, one would expect that 4ormat.com's revenue is projected to exceed that or has already.
Supporting IE means taking on board a technical debt that will follow you for the life of the project. There are lots of things that can be accomplished in ie6 but then you need to consider performance. If you're building an app that means a lot of JS and possibly DOM manipulation... which is dog slow in ie.6,7,8
Now factor in support costs. I can picture it now:
Customer: Uhhh your app sucks it's so slow.
Support: Hmm looks like you're using IE6. We've worked really hard to make our app function in every browser, however if you'd like the best possible experience then please upgrade.
Customer: What's a browser?
The best solution is to use chrome frame. The installation can be made seamless and if your app is worth using then your customers wont mind the extra 60s it takes to install.
Now factor in support costs. I can picture it now:
Customer: Uhhh your app sucks it's so slow.
Support: Hmm looks like you're using IE6. We've worked really hard to make our app function in every browser, however if you'd like the best possible experience then please upgrade.
Customer: What's a browser?
The best solution is to use chrome frame. The installation can be made seamless and if your app is worth using then your customers wont mind the extra 60s it takes to install.
Leaving aside the appropriateness of lumping IE6 with IE8 and 9, the support costs are already in the $100,000 number.
Slow speed of execution in IE might well be considered a vast improvement compared to the current state of affairs in regard to the potential customer's standpoint - i.e. IE not working at all.
Again, "change your browser" is a poor way to convince the customer that 4ormat.com is worth using given that the customer has already responded to the call to action.
Indeed, one might argue that there's no excuse for failing to inform the potential customer that IE is not supported before the call to action is clicked - obviously 4ormat.com is capable of testing for browser versions.
Slow speed of execution in IE might well be considered a vast improvement compared to the current state of affairs in regard to the potential customer's standpoint - i.e. IE not working at all.
Again, "change your browser" is a poor way to convince the customer that 4ormat.com is worth using given that the customer has already responded to the call to action.
Indeed, one might argue that there's no excuse for failing to inform the potential customer that IE is not supported before the call to action is clicked - obviously 4ormat.com is capable of testing for browser versions.
Seems win-win to simply use chromeframe. Given this is a web app which presumably customers are already invested in using (since they're paying for it), requiring a 60s one-time install seems like the best course of action for everyone involved.
Slow speed of execution in IE might well be considered a vast improvement compared to the current state of affairs
Unfortunately the general public doesn't think like that. To the average Joe your site is slow therefore it sucks.
Slow speed of execution in IE might well be considered a vast improvement compared to the current state of affairs
Unfortunately the general public doesn't think like that. To the average Joe your site is slow therefore it sucks.
I dislike developing for IE as much as the next guy, but does selectively supporting browsers, even when reasonable IE versions exist, bring us back to the "best viewed in Internet Explorer" days? Is this a step back for web standards?
I'd say that anything that convinces IE users to switch is a step forward.
It sure does. Developers seem content to keep moving the goalposts and treating "inferior" users as slime.
You seem to be taking this rather personally.
In a way yes but there's a big difference this time around. You can easily get most code including bleeding edge stuff working in Chrome, Firefox, Safari, and Opera. Not IE though despite the major improvements in IE9. I'm all for ignoring IE just so that maybe Microsoft will catch it up with everyone else. That means getting CSS working nicely in it as well as adopting a faster release cycle and actually encouraging people to upgrade and stop breaking IE every time a new version of Windows comes out.
Not always. I this year spent several hours chasing down a discrepancy between Firefox and WebKit (Safari/Chrome) and I've even seen cases where Safari and Chrome are slightly different.
Honestly, I drop support for IE <=8 for most of my sites. IE9 is pretty good and aside from a few glitches and IE specific stuff (usually 1 small hack around per problem). IE doesn't pose as much of a problem as, say, Android browser or Mobile Safari which will do things like ignore overflow:auto.
I can't imagine supporting IE 9+ would take that much money. But then again, I don't run a startup.
I can't imagine supporting IE 9+ would take that much money. But then again, I don't run a startup.
IE8 is pretty good and aside from a few glitches and IE specific stuff
IE7 is pretty good and aside from a few glitches and IE specific stuff
IE6 is pretty good and aside from a few glitches and IE specific stuff
Isn't that the point
IE7 is pretty good and aside from a few glitches and IE specific stuff
IE6 is pretty good and aside from a few glitches and IE specific stuff
Isn't that the point
...No, not really. The extra development work required to support IE9 on top of other browsers is vastly smaller than that for IE6.
It's a cost-benefit analysis. Messing about with words by stretching the what you can reasonably describe as "few glitches and IE specific stuff" to try and draw a false equivalence doesn't change the actual analysis.
It's a cost-benefit analysis. Messing about with words by stretching the what you can reasonably describe as "few glitches and IE specific stuff" to try and draw a false equivalence doesn't change the actual analysis.
IE10 looks like it will be the first version to not take much work. 9 is not as glaring as 7 or 8, but it is definitely the lowest common denominator.
For a browser that was supposed to be very standards compliant I'm always very surprised by how often a design that looks great in Firefox, Chrome and Safari bails in IE9.
This. IE8 still has the largest market share among IE versions, with IE9 growing [1].
IE8 is way too painful. IE9 is starting to go from "huge pain" to just within the realm of possibility.
IE10 is a different story. Maybe.
[1] http://arstechnica.com/business/news/2012/03/browsing-behavi... - as of Feb 2012, IE8 had ~25% and IE9 had ~15%, source: Net Market Share
IE8 is way too painful. IE9 is starting to go from "huge pain" to just within the realm of possibility.
IE10 is a different story. Maybe.
[1] http://arstechnica.com/business/news/2012/03/browsing-behavi... - as of Feb 2012, IE8 had ~25% and IE9 had ~15%, source: Net Market Share
You know, I think Microsoft may actually be getting their shit together (gasp). IE9 definitely isn't a bad browser, and 10 better than 9. I think they might be learning finally that they can't get away with putting out supbar products anymore, because its too easy to switch now. Granted, I think doing things differently is in Microsoft's DNA, but IE9, as well as starting forced upgrades, shows that they might actually be competitive at some point...
Honestly, they have been getting their shit together since 7, they were just so far behind that it has taken this long to have enough impact that devs don't want to stab their eyes out rather then support it. IMO they should have either switched to webkit (or at least forked it and started again from a better place) years ago
Given that tHN is full of developers, I'm pretty disapointed that so many ppl are lumping all the IE's together as a single product.
I totally see that IE6 & 7 are not worth the dev effort, IE8 is probably border-line, but IE9 is a good browser and people seem to be vastly exagerating how much work goes into getting IE9 to look and work like other browsers (i.e. not very much).
So not supporting IE9 seems a bit lazy to me, and I have to say, a little "religous" (they seemed to have ruled out IE10 already without doing any research into why). Also find it strange that they actively block it rather than just warn people about it being unsupported.
However, I will cut them slack because the target market are creatives, and it's an admin site rather than a consumer level site, so probably few IE users here. But others here seem to be extending this idea to the public web, which seems like a mistake...
I totally see that IE6 & 7 are not worth the dev effort, IE8 is probably border-line, but IE9 is a good browser and people seem to be vastly exagerating how much work goes into getting IE9 to look and work like other browsers (i.e. not very much).
So not supporting IE9 seems a bit lazy to me, and I have to say, a little "religous" (they seemed to have ruled out IE10 already without doing any research into why). Also find it strange that they actively block it rather than just warn people about it being unsupported.
However, I will cut them slack because the target market are creatives, and it's an admin site rather than a consumer level site, so probably few IE users here. But others here seem to be extending this idea to the public web, which seems like a mistake...
Sure, you couldn't get away with this on an ecommerce site such as for a bank or store. But I bet you could for many things such as games or social sites.
People know there's something uncool about IE, even if they don't know why. And it can be replaced in 5 minutes.
People know there's something uncool about IE, even if they don't know why. And it can be replaced in 5 minutes.
I can sympathise with this. We only support Firefox for our CMS editing interface, and then, only test in the latest version.
This is a somewhat more extreme version of the OPs decision but we also started work on Decal when the only browser with a JavaScript debugger was Firefox[1].
The interesting thing is we've deploying Decal ourselves for quite a while and only now just starting to try and open it up as a platform for other designers.
We have never had a client object to having to use Firefox to manage their content, however in running people through our "Decal 4 minute challenge"[2] we've found a huge amount of resistance amongst designers themselves.
This leaves us in a tricky predicament: we want designers to sell the system to their clients who, in our experience, don't care about using Firefox to manage their content, but in order to engage/on-board those designers in the first place we have to get past that initial hurdle (as it turns out, 4 minutes is way too long and we're refining that on-boarding process down to a target of about 30 seconds).
[1] http://www.decalcms.com/page/Support/#whyFirefox
[2] http://www.decalcms.com/page/4_minute_challenge
This is a somewhat more extreme version of the OPs decision but we also started work on Decal when the only browser with a JavaScript debugger was Firefox[1].
The interesting thing is we've deploying Decal ourselves for quite a while and only now just starting to try and open it up as a platform for other designers.
We have never had a client object to having to use Firefox to manage their content, however in running people through our "Decal 4 minute challenge"[2] we've found a huge amount of resistance amongst designers themselves.
This leaves us in a tricky predicament: we want designers to sell the system to their clients who, in our experience, don't care about using Firefox to manage their content, but in order to engage/on-board those designers in the first place we have to get past that initial hurdle (as it turns out, 4 minutes is way too long and we're refining that on-boarding process down to a target of about 30 seconds).
[1] http://www.decalcms.com/page/Support/#whyFirefox
[2] http://www.decalcms.com/page/4_minute_challenge
Not a big deal these days.. most things behave the same in IE8/IE9 as they do in Chome, Firefox and Safari. It's only IE7 that's a headache and that's <1% of traffic for most techie-oriented sites. If they were doing this 5 years, it'll be worthy of a headline...
>> most things behave the same in IE8/IE9 as they do in Chome, Firefox and Safari
Having recently developed an HTML5 single page web app, I can assure you that this statement is utterly false.
Having recently developed an HTML5 single page web app, I can assure you that this statement is utterly false.
[deleted]
I've been getting back into the open web after spending a few years doing mostly Flash stuff. It blows my mind how little debugging web development requires nowadays. You can write an app in Chrome, and it works equally well in Firefox and IE9 without any added effort on your part.
IE8/9 are certainly much better but they still have a long way to go. Gradients are a pain in 9 and rounded corners behave in unpredictable ways in both 8 and 9. Font rendering in all versions of IE including the latest and greatest sucks too.
In general, though we do have to spend time tweaking things between Chrome, Firefox, and Safari, IE8 and 9 still account for a significant portion of time spent getting things to work cross browser. For me, that time is so significant that I too completely ignore IE unless someone specifically asks for support.
Point is, IE, even in its latest form, is still not at the same level as the competition. I'm aware of all the reasons why I shouldn't ignore it but I do so in protest, not laziness and I hope one day a significant portion of the design community gets on board with it. If the web breaks for IE users maybe then Microsoft will make it behave sanely and try to get people to upgrade. Though I must say that the one thing I applaud IE for is it's box model. It is far more intuitive than the official spec.
In general, though we do have to spend time tweaking things between Chrome, Firefox, and Safari, IE8 and 9 still account for a significant portion of time spent getting things to work cross browser. For me, that time is so significant that I too completely ignore IE unless someone specifically asks for support.
Point is, IE, even in its latest form, is still not at the same level as the competition. I'm aware of all the reasons why I shouldn't ignore it but I do so in protest, not laziness and I hope one day a significant portion of the design community gets on board with it. If the web breaks for IE users maybe then Microsoft will make it behave sanely and try to get people to upgrade. Though I must say that the one thing I applaud IE for is it's box model. It is far more intuitive than the official spec.
IE9 works fine with one caveat:
Live with the features that work properly. Don't jump on every new bandwagon like gradients and then go ape shit when it doesn't work.
To be honest, it's not like all that shit really improves a product if it does something useful already. TBH IE6 can shift out a product that improves lives and earns money fine without being a pain in the arse if you accept its feature set.
Live with the features that work properly. Don't jump on every new bandwagon like gradients and then go ape shit when it doesn't work.
To be honest, it's not like all that shit really improves a product if it does something useful already. TBH IE6 can shift out a product that improves lives and earns money fine without being a pain in the arse if you accept its feature set.
This isn't about bandwagons. It's about IE behaving so unpredictably and vastly different than all other browsers on the market. It's like IE never got the news that the browser wars are over and continues to implement the CSS spec whatever way it wants at times.
We already live with the features that work properly but why can't we criticize features that dont work properly? When a spec changes we can't expect old versions of browsers to support it, that's fine. But when a spec changes and a new version of a browser comes out claiming to support it but really doesn't then we have every right to criticize it.
When IE9 came out Microsoft raved about how advanced it was and how we would get to play with all the new css3 features, etc. but that wasn't true. It was a big leap forward from version 8 but still not up to snuff compared to other browsers.
We certainly can create products that are incredibly useful even in older browsers but it's ludicrous to say we should just live with the limited feature set of IE. we're talking about the web here. A place where technology moves so fast that paradigms shift in a matter of months, not years. When every other browser on the market has been reliably supporting X features for several years now but one holdout still doesn't implement it like any of the others at all I'd say we have the right to criticize it.
Your tone makes me out to be like someone who just discovered web design and is using it like people used to use the blink tag in the 90's. That's not the case. This isn't about bandwagons nor is about the CSS3 features I mentioned. I only used those because they came to mind first. I'm very aware of design elements that are overused and those that need to be used with caution. You need to remember that functionality is only a piece of the puzzle. Backend design and front end design both play critical roles in making the user happy. Good design is about surprise and delight and since most browsers support it, we should be able to use parts of the new CSS spec now but IE is still holding us back as it always has. There are good reasons to use these features and not all people who use rounded corners and gradients are using them gratuitously like you imply.
Here are my reasons for wanting to use them: I want to cut down on the use of images for design (I can literally cut 90% of my image use by using css3). I want to speed up page load times. Stop depending on JavaScript as much (related to load times too). Finally, I just want to surprise and delight my users. Give them a beautiful experience. What I build may do its job but if its interface is boring and a chore to use then I messed up my job.
So should we all just "support the working features" of the lowest common denominator despite the fact that there's a ton of great features that are widely supported elsewhere already? Please don't be a design snob and look down your nose and assume anyone using css3 is jumping on some bandwagon lest you miss the point entirely.
We already live with the features that work properly but why can't we criticize features that dont work properly? When a spec changes we can't expect old versions of browsers to support it, that's fine. But when a spec changes and a new version of a browser comes out claiming to support it but really doesn't then we have every right to criticize it.
When IE9 came out Microsoft raved about how advanced it was and how we would get to play with all the new css3 features, etc. but that wasn't true. It was a big leap forward from version 8 but still not up to snuff compared to other browsers.
We certainly can create products that are incredibly useful even in older browsers but it's ludicrous to say we should just live with the limited feature set of IE. we're talking about the web here. A place where technology moves so fast that paradigms shift in a matter of months, not years. When every other browser on the market has been reliably supporting X features for several years now but one holdout still doesn't implement it like any of the others at all I'd say we have the right to criticize it.
Your tone makes me out to be like someone who just discovered web design and is using it like people used to use the blink tag in the 90's. That's not the case. This isn't about bandwagons nor is about the CSS3 features I mentioned. I only used those because they came to mind first. I'm very aware of design elements that are overused and those that need to be used with caution. You need to remember that functionality is only a piece of the puzzle. Backend design and front end design both play critical roles in making the user happy. Good design is about surprise and delight and since most browsers support it, we should be able to use parts of the new CSS spec now but IE is still holding us back as it always has. There are good reasons to use these features and not all people who use rounded corners and gradients are using them gratuitously like you imply.
Here are my reasons for wanting to use them: I want to cut down on the use of images for design (I can literally cut 90% of my image use by using css3). I want to speed up page load times. Stop depending on JavaScript as much (related to load times too). Finally, I just want to surprise and delight my users. Give them a beautiful experience. What I build may do its job but if its interface is boring and a chore to use then I messed up my job.
So should we all just "support the working features" of the lowest common denominator despite the fact that there's a ton of great features that are widely supported elsewhere already? Please don't be a design snob and look down your nose and assume anyone using css3 is jumping on some bandwagon lest you miss the point entirely.
> So should we all just "support the working features" of the lowest common denominator
As the parent and a a person with 16 years (yes that many years!) of experience managing and putting together well known corporate web sites and web apps, I'd say that yes you should.
The web is about being open to everyone regardless of the technical limitations.
As the parent and a a person with 16 years (yes that many years!) of experience managing and putting together well known corporate web sites and web apps, I'd say that yes you should.
The web is about being open to everyone regardless of the technical limitations.
I'm confused as to how being a parent is particularly relevant, but anyway...
This particular application is aimed at a narrow category of professionals, none of whom are likely to be using IE, or at least tied to using it. It would thus seem like a bit of a waste of effort to support it, given that it's more troublesome to support than WebKit and Gecko, and also given that Microsoft has promised that IE's standards support will improve, so it'll probably just work on IE10 anyway.
This particular application is aimed at a narrow category of professionals, none of whom are likely to be using IE, or at least tied to using it. It would thus seem like a bit of a waste of effort to support it, given that it's more troublesome to support than WebKit and Gecko, and also given that Microsoft has promised that IE's standards support will improve, so it'll probably just work on IE10 anyway.
Parent poster...
Wait, what does it matter that they were bootstrapped? The title could just as well be "startup that took investments and venture capital saved boatloads of money ...". The fact that they paid out-of-pocket seems immaterial to the article?
"To date, almost three years after launching 4ormat, not a single person has ever contacted us requesting support for Internet Explorer."
yeesh
yeesh
Of course they didn't. They just left.
As a web developer who deals with IE issues everyday, I can testify that this is worth it for those who can get away with it. If you are a startup that targets anyone creative or "new" end users, or if you have a significant web application, I'd highly consider it.
There are people who say that an experienced web developer can work around IE issues -- and they can. The problem is, the juice just isn't worth the squeeze. Let me explain. The cost to make your application support IE is enormous. And I'm not just talking about the cost to make it work and feature complete in the browser. I'm talking about the cost that you could be working on other products or features that drive the business -- the stuff that really matters and delights users.
Beyond preventing you from focusing on what matters, there's also a significant amount of technical debt that has to be inherited with every IE hack you add to your code base, and in some cases supporting IE can mean saying no to certain product features that otherwise could have been possible. This means that IE is actively inflicting damage to other browsers and is in effect lowering all your users -- even if they have a good browser -- on to a least common denominator experience.
IE also hurts your customer service and support personnel. Troubleshooting IE specific issues and quirks is painful, random and at times non-deterministic. You'll likely be consulting arcane MSDN articles published in the early to mid 2000's, and in general frustrating customers and developers alike. It can affect your entire organization, keeping everyone busy working around the issues -- from your front line customer service people, to product managers and developers. It's simply amazing what damage the browser can and does do to a web company.
I also agree that IE, in any version thus far widely available, is an albatross. In Microsoft's defense, I haven't used IE10 for development purposes nor do I target it (that's because almost no one uses it and access to the browser is hard to get outside of developer previews). But even IE9 is simply too little, too late. And in too little I mean it still doesn't get all of CSS3 right (I still have to create hacks around various issues and have only marginally more confidence compared to IE8). Not to mention the fact that users must be on Vista or Win7 means many Windows users will be stuck on IE8 for years, making it even more irrelevant. By the time IE9 has finally reached critical mass, the other browsers will likely be light years ahead (Chrome major version 30 by then??). This issue with upgrade path and slow speed of innovation is cause for great concern with developing anything on IE.
Developer tools in the IE browsers are also less than stellar. Microsoft has invested large amounts of effort and time into its Visual Studio line of tools and it shows. They are generally high quality and provide an excellent developer experience for working and debugging code. In stark contrast, IE Developer Toolbar, F9 Developer Tools, and Microsoft Script Debugger seem like after thoughts. The experience is subpar in almost every category compared to working with Firebug in Firefox, built-in Firefox debugging tools, and the amazing WebKit inspector and remote debugger. In addition, the tools and usage of them is fragmented across the different IE versions (a different combination of tools is needed per version to debug issues and inspect the DOM). As far as I know, remote debugging isn't widely available for IE, in any version.
Why has this happened? I largely feel that Microsoft's lack of focus on the browser and web standards over the past 10 years, and instead it's focus on Visual Studio and .NET have led them to a serious game of catch up. The browsers themselves are inadequate, the developer tools are not high quality, and the upgrade speed and innovation path takes years. Add all this together and it's a recipe for continued issue and pain with IE - in any version. Incremental improvements may be made, but they are just that. There will always be a game of catchup to be played, along with a new bag of hacks to implement and associated organization pain.
So if you can, do it! Drop IE! Your developers, employees and customers will thank you!
There are people who say that an experienced web developer can work around IE issues -- and they can. The problem is, the juice just isn't worth the squeeze. Let me explain. The cost to make your application support IE is enormous. And I'm not just talking about the cost to make it work and feature complete in the browser. I'm talking about the cost that you could be working on other products or features that drive the business -- the stuff that really matters and delights users.
Beyond preventing you from focusing on what matters, there's also a significant amount of technical debt that has to be inherited with every IE hack you add to your code base, and in some cases supporting IE can mean saying no to certain product features that otherwise could have been possible. This means that IE is actively inflicting damage to other browsers and is in effect lowering all your users -- even if they have a good browser -- on to a least common denominator experience.
IE also hurts your customer service and support personnel. Troubleshooting IE specific issues and quirks is painful, random and at times non-deterministic. You'll likely be consulting arcane MSDN articles published in the early to mid 2000's, and in general frustrating customers and developers alike. It can affect your entire organization, keeping everyone busy working around the issues -- from your front line customer service people, to product managers and developers. It's simply amazing what damage the browser can and does do to a web company.
I also agree that IE, in any version thus far widely available, is an albatross. In Microsoft's defense, I haven't used IE10 for development purposes nor do I target it (that's because almost no one uses it and access to the browser is hard to get outside of developer previews). But even IE9 is simply too little, too late. And in too little I mean it still doesn't get all of CSS3 right (I still have to create hacks around various issues and have only marginally more confidence compared to IE8). Not to mention the fact that users must be on Vista or Win7 means many Windows users will be stuck on IE8 for years, making it even more irrelevant. By the time IE9 has finally reached critical mass, the other browsers will likely be light years ahead (Chrome major version 30 by then??). This issue with upgrade path and slow speed of innovation is cause for great concern with developing anything on IE.
Developer tools in the IE browsers are also less than stellar. Microsoft has invested large amounts of effort and time into its Visual Studio line of tools and it shows. They are generally high quality and provide an excellent developer experience for working and debugging code. In stark contrast, IE Developer Toolbar, F9 Developer Tools, and Microsoft Script Debugger seem like after thoughts. The experience is subpar in almost every category compared to working with Firebug in Firefox, built-in Firefox debugging tools, and the amazing WebKit inspector and remote debugger. In addition, the tools and usage of them is fragmented across the different IE versions (a different combination of tools is needed per version to debug issues and inspect the DOM). As far as I know, remote debugging isn't widely available for IE, in any version.
Why has this happened? I largely feel that Microsoft's lack of focus on the browser and web standards over the past 10 years, and instead it's focus on Visual Studio and .NET have led them to a serious game of catch up. The browsers themselves are inadequate, the developer tools are not high quality, and the upgrade speed and innovation path takes years. Add all this together and it's a recipe for continued issue and pain with IE - in any version. Incremental improvements may be made, but they are just that. There will always be a game of catchup to be played, along with a new bag of hacks to implement and associated organization pain.
So if you can, do it! Drop IE! Your developers, employees and customers will thank you!
Note that Visual Web Developer can be used as a script debugger for IE.
I can't tell whether this is web or only photo hosting, but I have to wonder whether this prevents their customers from showing full web authoring competence by publishing portfolios that demonstrably work in every browser.
The sites generated by 4ormat support IE so our user's customers can definitely see their work in every browser. It's the app itself which you can't use in IE which is the overwhelming majority of our development.
In case anybody who is not running windows wants to see what their site looks like in IE, I fired up parallels out of curiosity:
http://i44.tinypic.com/54vewk.jpg
http://i44.tinypic.com/54vewk.jpg
For sites with a technical audience, IE is pretty much expendable nowadays. For example, looking at the analytics for railstutorial.org shows that more than 96% of visitors use something other than IE.
Can't believe I just wasted a few minutes reading that article. I went to find out how to save over $100k and learned nothing other than what I already knew: older versions of IE cause issues.
Normally I'm not worried about IE7/6. The only time it is an issue is when a corporate client (who else is stuck using those browsers, these days? not many) complains that their new, cutting-edge social media app doesn't render properly in their antiquated browser.
We have done this for many of our projects and saved a lot of money and time. And actually it had only a marginal effect on our site statistics compared to the efforts we had to put into testing and developing for IE.
So what about IE10? It is still missing WebGL, but do you use that?
Nope. Not even IE10. If they pop Webkit rendering into IE maybe we'd consider it.
There also just aren't that many users showing up to our site using IE. That graph in the article is straight from Google Analytics for our main landing page.
There also just aren't that many users showing up to our site using IE. That graph in the article is straight from Google Analytics for our main landing page.
IE 10 is a high quality standards compliant browser. Webkit rendering is not the web. You should support it. And Opera. And IE9 unless you absolutely require features it does not support.
You lost me at "And Opera"
Has there ever been a business case for supporting Opera?
You need a business case to write standards compliant accessible code that is browser agnostic?
WWW - as envisioned by Berners Lee - is getting worse.
> Berners-Lee identifies universality as one of Web’s key principles, providing people with the freedom to link to anything, regardless of hardware, software, or Internet connection.
WWW - as envisioned by Berners Lee - is getting worse.
> Berners-Lee identifies universality as one of Web’s key principles, providing people with the freedom to link to anything, regardless of hardware, software, or Internet connection.
Yes I do.
I pay my rent with money, not with good intentions by some guy who has been granted a nighthood.
That said I assume a fairly standard webpage is rendered decently in Opera so I wouldn't block it (as I would haave done to IE if it had had the market share of opera).
I pay my rent with money, not with good intentions by some guy who has been granted a nighthood.
That said I assume a fairly standard webpage is rendered decently in Opera so I wouldn't block it (as I would haave done to IE if it had had the market share of opera).
I would say that the responsibility on the developer for that vision to occur is to write standards compliant code. Working around bugs or quirks in a specific browser I think falls into the realm of business case.
"Works in WebKit" isn't necessarily equated to "write standards compliant code". For organisations that manage to develop a website that requires a $100,000 outlay to work in Internet Explorer, that can't possibly be a web standards compliant code base they are starting from.
Webkit rendering is not the web, true. That's sad though. I'd rather it WAS the web, and we could go on and improve on it (new image apis, sound apis, acceleration, etc), instead of reinventing various variations of the wheel (ie. basic html rendering).
As for Opera, should they support any oddball browser engine out there with it's particular quirks?
Two words for you: "opportunity cost".
As for Opera, should they support any oddball browser engine out there with it's particular quirks?
Two words for you: "opportunity cost".
Wait - do you actively block IE or do you just ignore it in testing?
If you just ignore it in testing, fine.
But if you actively block it then you are evil and no one should copy you.
If you just ignore it in testing, fine.
But if you actively block it then you are evil and no one should copy you.
What about IE with Chrome Frame?
http://www.google.com/chromeframe
http://www.google.com/chromeframe
I think you could just use Chrome Frame if it was absolutely required but it's just never come up.
[deleted]
What's interesting is that 40% of the users were on Safari (Mac) and 65% users were on a Mac. This automatically precludes IE on this very large percentage of total users.
All I can say is great news. I hope this catches on with other startups.
Interesting... Wonder how much they lost...
IE sucks, I don't blame them. Helping us push to the future.
I wouldn't go out of my way to support it either.
If it happens to work in IE, then fine. If not, tough Rocco's.
If it happens to work in IE, then fine. If not, tough Rocco's.
Kind of brings you close to this thought on Microsoft's position to Firefox:
http://www.quora.com/Who-is-most-likely-to-acquire-Mozilla
http://www.quora.com/Who-is-most-likely-to-acquire-Mozilla
tl;dr: if you build a tool which solves a significant and recurring pain point for creative professionals, you can get away with not supporting IE.
The article does not provide much insight into building a consumer-facing application--this is the equivalent of a company using an intranet app which is IE6-specific.