El arte de cotizar: inlcluye Internet Explorer como elemento adicional

Leyendo este articulo me encontre con este comentario:

AI escribió:

Y por ese tipo de situaciones, no considero extra decir que es valido especificar en una cotizacion y contrato, donde se probara el proyecto que desarrollaremos. De esta forma, crearemos conciencia del danho que ocasiono Internet Explorer al no respetar los estandares y evitaremos que todo el peso de eso recaiga solo en el desarrollador, como conozco tantos casos. Si dejamos "abierto" el tema del soporte, se presta para este tipo de situaciones, donde el que paga los platos rotos es unicamente el desarrollador.

Si ustedes realizan cotizaciones para proyectos, recuerden que deben incluir como un elemento adicional soporte para IE6 y para IE7, y ya de su cliente final dependera como consigue mas dinero para seguir soportando versiones viejas de IE, o de plano se une a nosotros y decide ya no soportarlo por los gastos que implica.

Tenemos que ser practicos, la vieja escuela decia: "es que tu web debe ser bien vista donde sea", la realidad del mundo actual, te dicta que debes seguir estandares, pero eso no es ninguna garantia de que se vera bien un sitio en todas partes. Debemos siempre dicernir entre lo que es incluido por default y lo que tendra un costo extra soportarlo.

Ejemplo, una empresa refresquera pide un sitio web, debemos estimar el esfuerzo necesario para hacer un sitio que se vea bien en Chrome, Firefox e Internet Explorer 9 o superior. Aqui el soporte crossbrowser es "minimo" pues no se requieren muchos "hacks" entre los diferentes navegadores, por lo tanto practicamente todo el esfuerzo de desarrollo se enfoca en la logica de negocios. Sin embargo, si hablamos de IE8(el menos malo de los malos), IE7 e IE6 la cosa cambia, debemos revisar en nuestros requerimientos que funcionalidad requeriria "hacks" para funcionar en versiones viejas y cobrarlo, el no ser preciso en las cotizaciones se presta para que el unico pagano de esas lagunas en las cotizaciones / contratos, sea el desarrollador.

Dependiendo de la funcionalidad que ocupes, soportar versiones viejas de IE, puede aumentar el presupuesto entre un 10% o un 50% de tu proyecto.(realmente no es un dato preciso, simplemente ilustrativo)

A partir de ahora, cuando estes por vender un proyecto web, recuerda incluir como elemento adicional, el soporte para versiones viejas de IE, explica/evangeliza el impacto en esfuerzo, que tiene soportarlo, y que sea el cliente sea el que decida si lo paga o no. Si es un cliente que ya tiene una web, trata de revisar estadisticas de sus visitantes para ver que tan demandante, es en su web, la cantidad de usuarios con versiones viejas de IE.

Tomar la decision de seguir soportando versiones viejas de IE, es una decision conjunta, pero si es requisito soportarlo, quien vende el proyecto, tiene la responsabilidad de vender eso, como lo que es, un esfuerzo extra, para evitar que sea el desarrollador quien pague, con horas extras, ese soporte.

Lamentablemente muchas de las agencias o en los empleos en que he trabajado, estan de la vieja escuela en mexico, y claro el que paga es el desarrollador, muchas empresas grandes en sus desarrollos quieren que su desarrollo se vea en IE6, IE7, IE8 y demas exploradores dentro de su intranet que por "seguridad" de sistemas no actualizan sus navegadores, cosa que nunca he entendido, incluso en los banners de flash he trabajado bajo el CS3 imaginense, y como en tu opinion si es una renovacion de una web ver que tan estadisticamente que tipo de navegador entran a tu web y aunque tengas argumentos para que ese pequeño porcentaje de menos de 4% o menos no vale la pena programar en ese navegador se omite por ser "potenciales clientes"

Saludos desde méxico

joshuavw escribió:

Soy mexicano, trabajando para clientes americanos desde hace 10 anhos. Ahora vivo en USA, tambien algunas veces me ha tocado trabajar con clientes mexicanos. Las diferencias culturales se notan, mientras el americano entiende que el desarrollo web cuesta, y que el soporte para mas navegadores en muchos casos tiene impacto $$$ en Mexico se juega mas al papel de que a los clientes les gusta asumir que por default sera una Web Perfecta(asumen y asumen muchas cosas y el desarrollador lo permite), y todo lo no "perfecto" corre a cargo del desarrollador.

