even when there was massive amounts of file sharing it was still considerably faster than my 1.5/768 dsl is now, so I don't think bandwidth is the real issue as some have suggested.
Whoa there, slick. So long as you have as much bandwidth as you'd want or expect, that means there's no bandwidth problem?
While universities (usually) have a sufficiently large pipe, they're still quite likely paying for the utilization of it. (In other words, it's driving your tuition up.) Just because things still "work" for you at speeds you're comfortable with doesn't mean a) your network isn't at or near capacity; b) other projects at the university aren't feeling the crunch; or c) that the network bill hasn't doubled or more as a result of this type of traffic.
I'm not going to throw judgements at college kids that download and serve porn and mp3's 24/7, but don't do it thinking that it doesn't affect you or anyone else.
The campus network is handled by ISD (Internet Services Division) which has nothing to do with the CS department.
And rightly so..:)
The CS folks I'm sure all want to experiment and play, and the ISD folks are probably there to ensure security and connectivity. Often times those goals are at odds with each other.
USC also seems to take complaints about the students overly seriously.
Most major universities do, actually. It's fairly common to get letters of reprimand for port scans and the like.
It was much easier nailing script kiddies at their university when they were doing everything from their PC's instead of bouncing from a dozen hax0rd Korean servers... Nowadays you actually have to do some real research. The good thing is that by the time you do get all of that research done, you have a mountain of evidence and involvement from other ISP's (and perhaps governments). Universities tend to do a little more against those students when presented with this kind of research and contacts than if someone just sends an e-mail with IDS logs..:)
How is this any different from a rear-view mirror? If a driver has to cock his head slightly to get a view of what's behind him, what does it matter if it's a video screen he's looking at or a mirror? Do you think we should ban the use of rear-view mirrors? How about the side ones while we're at it?
I completely agree that distractions should be avoided, but any mechanism that allows the driver to minimize the effort and attention required to collect information about the road around him and the occupants in the vehicle is good in my book.
p2p breaks our precious little ratio of what we expect and what we need
Uhh, yah, except this is how they're determining how much they can charge you. If the ratio becomes permanently skewed, the way they "evolve" as you put it is to simply skew their prices to compensate. Though your end user connections may be effectively "unlimited", someone upstream pays for the bandwidth by how much data gets transferred. I guarantee the costs will filter down.
So as a business, what would you do? Raise your rates for all "unlimited" customers? Create a new class of DSL customer with a lower bandwidth cap and re-figure the ratio? Block P2P activity entirely? Write into the end user contract some soft usage caps and go after the top 1% of bandwidth consumers? All of the above?
I don't really think P2P is going to drive growth (i.e. more bandwidth for less cost) any more aggressively than the growth we're already seeing. I just think it's going to annoy ISP's and make them re-think some of their "unlimited" bandwidth plans.
FYI, I received the same "release" as quoted above in multiple pieces of spam this weekend. Keep this in mind when we show our support and interest in this (admittedly amusing) venture.
So without using the words 'perpetual motion', we have a vehicle that can travel, with batteries, some 4000km, and at the end of it, those batteries will continue to have a "full charge".
Presumably the battery started at a "full charge" at the beginning of the trip. If the battery has not lost any energy, where did the energy for that trip come from?
Suppose the car was able to convert ambient heat into energy for the car
While it's true that a temperature differential can create an electric current, there is no differential here. If the car is starting from a "cold" condition, it's effectively the same temperature as the ambient air. The only way you're going to generate an electrical current is if it had some supercooled or superheated core, and eventually it would reach thermal equilibrium with the environment and your electrical current would go away. You can't just "extract" heat from the air and turn it into useful energy. It would require energy to power a thermal pump (e.g. an air conditioner) of some kind to collect heat.
Air movement does not cool something to anything below the temperature of the air. The only exception to this might be if you're cooling through evaporation, but you're screwed once you're out of stuff to evaporate, or when the air reaches saturation.
They used to have "air conditioners" that worked this way. You'd stick a unit in your car window and the movement of the air combined with a fine mist of water was supposed to cool you down. It didn't work too well.
I consider myself to have an extremely analytical and objective mind with respects to things like this, and if this were presented as legitimate research, we might be a little more keen on listening to it, but it's being presented in the same manner that numerous other "inventions" have been presented where the only gain occurring was by bilking investors out of money.
I'll believe it when I see it, and I really doubt we're going to see anything other than a show here. Once you get exposed to a large number of these types of fraudulant inventions, you kind of know how to spot them in the future.
can you name me one advantage the yards/miles/gallons/etc system has over the metric system?
Umm, zero cost of conversion?
Nobody's arguing that metric is superior. It's not the USA being arrogant, it's the USA listening to all of the businesses that whine whenever the topic of conversion is brought up. The USA very much caters to its corporations, even when it isn't in anyone else's best interests or even logical.
In the US government many (most? all?) contracts and the like are required to be performed in metric. Some businesses work in metric. While total conversion to metric is more costly than the short-term costs involved in converting on-the-fly, don't bet that it's going to happen any time soon.
The real question is: what is making a profit and what is covering expenses?
I'm afraid it doesn't really matter. Once you slap advertising on your site and try to sell your site's content to advertisers, you've gone commercial. It doesn't matter that it isn't successful or that the incoming cash doesn't balance the costs of the business, it's still legally a commercial venture at that point.
I see no problem in a fan hosting a site about public entertainment, with logos, and make some money off of it.
I completely agree, but unfortunately it's up to the trademark holders here, and they've spoken. The problem is that you are using their logos to say "hey, come over here! we have XYZ-related content on this site!". Without the use of their logos, the site owners would (arguably!) not be able to attract the same size audience they usually would, which would impact the amount of money they take in through advertising. Here, the presence of the trademarked logo has a direct impact on the money the site owner receives through its advertisers. This is the problem the MLB is trying to address: the use of their logos to attempt to make a profit.
Now, I totally agree that it's kind of stupid for them to be going after fan sites like this, especially in these times. I think what they're doing is kind of silly, but I'm trying to present the above in a more rational way so that you're aware of their line of reasoning here.
That's just saying that it couldn't even get to the site from the United States, which probably means the site's down or you mistyped a URL. China wasn't tested here.
Agreed, I was a little surprised this was making headlines. I saw a Discovery Channel or TLC bit about it over a year ago that went into a lot of detail about the same material.
IANAL, but legally, they wouldn't be able to convict you of crimes your neighbors did. If it's pretty clear that you do resell service, they obviously aren't going to be able to convict you of a crime using that service. But be aware that some states have laws that include phrases like "avoids consciously knowing" that can still make you liable for crap your neighbors do if you take steps to keep their activities untraceable.
In addition, this is just the legal side of the coin. Your contract with your ISP probably makes you 100% liable for the activities performed through your connection. You may be able to appease your ISP by telling them you've identified the source of the abuse and stopped it. But if this is a recurring matter, and due to your anonymous usage policies you are unable to get it stopped, your ISP is going to pull the plug on you, and rightly so.
And keep in mind that I'm just talking about usage information, not actual monitoring of content, which I don't think the original poster was recommending.
The fact is that if you use "advanced browser features" you end up locked into a browser brand and version.
Agreed. My comments were geared more towards testing and supporting a particular browser, though, not towards writing for a particular browser. We discourage writing for proprietary features of a web browser just on general principle.
Aside from that I mostly agree with all of your other points, though I still think less of the mainstream web guys than you do. Maybe all of the companies I've worked for have just been dominated by below-average employees that should not have been in those positions, I don't know. We certainly have a number of people that do know how to write clean code, and how to build applications that output clean, validator-friendly code, but generally these guys are in positions a little more advanced than a typical web monkey.
Running UNIX was a job requirement for my position.
It sounds like your job requirements were counter to your company's standards. You have a legitimate gripe, but it's against your company, not the web designers. They made a conscious business decision to accept what may very well be "faulty" code in their web sites and/or to hire designers without requiring them to adhere to standards.
I think you should petition your higher-ups to spend the extra money to train your developers to learn how to standardize their HTML output, purchase better authoring tools that generate clean HTML output, and get more testing time against your sites to ensure everything validates cleanly and appears as expected in your web browser. What do you think they will say to that?
Being simply standards-compliant is not enough. Standards-compliant code may still appear differently in different browsers. Testing must be performed if you want to view that page as designed in your browser of choice.
In fact, I'd wager that the over all testing cycle would be shorter if you started by validating your HTML.
I agree, where "testing" in this discussion refers to the look-and-feel of the site. With full-blown usability testing, you're primarily checking the functionality of the site, and that's generally done once for each set of browsers being targeted. Look-and-feel is part of that, obviously, but isn't all of it. It's arguable how much testing time would be saved by having your developers take the extra effort (if any) to ensure their application always outputs valid HTML.
The fact is that writing actual HTML is no harder than writing non-HTML (at least for someone who legitimately claims to be able to write HTML), and it is considerably easier to debug.
This is fantasy-land, or for small firms that may wish to spend more money to hire people that really understand what they're doing. In the real world, your bottom-rung "web authors" do not have an exceptionally high degree of training, which is pretty much what you say in the next paragraph. I'm not saying this is good, but it's the real world.
In addition, some web sites have content backed by more than one application, possibly done by more than one development group or even generated by 3rd-party applications. Fixing a web page that doesn't validate 100% is frequently a little more complicated than calling Bob the web guy and having him clean up his code.
In my mind this is analogus to saying "Our C program throws a gazillion warnings, but it compiles with the particular sub-version of the compiler we are using at the moment and it seems to work with the test data. Any more testing would be a waste of money. Fuck it; were shipping it."
HTML validation problems aren't nearly as severe as warnings pointing out a potentially serious vulnerability in code. You are unlikely to find exploitable buffer overflows in HTML. I understand and empathize with your point here, but it's a bit of a stretch.
I've got news; the message is the fucking message**. I don't give a shit that you graduated top of your class in graphics design at Shitheel Technical College, I actually want to know what the number to HR is, or what's for lunch in the cafeteria or how to change my 401k. Get over yourself and give my browser the INFORMATION (That is what the "I" in "IT" stands for!) in a format that my browser, whatever it is, has a fighting chance of parsing and presenting to me however I damn well please.
Agreed, 100%. However, the people building our web site content are not the ones designing HTML. Frequently our content managers have no knowledge of HTML. They just click the bold button. It's those back-end systems, 3rd party applications, and developers in another group that actually get all of that turned in to HTML. This may be the key bit where our environment may differ from what you're used to. If we were talking about one person drawing up HTML documents all day, you're right, it's nothing to just pump these through a validator before slapping them up on a web site.
Look, I hear what you're saying. Coding to standards is really the way things ought to be. The reason I threw testing in there was because it seemed like your gripe was actually due to the fact that things did not render in your browser of choice. I was trying to point out that even standards-compliant code may not render as you expect. I frequently come across code that actually does validate with no errors whatsoever on some of our internal web sites, but the site fails to render as expected (sometimes making it very difficult to use) in browsers not supported by the company. Coding to standards only goes so far, and for internal use, actual usability testing is given precedence over ensuring that <p> tags are properly terminated.
All that managers look at are numbers. When figuring out how to design and test web sites for internal use, they go with the cheapest method for developing the sites safely, and the cheapest method for testing these sites completely, so that all employees should theoretically be able to use that site without problems with the minimum of expense. Things like strict HTML or XHTML validation are perks at this point.
Your case is peculiar because somebody made the decision to go with this site development model while simultaneously requiring a percentage of its workforce use alternative web browsers. That sucks, but it was a business decision. Estimate the costs involved in getting all of the company's sites viewable in your browser (include training and additional development time to get these sites validated and standards-compliant if you prefer) and compare that with the costs saved by letting you view these sites at your PC instead of another company-provided terminal and make a managerial decision.
Forcing XHTML means we're forcing XML, which tends to enforce better HTML coding habits in the first place, and is easier to validate. That's all I was trying to suggest.
I simply don't understand how you can label me part of the problem when I've said multiple times that we have a very extensive lab that we use to verify that public-facing sites function with a diverse set of browsers. I don't make the decisions as to how that testing occurs, be it with an HTML validation tool or other forms of software and human testing.
I also can't believe you'd advocate two to three times the testing and extend development times simply to support non-standard browsers that make up a stubborn 0.01% of employees that might use them. This does not make good business sense. Coding to standards is only part of this picture.
In an ideal world, all code would adhere strictly to standards, and all browsers would render those standard-compliant documents perfectly. This is not an ideal world, and development time and testing cost money. While I personally (like you, I believe) do not feel this should be neglected on web sites that have a non-specific intended audience (e.g. public-facing Internet sites), I see no reason to not apply only a subset of these development and testing measures when you have a very specific target audience. This in no way reduces the expectations of public-facing code, and simply allows us to reduce development and testing times (which cost money!) for internal sites.
Perhaps we'll just have to agree to disagree here Sometimes the needs of the business outweigh technical wants. Even though I am one of the biggest supporters of W3C standards and validation in the web group at my company, I nevertheless recognize that there are overriding business needs to take into account here as well.
I agree that developers should ensure that their output passes a validation test. We're actually starting to move some stuff to XHTML, so this will be even easier as time goes on.
Our testers, though, are still just going to test exclusively with with the company-standard browser for internal company sites.
So in theory, keeping the applications honest will allow them to be used by a number of different browsers. In practice, though (and this is becoming less of a problem as browsers standardize), even standards-compliant apps will fail to render as expected in different browsers. For our specific situation, though, it's not worth it for us to go that extra mile for stuff that isn't public-facing.
Well, the corp standard here is IE, but I use Opera.
It's IE here too, but I use Mozilla most of the time. Like you, I switch to IE when I need to. So far it's a non-issue.
but what we are developing is for customers (hospitals)
Then perhaps this thread doesn't really apply to you. I was simply trying to say that there are situations where coding for one particular browser is not bad.
Or some of the employees work from home or remotely and need to access it?
For us, at least, we prohibit even remote access into the corporate network from non-company systems, so that's a non-issue for us also.
It is ALWAYS "cheaper" to do something correctly up front instead of trying to fix it after the fact.
This is completely dependent upon the situation. In my corporate environment, I disagree completely. We have hundreds (if not thousands) of different internal web sites. If 1% of these sites later for some reason becomes more of a public-facing site, it's far cheaper to go in after the fact and shore it up so that it's standards-compliant and functions with other web browsers than it is for us to double (or triple or more) our testing efforts and add development time to ensure all of our sites work with browsers that are not company standards. This just doesn't make good business sense.
1. Absolutely, web standards need to be adhered to, but I don't think it's reasonable for developers to spend more time working around a quirk in their code if what they're writing displays fine on the corporate mandated standard browser.
2. No, users in the company have company-purchased PC's with company-standard operating systems and company-licensed software. This cuts down support costs significantly over some company that may allow any old piece of hardware, operating system and software that the employee wants. There are always exceptions, but there has to be a justified business reason for that exception. People going off and installing whatever software they wan't will simply find that if it breaks the company isn't going to help them. Corporate standards are there for a reason, and part of that reason is to allow us to reduce support and development costs, which includes limiting testing to that on browser that employees should be using anyway.
Now don't get me wrong, I'm using Mozilla right at this moment. And like I said, for public-facing sites, you can bet we have a lab with all sorts of OS and software combinations where sites are tested to be sure they work fine (and that includes adherence to standards). But for Intranet, employee-specific sites, it makes little sense to expand your testing costs to non-company-standard browsers that should have no business being on most employees PC's in the first place.
The only place where I could see standardizing on a browser would be for in-house stuff like this. Major companies tend to adopt corporate standards for software like this, and in my case, that software is IE. This is actually a good thing at this scale, because our IT support groups only have to worry about supporting one type of browser, etc. It's also beneficial for our Intranet web applications, because we only have to develop and test for one particular type of browser. Everyone in the company should be using company-standard software, so it's not a big deal if non-standard software doesn't work correctly with our Intranet sites.
On the Internet side, however, or where we do need to be looking at more than one browser vendor, you can bet that we test with just about every known browser. We actually have an organization devoted to doing this type of testing.
I mention all of this because there are some cases where you would want to write for a specific browser and not have to worry about everyone else.
We've submitted Jabber to the IETF twice and are continuing to press forward.
The IETF is already endorsing SIP and SIMPLE for session signalling and instant messaging. SIP is already in use today by VoIP and similar implementations. SIMPLE is just a fairly simple extension of the signalling SIP already provides.
It seems to me that the IETF would probably rather go with this than adopt something else.
These arguments sound an awful like the arguments people made with respects to proprietary online services and the more standards-oriented Internet back when it was just emerging.
Users demand interoperability. They get annoyed when they cannot communicate with users on a different service. Either the different IM clients today agree on a standard (which already exists: SIP and its descendents), or users are going to make more use of those IM clients like Trillian that interoperate with their proprietary IM service anyway. If they don't support standards, users will stop using their clients.
With SIP, your "screen name" becomes your username@domain, where the domain portion would be your local SIP server (which might be "yahoo.com" if Yahoo! used SIP).
Slashdot Mirror
Here, why don't you visit this URL I have here and then click on the auto-login bookmark you have for Slashdot.. There are issues here.
even when there was massive amounts of file sharing it was still considerably faster than my 1.5/768 dsl is now, so I don't think bandwidth is the real issue as some have suggested.
:)
:)
Whoa there, slick. So long as you have as much bandwidth as you'd want or expect, that means there's no bandwidth problem?
While universities (usually) have a sufficiently large pipe, they're still quite likely paying for the utilization of it. (In other words, it's driving your tuition up.) Just because things still "work" for you at speeds you're comfortable with doesn't mean a) your network isn't at or near capacity; b) other projects at the university aren't feeling the crunch; or c) that the network bill hasn't doubled or more as a result of this type of traffic.
I'm not going to throw judgements at college kids that download and serve porn and mp3's 24/7, but don't do it thinking that it doesn't affect you or anyone else.
The campus network is handled by ISD (Internet Services Division) which has nothing to do with the CS department.
And rightly so..
The CS folks I'm sure all want to experiment and play, and the ISD folks are probably there to ensure security and connectivity. Often times those goals are at odds with each other.
USC also seems to take complaints about the students overly seriously.
Most major universities do, actually. It's fairly common to get letters of reprimand for port scans and the like.
It was much easier nailing script kiddies at their university when they were doing everything from their PC's instead of bouncing from a dozen hax0rd Korean servers... Nowadays you actually have to do some real research. The good thing is that by the time you do get all of that research done, you have a mountain of evidence and involvement from other ISP's (and perhaps governments). Universities tend to do a little more against those students when presented with this kind of research and contacts than if someone just sends an e-mail with IDS logs..
Try not to typecast actors.. I actually think he can pull it off. I think Klein could pull it off, though he might be a bit young.
How is this any different from a rear-view mirror? If a driver has to cock his head slightly to get a view of what's behind him, what does it matter if it's a video screen he's looking at or a mirror? Do you think we should ban the use of rear-view mirrors? How about the side ones while we're at it?
I completely agree that distractions should be avoided, but any mechanism that allows the driver to minimize the effort and attention required to collect information about the road around him and the occupants in the vehicle is good in my book.
p2p breaks our precious little ratio of what we expect and what we need
Uhh, yah, except this is how they're determining how much they can charge you. If the ratio becomes permanently skewed, the way they "evolve" as you put it is to simply skew their prices to compensate. Though your end user connections may be effectively "unlimited", someone upstream pays for the bandwidth by how much data gets transferred. I guarantee the costs will filter down.
So as a business, what would you do? Raise your rates for all "unlimited" customers? Create a new class of DSL customer with a lower bandwidth cap and re-figure the ratio? Block P2P activity entirely? Write into the end user contract some soft usage caps and go after the top 1% of bandwidth consumers? All of the above?
I don't really think P2P is going to drive growth (i.e. more bandwidth for less cost) any more aggressively than the growth we're already seeing. I just think it's going to annoy ISP's and make them re-think some of their "unlimited" bandwidth plans.
Money from advertising was my guess, but I didn't look to see.
FYI, I received the same "release" as quoted above in multiple pieces of spam this weekend. Keep this in mind when we show our support and interest in this (admittedly amusing) venture.
So without using the words 'perpetual motion', we have a vehicle that can travel, with batteries, some 4000km, and at the end of it, those batteries will continue to have a "full charge".
Presumably the battery started at a "full charge" at the beginning of the trip. If the battery has not lost any energy, where did the energy for that trip come from?
Suppose the car was able to convert ambient heat into energy for the car
While it's true that a temperature differential can create an electric current, there is no differential here. If the car is starting from a "cold" condition, it's effectively the same temperature as the ambient air. The only way you're going to generate an electrical current is if it had some supercooled or superheated core, and eventually it would reach thermal equilibrium with the environment and your electrical current would go away. You can't just "extract" heat from the air and turn it into useful energy. It would require energy to power a thermal pump (e.g. an air conditioner) of some kind to collect heat.
Air movement does not cool something to anything below the temperature of the air. The only exception to this might be if you're cooling through evaporation, but you're screwed once you're out of stuff to evaporate, or when the air reaches saturation.
They used to have "air conditioners" that worked this way. You'd stick a unit in your car window and the movement of the air combined with a fine mist of water was supposed to cool you down. It didn't work too well.
I consider myself to have an extremely analytical and objective mind with respects to things like this, and if this were presented as legitimate research, we might be a little more keen on listening to it, but it's being presented in the same manner that numerous other "inventions" have been presented where the only gain occurring was by bilking investors out of money.
I'll believe it when I see it, and I really doubt we're going to see anything other than a show here. Once you get exposed to a large number of these types of fraudulant inventions, you kind of know how to spot them in the future.
But of course we could be wrong...
can you name me one advantage the yards/miles/gallons/etc system has over the metric system?
Umm, zero cost of conversion?
Nobody's arguing that metric is superior. It's not the USA being arrogant, it's the USA listening to all of the businesses that whine whenever the topic of conversion is brought up. The USA very much caters to its corporations, even when it isn't in anyone else's best interests or even logical.
In the US government many (most? all?) contracts and the like are required to be performed in metric. Some businesses work in metric. While total conversion to metric is more costly than the short-term costs involved in converting on-the-fly, don't bet that it's going to happen any time soon.
The real question is: what is making a profit and what is covering expenses?
I'm afraid it doesn't really matter. Once you slap advertising on your site and try to sell your site's content to advertisers, you've gone commercial. It doesn't matter that it isn't successful or that the incoming cash doesn't balance the costs of the business, it's still legally a commercial venture at that point.
I see no problem in a fan hosting a site about public entertainment, with logos, and make some money off of it.
I completely agree, but unfortunately it's up to the trademark holders here, and they've spoken. The problem is that you are using their logos to say "hey, come over here! we have XYZ-related content on this site!". Without the use of their logos, the site owners would (arguably!) not be able to attract the same size audience they usually would, which would impact the amount of money they take in through advertising. Here, the presence of the trademarked logo has a direct impact on the money the site owner receives through its advertisers. This is the problem the MLB is trying to address: the use of their logos to attempt to make a profit.
Now, I totally agree that it's kind of stupid for them to be going after fan sites like this, especially in these times. I think what they're doing is kind of silly, but I'm trying to present the above in a more rational way so that you're aware of their line of reasoning here.
That's just saying that it couldn't even get to the site from the United States, which probably means the site's down or you mistyped a URL. China wasn't tested here.
Agreed, I was a little surprised this was making headlines. I saw a Discovery Channel or TLC bit about it over a year ago that went into a lot of detail about the same material.
IANAL, but legally, they wouldn't be able to convict you of crimes your neighbors did. If it's pretty clear that you do resell service, they obviously aren't going to be able to convict you of a crime using that service. But be aware that some states have laws that include phrases like "avoids consciously knowing" that can still make you liable for crap your neighbors do if you take steps to keep their activities untraceable.
In addition, this is just the legal side of the coin. Your contract with your ISP probably makes you 100% liable for the activities performed through your connection. You may be able to appease your ISP by telling them you've identified the source of the abuse and stopped it. But if this is a recurring matter, and due to your anonymous usage policies you are unable to get it stopped, your ISP is going to pull the plug on you, and rightly so.
And keep in mind that I'm just talking about usage information, not actual monitoring of content, which I don't think the original poster was recommending.
The fact is that if you use "advanced browser features" you end up locked into a browser brand and version.
Agreed. My comments were geared more towards testing and supporting a particular browser, though, not towards writing for a particular browser. We discourage writing for proprietary features of a web browser just on general principle.
Aside from that I mostly agree with all of your other points, though I still think less of the mainstream web guys than you do. Maybe all of the companies I've worked for have just been dominated by below-average employees that should not have been in those positions, I don't know. We certainly have a number of people that do know how to write clean code, and how to build applications that output clean, validator-friendly code, but generally these guys are in positions a little more advanced than a typical web monkey.
Running UNIX was a job requirement for my position.
It sounds like your job requirements were counter to your company's standards. You have a legitimate gripe, but it's against your company, not the web designers. They made a conscious business decision to accept what may very well be "faulty" code in their web sites and/or to hire designers without requiring them to adhere to standards.
I think you should petition your higher-ups to spend the extra money to train your developers to learn how to standardize their HTML output, purchase better authoring tools that generate clean HTML output, and get more testing time against your sites to ensure everything validates cleanly and appears as expected in your web browser. What do you think they will say to that?
Being simply standards-compliant is not enough. Standards-compliant code may still appear differently in different browsers. Testing must be performed if you want to view that page as designed in your browser of choice.
In fact, I'd wager that the over all testing cycle would be shorter if you started by validating your HTML.
I agree, where "testing" in this discussion refers to the look-and-feel of the site. With full-blown usability testing, you're primarily checking the functionality of the site, and that's generally done once for each set of browsers being targeted. Look-and-feel is part of that, obviously, but isn't all of it. It's arguable how much testing time would be saved by having your developers take the extra effort (if any) to ensure their application always outputs valid HTML.
The fact is that writing actual HTML is no harder than writing non-HTML (at least for someone who legitimately claims to be able to write HTML), and it is considerably easier to debug.
This is fantasy-land, or for small firms that may wish to spend more money to hire people that really understand what they're doing. In the real world, your bottom-rung "web authors" do not have an exceptionally high degree of training, which is pretty much what you say in the next paragraph. I'm not saying this is good, but it's the real world.
In addition, some web sites have content backed by more than one application, possibly done by more than one development group or even generated by 3rd-party applications. Fixing a web page that doesn't validate 100% is frequently a little more complicated than calling Bob the web guy and having him clean up his code.
In my mind this is analogus to saying "Our C program throws a gazillion warnings, but it compiles with the particular sub-version of the compiler we are using at the moment and it seems to work with the test data. Any more testing would be a waste of money. Fuck it; were shipping it."
HTML validation problems aren't nearly as severe as warnings pointing out a potentially serious vulnerability in code. You are unlikely to find exploitable buffer overflows in HTML. I understand and empathize with your point here, but it's a bit of a stretch.
I've got news; the message is the fucking message**. I don't give a shit that you graduated top of your class in graphics design at Shitheel Technical College, I actually want to know what the number to HR is, or what's for lunch in the cafeteria or how to change my 401k. Get over yourself and give my browser the INFORMATION (That is what the "I" in "IT" stands for!) in a format that my browser, whatever it is, has a fighting chance of parsing and presenting to me however I damn well please.
Agreed, 100%. However, the people building our web site content are not the ones designing HTML. Frequently our content managers have no knowledge of HTML. They just click the bold button. It's those back-end systems, 3rd party applications, and developers in another group that actually get all of that turned in to HTML. This may be the key bit where our environment may differ from what you're used to. If we were talking about one person drawing up HTML documents all day, you're right, it's nothing to just pump these through a validator before slapping them up on a web site.
Look, I hear what you're saying. Coding to standards is really the way things ought to be. The reason I threw testing in there was because it seemed like your gripe was actually due to the fact that things did not render in your browser of choice. I was trying to point out that even standards-compliant code may not render as you expect. I frequently come across code that actually does validate with no errors whatsoever on some of our internal web sites, but the site fails to render as expected (sometimes making it very difficult to use) in browsers not supported by the company. Coding to standards only goes so far, and for internal use, actual usability testing is given precedence over ensuring that <p> tags are properly terminated.
All that managers look at are numbers. When figuring out how to design and test web sites for internal use, they go with the cheapest method for developing the sites safely, and the cheapest method for testing these sites completely, so that all employees should theoretically be able to use that site without problems with the minimum of expense. Things like strict HTML or XHTML validation are perks at this point.
Your case is peculiar because somebody made the decision to go with this site development model while simultaneously requiring a percentage of its workforce use alternative web browsers. That sucks, but it was a business decision. Estimate the costs involved in getting all of the company's sites viewable in your browser (include training and additional development time to get these sites validated and standards-compliant if you prefer) and compare that with the costs saved by letting you view these sites at your PC instead of another company-provided terminal and make a managerial decision.
Forcing XHTML means we're forcing XML, which tends to enforce better HTML coding habits in the first place, and is easier to validate. That's all I was trying to suggest.
I simply don't understand how you can label me part of the problem when I've said multiple times that we have a very extensive lab that we use to verify that public-facing sites function with a diverse set of browsers. I don't make the decisions as to how that testing occurs, be it with an HTML validation tool or other forms of software and human testing.
I also can't believe you'd advocate two to three times the testing and extend development times simply to support non-standard browsers that make up a stubborn 0.01% of employees that might use them. This does not make good business sense. Coding to standards is only part of this picture.
In an ideal world, all code would adhere strictly to standards, and all browsers would render those standard-compliant documents perfectly. This is not an ideal world, and development time and testing cost money. While I personally (like you, I believe) do not feel this should be neglected on web sites that have a non-specific intended audience (e.g. public-facing Internet sites), I see no reason to not apply only a subset of these development and testing measures when you have a very specific target audience. This in no way reduces the expectations of public-facing code, and simply allows us to reduce development and testing times (which cost money!) for internal sites.
Perhaps we'll just have to agree to disagree here Sometimes the needs of the business outweigh technical wants. Even though I am one of the biggest supporters of W3C standards and validation in the web group at my company, I nevertheless recognize that there are overriding business needs to take into account here as well.
I agree that developers should ensure that their output passes a validation test. We're actually starting to move some stuff to XHTML, so this will be even easier as time goes on.
Our testers, though, are still just going to test exclusively with with the company-standard browser for internal company sites.
So in theory, keeping the applications honest will allow them to be used by a number of different browsers. In practice, though (and this is becoming less of a problem as browsers standardize), even standards-compliant apps will fail to render as expected in different browsers. For our specific situation, though, it's not worth it for us to go that extra mile for stuff that isn't public-facing.
Well, the corp standard here is IE, but I use Opera.
It's IE here too, but I use Mozilla most of the time. Like you, I switch to IE when I need to. So far it's a non-issue.
but what we are developing is for customers (hospitals)
Then perhaps this thread doesn't really apply to you. I was simply trying to say that there are situations where coding for one particular browser is not bad.
Or some of the employees work from home or remotely and need to access it?
For us, at least, we prohibit even remote access into the corporate network from non-company systems, so that's a non-issue for us also.
It is ALWAYS "cheaper" to do something correctly up front instead of trying to fix it after the fact.
This is completely dependent upon the situation. In my corporate environment, I disagree completely. We have hundreds (if not thousands) of different internal web sites. If 1% of these sites later for some reason becomes more of a public-facing site, it's far cheaper to go in after the fact and shore it up so that it's standards-compliant and functions with other web browsers than it is for us to double (or triple or more) our testing efforts and add development time to ensure all of our sites work with browsers that are not company standards. This just doesn't make good business sense.
I deliberately avoided using the past-tense "endorsed" precisely for this reason. But you're right.
It seems like there are multiple efforts to build standards for the same thing. I wonder if one of these groups are defunct?
1. Absolutely, web standards need to be adhered to, but I don't think it's reasonable for developers to spend more time working around a quirk in their code if what they're writing displays fine on the corporate mandated standard browser.
2. No, users in the company have company-purchased PC's with company-standard operating systems and company-licensed software. This cuts down support costs significantly over some company that may allow any old piece of hardware, operating system and software that the employee wants. There are always exceptions, but there has to be a justified business reason for that exception. People going off and installing whatever software they wan't will simply find that if it breaks the company isn't going to help them. Corporate standards are there for a reason, and part of that reason is to allow us to reduce support and development costs, which includes limiting testing to that on browser that employees should be using anyway.
Now don't get me wrong, I'm using Mozilla right at this moment. And like I said, for public-facing sites, you can bet we have a lab with all sorts of OS and software combinations where sites are tested to be sure they work fine (and that includes adherence to standards). But for Intranet, employee-specific sites, it makes little sense to expand your testing costs to non-company-standard browsers that should have no business being on most employees PC's in the first place.
The only place where I could see standardizing on a browser would be for in-house stuff like this. Major companies tend to adopt corporate standards for software like this, and in my case, that software is IE. This is actually a good thing at this scale, because our IT support groups only have to worry about supporting one type of browser, etc. It's also beneficial for our Intranet web applications, because we only have to develop and test for one particular type of browser. Everyone in the company should be using company-standard software, so it's not a big deal if non-standard software doesn't work correctly with our Intranet sites.
On the Internet side, however, or where we do need to be looking at more than one browser vendor, you can bet that we test with just about every known browser. We actually have an organization devoted to doing this type of testing.
I mention all of this because there are some cases where you would want to write for a specific browser and not have to worry about everyone else.
We've submitted Jabber to the IETF twice and are continuing to press forward.
The IETF is already endorsing SIP and SIMPLE for session signalling and instant messaging. SIP is already in use today by VoIP and similar implementations. SIMPLE is just a fairly simple extension of the signalling SIP already provides.
It seems to me that the IETF would probably rather go with this than adopt something else.
These arguments sound an awful like the arguments people made with respects to proprietary online services and the more standards-oriented Internet back when it was just emerging.
Users demand interoperability. They get annoyed when they cannot communicate with users on a different service. Either the different IM clients today agree on a standard (which already exists: SIP and its descendents), or users are going to make more use of those IM clients like Trillian that interoperate with their proprietary IM service anyway. If they don't support standards, users will stop using their clients.
With SIP, your "screen name" becomes your username@domain, where the domain portion would be your local SIP server (which might be "yahoo.com" if Yahoo! used SIP).