Slashdot Mirror
When Should You Stop Support for Software?
hahafaha asks: "I am currently working on a website for a small organization. We (I am not alone in this) have a beta version ready, and are currently testing the site on browsers. We have tried all of the big browsers (Firefox, IE, opera), as well as other browsers, such as lynx, links, w3m and even NetFront. So, when can one decide that they will stop supporting a system. Obviously, going (for example) down to IE 1 is crazy, but is IE 3 crazy? This is not only relevant to web design but to any programming at all. When, for example, can you say that I will *not* support a certain version of Windows. Can you say that now about Windows 98? How about 95?"
Depends on if you consider x% of the interweb population to be valuable to your business.
// file: mice.h
#include "frickin_lasers.h"
That is what I see. When the vendor drops support - and that can range from normal EOL to extended contract based EOL - it is time to stick a fork in it. Sadly, it looks like I get to keep a copy of Solaris 8 running for a few more years....
+++ UGUCAUCGUAUUUCU
Whenever the cost of supporting the customers that comes from supporting those customers, exceeds the benefits of satisfying those customers.
The trick is determining the costs and benefits. But often it is not that hard.
That's a business decision, not your's.
If the company is willing to pay you to support old browsers/OS's because the company is getting something out of the clients with those browsers/OS's, then that is their concern.
If you're looking for a baseline that may be acceptable for customers, you could just use the browser vendor's support matrix. If the vendor doesn't support it (IE 2.0), it'll be difficult for you to support it.
Realistically speaking, it depends on your target audience. It's probably safe to ignore IE5 and older versions of Netscape, because your customers probably can update to newer versions, even on older OS versions.
I develop websites as well as part of a much larger firm. We stop providing support for older browsers (Like IE 5 and 5.5 Mac) when MS decides to stop supporting them.
:)
.8, and Safari (forget which version).
We will only test on XP, Win2K and win 98, but not 95... (that's just silly
Our browser support goes back to IE 5.5 Win, NS 6, FF
Take the hint from others and you will be able to justify your actions.
The Code Ninja is swift with his tool, precise in his delivery, and deadly accurate in his execution.
I suppose the obvious answer would be "What is the lowest level that you could reasonably expect from your userbase". For a site touting the latest and greatest in web technology, you might be a bit heavier in your requirements than for, say, a site on nutrition.
For regular applications, you might ask yourself what the lowest level is that can reasonably be expected to do what's required. i.e. if you need a gig and a half of RAM for most operations, you might not support Win95 simply because it can't support you RAM-wise.
Then, even if you could do it in '95, would your userbase still be in '95? Really, it just boils down to "what's on the machines of the people you want to serve?"
You are standing in an open server west of a blue house, with a boarded front door. There is an Exchange mailbox here.
Profitability.
If you're programming for money, then do you want to do business with the largest userbase possible. That means, what you are doing is popularity driven. If your customers are on win3.11 or dos6 machines, then you code for those machines. If you've got your current product sufficiently done and have some extra time left over, then is the time to spread into new markets as is with all businesses. Ultimatly, if cost doesn't justify the support then don't do it.
If you're programming for fun, then you do what you want because it's rewarding to you. Make your app for a certain platforms and it's popularity will drive itself. Hence the OSS model. Doing anything else is sadomasochistic.
The last and best place support should end up is in a perminant forum with a very good search utility and an FTP file archive all running on old, redundant, stable hardware that will mabye get a few hundred hits a year. Your reputation will be very good for providing support like that since people know in 10 years when they plug in their old machine they can still find drivers or programs for it even if nothing new is being produced for it. It's also very cheap.
If I were you, I'd put up a counter and see what browsers are visiting the site, dropping support for browsers that never visit.
The same principle goes for the rest of everything. Have a peek at the statistics, and if no one uses it, then don't support it. It's that simple.
Alternately, don't support it if it's just too hard/impractical to support it. If a minor change would do, then it wouldn't hurt.
Whatever you end up doing, don't block browsers out with the horrid "Sorry, you do not have Internet Explorer 5.0 or better" message. Most of the sites that show that message, I can view just fine if I can manage to get past the browser-blocking "welcome" page. Let the browsers "try" to view the page, even if your "what kind of browser are you?" check thinks it shouldn't be able to. Even if it doesn't display perfectly, the user might still get the information they were looking for.
-- I prefer the term "karma escort."
(total number of users) * (% of users using browser) = # of users who you won't be supporting.
.5% of total market share, but you get my point).
We have a two-tired philosophy: we don't test with browsers that have 5% market share, because we're a small business with limited resources. However, if a user reports a problem in a 5% browser that's easy to fix, we'll fix it. If it's a fundamental issue (lack of CSS support, etc), we'll just say "sorry, can't do it."
If it's not fundamental but not easy to fix, we'll consider the direction that the browser's market share is going in. An IE 4 problem that would take a lot of time to fix is not as important as an Opera problem that will take a lot of time to fix, because any work we do to support IE 4 is less and less valuable every day; Opera work should be worth more or less the same in a year that it is now (yeah yeah, it may gain another
As you get more users, that threshold drops. If you've got a million revenue-generating users, it only takes a fraction of a percentage drop in revenue to justify the resources needed to support an old browser.
Cheers
-b
If I wanted a sig I would have filled in that stupid box.
The problem with this line of reasoning is that it means supporting browsers (or in the larger view, platforms) which are so old that making your product work with them is a huge security risk.
Supporting older web browsers means allowing 40-bit SSL for "secure" transactions.
Supporting older Microsoft OSes is basically the same in terms of authentication mechanisms, for example.
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
More up to date browsers?
It is not so much that lynx is not up to date, but just that it does not have a fancy GUI.
Firehed - Unfortunately, thanks to medical breakthroughs, common sense is not as common as it once was.
I think a more relevant analysis is this:
Are those users that you're shutting out likely to be also people interested in your products/services/charity etc?
Compare the demographics of your "typical customer" to the people who still use outdated OSs/browsers. If your organization sells expensive golf clubs, how likely is it that a potential customer for those clubs will be running Windows 95 (or whatever)?
(Yeah, we've all heard stories of bigwigs with stone age software, but those are the exceptions)
The gold standard in this case is to find out what browsers your clients are using at home and in the office. Then be sure that all those work flawlessly.
--
Yes. I'm cynical, aren't you.
The gold standard in this case is WILL IT MAKE MONEY. If supporting users on IE3 costs more money than you'll get FROM users on IE3, don't do it. Simple.
-----
PGP Key ID 0xCB8FF658
Part of the challenge of determining what systems to which you will present lies in weighing the advantages and disadvantages of given software versions with their popularity. As such, I would actually endorse prioritizing support of Windows 95 over Windows 98, since Windows 98 added few if any notable technological advantages over Windows 95 OSR2, feature additions of dubious usability, and was (in my experience) less stable as well. Additionally, developing for Windows 95 always produces compatibility with Windows 98 as a consequence, although the inverse is not always true. "Newer" or "more popular" do not necessarily mean "better" or "more suitable" for testing.
It depends on your definition of "support". To many web developers, "support" means you deliberately prevent the site from working on unsupported browsers. A slightly more lenient web developers will instead throw up a "hey idiot" message to users that they aren't using an approved browser.
What you need to do is to make the page conformant to standards. Don't use yesterday's revised standard, use something that reasonably supported by a lot of browsers. And use only what you need, because the more odd corners of CSS you decide to use, the fewer browsers the page will render correctly in.
Dish out IE-specific pages to IE, because it whines if it doesn't get them. Then dish out standard HTML/CSS/Javascript to everything else. If you want to be thorough, dish out HTML 3.2 for older browsers.
You will want to *test* the page on a lot of different browsers at a lot of different versions. You should be doing this anyway, without having to ask Slashdot for permission.
Don't blame me, I didn't vote for either of them!
This completely depends on your customer base. If 80% of your customer base is Windows 95, then you'd better support that platform. If it's just two percent, and the other 98 percent is Win 98 and Win XP, then it's probably time to rethink that last two percent, especially if continuing to support is holding you back.
That said, think a long time before you drop support, and only do it if continuing to do that support is hurting your company or the product in some way. Customers in that minority that enjoy your products, and especially long time customers who are in that minority, will be pretty vocal about their happiness that you've got a product they can still use. This can help drive further sales.
At some point, you might have to drop support despite the wishes of these customers, but until that time, continue to support 'em as long as you can.
We have a set of potential customers we'd love to be able to support with our products, but the platform vendor bailed on 'em a long time ago. We can't even get the development software for the platform any more. We've had a number of inquiries about that platform, and we know that if we could support those folks, they'd love to have our software, but there's not much we can do.
I'm not trying to attack or troll, but seriously, you can't develop a product to beta stage, and then start questioning whether it should run on hardware/software X or Y.
The correct way to go about any project is to identify the target audience and their technology, and develop accordingly. 12 years of bone-headed decisions have taught me this simple truth.
Never build a house first and then question if the design was right or the tools were chosen correctly - identify what you need in a house first, design it accordingly, and then pick the tools to build it.
In my experience, most users of Opera and Firefox won't fall back to IE if the website appears broken. You've already pissed them off by not working with their preferred browser. If you're not somehow handing bars of gold through the screen, they won't stick around longer than it takes to close the tab.
Batou: Hey, Major... You ever hear of "human rights"? Major: I understand the concept, but I've never seen it in action
Things have changed. You can easily write javascript that is 99% cross-browser, at least for browsers released this century.
Business. Numbers. Money. People. Computer World.
w3schools.com is directed towards a technical audience that is more likely to use minority browsers.
For example, this page shows 85% IE, 10% Firefox, and 5% everything else. And, Web browser statistics are unreliable.
In the real world, design the site on Firefox, debug the site on IE6, and make sure there aren't any glaring incompatibilities in Safari and Opera. Minor unfixable incompatibilities (such as Opera's and Safari's problem with jumping centered content based on whether there is a scrollbar) with non IE/Firefox can be ignored.
I think that it depends entirely on the type of site.
I like to give the example of a local company that was offering some sort of website video streaming software for smaller retail firms. About a year ago, I was forwarded an introductory letter with a demo URL. My default browser, Mozilla, did not load the page properly at all -- I didn't bother to see if it would work in IE or not. Simply put, if you are trying to sell web based software to technical users, you better have the site work in more than just IE.
However, if it's a website of a smaller organization (that isn't technically orientated) that doesn't have the resources to spend on extensive compatibility testing, I will often cut them some slack and try IE.
Here's a crazy idea:
Instead of coding for specfic browsers, write valid code!
That was the whole intent of the web in the first place.
I always find it ridiculous when a website talks about what browsers it "supports." Websites should not be browser-specfic.
Also:
USE AS FEW FEATURES AS POSSIBLE.
I can't count how many times I've seen things that could have been done in simple HTML, done instead in flash, java, javascript, activex, etc. The more different technologies you use, the more you'll get screwed up by subtle glitches in their implementation.
In short, pick a handful of good technologies and implement them properly. Support users by pointing them to software that is not broken.
Life is too short to proofread.
Grandparent post:
Do you use java, javascript, CSS, flash, CGI, etc., or not?
Your post:
No, a flashier website will still work just fine on lynx, if it's done competently.
That's an awful broad statement to make in response to a post that gives five specific examples (some valid, some not). However, grandparent poster did not give sufficient detail, but I'm bored and will give some.
1. Java. I fail to see how a visually oriented java based website will work "just fine" in lynx, regardless of comptence. Let's take a good example of when to use java - I have a number of server software packages that use java based websites to provide system/software monitoring capability, specifically real-time graphing of various things. Lynx cannot provide that. If I'm in text only mode for whatever reason, I'll monitor the servers using text utilities.
2. Javascript. Moving into something I've written recently, I have a nice AJAX based based database front-end. It's meant to allow users on Windows, OS X, or Linux to graphically manipulate the database. It does so very nicely according to all of the users. Lynx cannot do what's required for the application. However, again, if I were trying to work the console, there are text based database front-ends. The key is to use the appropriate tool.
3. CSS. OK, grandparent loses some points on this one, as most things you do with CSS don't affect lynx, in that it simply ignores the CSS and presents the content in plain format.
4. Flash. I'll assume that the flash content is something that would be useful to the viewer and is, per your statement, "done competently." This eliminates sites that use Flash "incompetently" - doing things like using it for naviation and not providing html links to the same content and so on and so forth. This still leaves us with interactive meida, multimedia presentations, online tutorials that simulate applications, and various front-end software as discussed in points 1 and 2 that's also possible to do in flash. Unless you've convinced lynx to download the flash file and hand it off to flashplayer, none of these will work with lynx.
5. CGI. I'll give you this one, as whether a website is using CGI or not really doesn't have much effect on whether a page will work on lynx or not. I suppose maybe the poster was getting at the fact that many of the clever CGI programmers these days also integrate java, javascript, or flash into their applications.
So that gives you two points and grandparent three. I award the belt to him.
Really, what it comes down to is evaluating who will be using your site, what they're doing, and what their needs and expectations are. Most of what grandparent posted about aren't used in a *needed* way on public websites, but are extremely useful when done correctly. You also need to evaluate what portion of your site is reasonable to have higher requirements for. Are you simply presenting information or pushing the envelope into increased user interaction?
Google.com works with lynx, while google maps does not. Part of what google maps presents (directions, things near places) *could* be presented in lynx, but you know, doing so would take a very large amount of effort for virtually no payoff. I don't think google stockholders are loosing too much sleep over the issue.
Similarly, my main website supports and has been tested in IE 5.x for Windows and Mac, IE 6, Mozilla, Firefox, Safari, Opera, Konqueror, Lynx, and Links. It looks virtually identical in all of them, but doing so required some horrible kludges that make the code harder to read and understand.
On the other hand, my web applications (both internal and for public use) support IE 6, Moz/FireFox, and Safari. The code is clean and simple, and works in all three with the exact same code for the most part - there's very little that's coded based on which browser you're using (obviously, the AJAX calls are different). I could spend time devising wa
The only reason why there's a 10 year requirement for car manufacturers (at least in the US) is a safety issue-- you wouldn't want 10 year old cars rolling around on bad brakes due to parts being unavailable, would you?
I don't moderate anymore. Karma penalty for 90% fair mods? Can I mod that unfair?
Disclaimer: Writing this after coming home from the bar and randomly having a look at slashdot
10 years is FAR too long for software development.
I'd disagree. I regularly write code in a language invented 20+ years ago for an interface defined 20+ years ago, using principles defined over a hundred years ago.
You'd either be limiting your functionality
Do you mean functionality, or do you mean "shiny things"?
particular old browser
What has writing HTML to do with software development? That aside, if you concentrate on content rather than "pretty" then practically any browser in existence will be able to deliver that content to the user perfectly fine.
What would Lemmy do?
Get a clue. Don't support the browsers. None of them. Don't support the IE series or the Firefox browsers.
Support to a set of standards.
Well, that's the principle. Since 90% of the web surfers (less on tech-savvy sites) use IE, I suppose explicitly supporting the latest version of IE is a good idea. But other than that:
I'm sure there's a lot more that every webdesigner should know, but this is a nice start.
IMHO, what it really depends on boils down to two things:
1. Is it worth the time to develop it for release? (Return on investment, factoring in goodwill and brand loyalty, etc.)
2. Would it be a support nightmare after release? (If you can't reproduce problems, you can't fix/mitigate them very well, and the customers may end up being more frustrated than if you'd just told them "Sorry, use Firefox".)
E pluribus unum
I quit supporting it when the original creators stop supporting it. Windows: 2000 and XP only - no NT, no Win9x - Browsers are the same. If the guys that wrote it give up on it it, far be it from me to continue to support it's arcane functions.
"Straddling the sword of technology..."