Of course there should be a basis to support for other browser
like conducting a Browser Statistics like this.
http://www.w3schools.com/browsers/browsers_stats.asp
----- Original Message ----
From: Jeff Gutierrez <[EMAIL PROTECTED]>
To: Philippine Linux Users' Group (PLUG) Technical Discussion List
<[email protected]>
Sent: Tuesday, March 20, 2007 12:13:25 PM
Subject: Re: [plug] Bankard Drops Support for Firefox and Linux
I'm with you on that but the reality is standards-compliant browsers aren't the
end of the story. Technology isn't the only consideration. It's never just
"tweaking something here in there" since there are QA-related resources the
need to always be considered. A reasonable company providing consumer or
enterprise services will not deploy an application and claim to support every
browser-OS combo because it's "supposed" to just work. Everything must be
QA-ed to limit any gotchas in production.
Furthermore, customer support is also a big issue. What will their customer
support team do if someone using Opera/MacOS calls for help? It becomes a
nightmare if your company needs to support hundreds of thousands of users.
Again, it doesn't end with "just tweaks." :)
Regards,
jeff
----- Original Message ----
From: JM Ibanez <[EMAIL PROTECTED]>
To: [email protected]
Sent: Monday, March 19, 2007 12:07:47 PM
Subject: Re: [plug] Bankard Drops Support for Firefox and Linux
Jeff Gutierrez <[EMAIL PROTECTED]> writes:
> Elijah,
>
> Most often than not, explicitly restricting browser/OS support mean
> they know that other browsers and OSes exist :) The reason is mostly
> the allocation of development and QA resources. A CIO/CTO might have
> the following rationale behind the decision:
>
> 1. I only have a limited budget for software engineers and QA
> engineers, why would I allocate 10% of my resources to 1%
> (e.g. Safari, Opera, etc users) of my customers? (I use a Mac and I
> don't even use Safari.)
Note that with the advent of more standars-compliant browsers,
developers need not to create special-case HTML/CSS (i.e. separate
HTML/CSS per browser), as one can code to the standards and just fix the
quirks.
And cost? You get 100% of the market base; heck, with even a few tweaks
(e.g. coding a different stylesheet), you can even support the mobile
device market, without much additional cost.
That's the big plus that these CTOs/CIOs don't really seem to get, IMHO.
It's not really about browser-specific support as much as being
standards-compliant enough.
--
JM Ibanez
Senior Software Engineer
Orange & Bronze Software Labs, Ltd. Co.
[EMAIL PROTECTED]
http://software.orangeandbronze.com/
_________________________________________________
Philippine Linux Users' Group (PLUG) Mailing List
[email protected] (#PLUG @ irc.free.net.ph)
Read the Guidelines: http://linux.org.ph/lists
Searchable Archives: http://archives.free.net.ph
_________________________________________________
Philippine Linux Users' Group (PLUG) Mailing List
[email protected] (#PLUG @ irc.free.net.ph)
Read the Guidelines: http://linux.org.ph/lists
Searchable Archives: http://archives.free.net.ph
____________________________________________________________________________________
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html
_________________________________________________
Philippine Linux Users' Group (PLUG) Mailing List
[email protected] (#PLUG @ irc.free.net.ph)
Read the Guidelines: http://linux.org.ph/lists
Searchable Archives: http://archives.free.net.ph