Pero por eso creamos este tipo de temas, de nosotros, como desarrolladores de latam, depende cambiar esos paradigmas, tenemos que fomentar esa educacion por entender el desarrollo web y sus variantes, muchas veces el problema no son los clientes, sino nosotros mismos que agachamos la cabeza y preferimos trabajar 3 horas extras en un hack de IE, en vez de levantar la voz y decir, estimamos 8 horas para este modulo, las 3 horas que se ocupan para el hack de IE, deben estar en un plan para que se hagan manhana. (y al estar en un plan, el cliente pago por ellas y no hay necesidad alguna de horas extras "gratis")

Complementando, sobre esto:

escribió:

El punto de mi tema se apega perfecto a tu caso, creo que es totalmente valido que para ellos ese 4% sea importante, y eso resume el punto al que iba en mi tema. La agencia donde trabajaste debio darle dos cotizaciones, la primera sin incluir versiones viejas de IE, y la segunda incluyendolas, asi tangiblemente, ellos sabran cuanto les$$$ cuesta quedar bien con esos clientes potenciales.

Aqui como a ellos no les impacta en dinero, ellos exigen todo lo que puedan, y pues como es gratis, de ser por ellos hasta te exigian soporte a IE5 para no perder al potencial abuelito comprador. Por eso no debemos dejar ambigua la parte a la que nos enfocaremos y especificar cuanto costara ampliar nuestro foco, para que ellos decidan cuanto quieren invertir.

Yo siempre menciono esto en los cursos y le agrego algo más. No peleen con palabras y sentimientos, sino con números duros. Es muy fácil demostrar que soportar IE6 e IE7 no vale la pena. Un simple viaje a Google Analytics lo demuestra.

De ahí, justificar una subida en el precio es fácil, realmente fácil. En ocasiones creo que la razón por la que muchos siguen soportando IE6/7 es el terror de hablarle a los jefes.

Yo en mis contratos coloco una cláusula de compatibilidad con IE7 e IE8 (IE6 no lo considero por defecto y también genera un gasto extra, independientemente de IE7 e IE8). Sin embargo, creo que hay que establecer también una diferencia entre hacer un sitio "compatible con" o que simplemente pueda verse en viejos navegadores. Usando Progressive Enhancement es perfectamente factible que el sitio pueda verse en navegadores antiguos anque eso no implique que deba verse "igual en todos los navegadores", que es realmente donde está el esfuerzo extra. Eso sin tener en cuenta que para llenar los "gaps" apunta de polyfills de javascript estamos comprometiendo tiempos de descarga y memoria sobre un sistema que ya está bastante comprometido en recursos.

Estás haciendo el gran trabajo, Fricky, por eso sigues siendo Presidente. Ese es el camino.

Ahora hay un problema. Progressive enhancement no es la cosa más compatible del mundo con Responsive Design. Y combinarlos cada vez es más jodido.

Yo por otro lado creo que, si usas IE6/7/8, te mereces todos los polyfills y JS que te van a poner encima.

Más que con Responsive Design, yo diría que Progressive Enhancement es un problema con HTML5 y CSS3. No es casualidad que la tendencia hoy día sea Graceful Degradation, es apenas lógico si tenermos en cuenta la falta real de compatibilidad hacia navegadores antiguos.
Lo que yo procuro es buscar el punto medio, donde puedas dar una experiencia básica (pero lo suficiemente decente como para que no sea odiosa) en esos navegadores y puedas aprovechar las ventajas que CSS3 o HTML5 te ofrece en navegadores modernos. En términos sencillos, hacer lo suficiente como para que -al menos hasta IE8- tengas una experiencia medianamente decente, sin que ello implique hacer virguerías.
El tema de los polyfills yo lo trato más desde el pundo de vista de la funcionalidad. Es decir, está bien usar un polyfill para curbir algo que afecta directamente al modo como funciona el sitio, pero no si simplemente quieres agregar box-shadow a un elemento. A menos, claro, que el cliente así lo requiera y esté dispuesto a pagar por ello.

The Fricky! escribió:

Me gusta mucho esa filosofía. No lo había pensado. La usaré a partir de ahora en los cursos.

Hablando de polyfills, yo trabajo con el template de html5boilerplate y ese incluye modernizr.js que se supone corrije algunos de los errores comunes de IE.

Pero en si seria bueno tal vez por ahi trabajar en un tema que recoletara los polyfills mas importantes que se andan moviendo por el mercado web.

De hecho existe una recopilación de polyfills en Github: HTML5 Cross Browser Polyfills. No están seleccionados por su popularidad, es más una recopilación de recursos, pero está muy bien.
También vale la pena darle un vistazo a la presentación de Addy Osmany sobre log polyfills: Polyfilling The HTML5 Gaps With JavaScript, tanto por los slides de su presentación como por los links que aparecen en el artículo