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"
Yeah, what happened to "Degrade Gracefully".
I mean, if you're entire business is a web app which requires CSS and modern javascript... then support what you need to support. I'd personally support firefox 1.0+, netscape 6.0+, IE 5.5+. That will encompas more than 99% of people; after that I think it's really diminishing returns (pre-IE5.5 means pre-windows98).
I can't see supporting netscape 4.7 anymore. It was a good browser, but it was released in what, 1998? It's time to move on, folks - it's been 8 years. It doesn't support CSS and iframes properly and a whole bunch of stuff. Trade in your SparcStations and PackardBells for something modern, please.
Just attempt to make it degrade gracefully.
~Will
sig?
I just read that using Opera, you insensitive clod.
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."
Whenever the cost of supporting the customers that comes from supporting those customers, exceeds the benefits of satisfying those customers.
You don't ever stop supporting your customers. You just switch to paid support after your warranty or contracted support period has expired.
I'm still supporting the first commercial software I ever wrote (a refrigerator controller for a meat packing company) because it still does the job I originally wrote it for, and the company using it occasionally pays me to port it to newer hardware. I'm not making a loss, and it's not a huge money spinner for me, but I'll continue supporting it because it's mine.
"I've got more toys than Teruhisa Kitahara."
I'll disagree with this. The company I work for recently stopped support for some software we wrote in 1999. We provided more than 2 years notice, and a reasonable upgrade path.
Our entire code base was rewritten in 2000 and once again in 2005. Supporting 3 different code bases is not practical.
First of all, for front line support people, have them trained on 3 different products is simply not practical.(While the 3 pieces of software are similar in general functionality, they're are significant differences in how the achieve that functionality.)
More importantly, the number of developers that are familiar with the original code base is small. And these are the most senior developers and having them spend the their time looking at the old case base is not a productive use of their time.
I suppose we could have offered a support contract to the customers of the older version that represented the realistic cost of what it would be to support the older code base. But, the number would have been ridiculously high and would probably be seen as quite insulting by the customer.
It made more sense to announce the sunset of the product with a large amount of advance notice, and provide a reasonable upgrade path.
Since when can the first post be modded 20% redundant?
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
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