Forum Moderators: phranque
Scenario: My client buys a pricey piece of software, written in .NET, that needs a custom front-end. I'm strictly a Unix guy so they bring in a Windows developer (with some very impressive credentials I might add). So far so good.
Today I saw the final product. It doesn't work in Netscape and the developer really doesn't seem to care ("we'll they knew that this would be an IE-only implementation"). And what irks me the most is that there is no reason why it shouldn't work in Netscape. It's simply a multi-page form. All the processing - including error handling - is done on the back-end. But when you click the "NEXT" button, Netscape just does nothing. Why? One javascript command in the form that Netscape obviously has a problem with. The javascript does absolutely nothing as far as I can see. In fact the app works identical without it, which I verified by turning javascript off in IE. And furthermore the app actually does work in Netscape when you use the Enter key instead of the Next button. It's simply bad coding. Period.
And it bugs me even more because this is not the first time I've seen web applications that "require IE" unnecessarily. Either because of bugs like this, or because of developers wanting to exploit certain IE-specific technologies when the app could have easily be written without any browser- or platform-specific technologies.
No offense, but I see this too often in the Windows development camp. It's an attitude that nothing outside of Microsoft matters.
You know 99% of the time you see a Windows- or IE-only web app it could have been done just as well without those stringent requirements, and without any additional time or money spent doing so. So why then? Even if you lose just one customer for something like this, why?
Argh!
I had a friend who used to code in ASP. He used every single feature of DHTML and VB Scripting that was available at the time. His website not only didn't render properly in Netscape, it was impossible to see any content, thanks to IE specific DHTML. I pointed it out to him, but he said, "Whatever, people should not use Netscape". That was 3-4 years back, when Netscape was still popular.
We used to argue a lot about what is better ASP or PERL. He would always support ASP and would talk trash about PERL :).
IMO some people feel threatened by Netscape and they try to deny it's existance ;)
IMO some people feel threatened by Netscape and they try to deny it's existance
I agree with Moltar on the newbies issue. As a naive and newbie webmaster just 3-4 years ago I was ignorant enough to design sites for our company making full use of what looked like attractive features i.e. DHTML etc. I built the sites in Fronpage (dare I mention the name) because I understood that that was the easiest package to learn. I used the features that FP provided. Only weeks later did I accidentally learn that my new site didn't work in Netscape. When I was designing the pages FP didn't give me any flashing messages saying, "You're going wrong buddy, don't forget Netscape users, this won't work for them". (In my defence I re-did every page and now always test in Netscape. Not everybody has that luxury of time).
In the case of "experienced" designers - hey, some of them think that 1280 x 1024 is the lowest resolution anybody uses, that everybody in the world has broadband, that nobody ever needs to modify text size in the browser, that rotating swf logos are the pinnacle of cool, that white text on white background makes for good rankings in SERPS..... :-)
What makes you think they've heard of Netscape?
As much as I agree with you Jamesa, let me present the other side of the spectrum.
We develop so many sites that taking the time to deal with Netscape for each and every site turns out to be expensive. We ask our developers to code as simply as possibly so that hopefully the site will work. But if it doesn't, then that's just too bad, we don't have time to go back and fix all the sites so they work in netscape.
Similarly, we've had to code some shopping carts in javascript. We know we lose some people who aren't able to see the javascript, but on the web where there are so many variants, you can't win them all. So we always try to cater to the majority, and if we have to lose a few sales here and there for the sake of efficiency, we're okay with that.
Since there are only a small number of themes/purposes on the web, it is only a question of knowing what works from experience. Then you apply that knowledge to new projects. The best time to catch errors is *during* development, not going back to fix them. By that time, some other whizbang *feature* that the developer has fallen in love with has boxed you in. It helps to keep on hammering on the developer that the project is not an expression of his creativity, but a means to an end. Usually profit. It also helps to have a project manager who is at least as, if not more technically proficient than those under their tutelage. The more hard problems he solves for them, the more likely they will listen. Having a *bible* of coding, usability and technical standards that is required reading for all developers also helps in resolving discussions of how cool a proposed feature is. If it's not in the book, it doesn't happen.
Finally, once you get some developers you can work with, keep them around. They are much more valuable than new developers you have to break in all over again.
++++
Function first, form lower down the ladder.
[Just hope I don't ever see a sign on my local supermarket stating I need to be wearing Levi's and Nikes to spend my money in their store.]
anchordesk
With me, if NN4 doesn't see my stylized text and colors I usually don't care as long as the content is accessible. But failing to close a table tag thus rendering whole whole page invisible in Netscape is another. I have a friend who must of got tired of the "you know it's broken Netscape" phone calls - at least now he sanity-checks his work and has even asked a few times about where to get a cheap Mac :).
But yea, I admit there could be somewhat of a learning curve initially. At some point in time you probably needed to have been into testing cross-browser and platform to know where the danger areas are. But with HTML especially usually all it takes is valid (but not necessarily W3C validated) code.