creo que esto te puede interesar

Saludos.

De verdad, cómo me gustaría que ese blog fuera visible!!!! Cos, hay que hacer algo con esos temas tan interesantes que se debaten ahí.

EL POST AL QUE SE REFIERE ANTONIO

http://www.minid.net/2007/12/12/a-ver-si-lo-entienden/

Cita: “Efectivamente, los sitios web deben de verse bien en todos los navegadores. Pero verse bien no tiene por qué ser verse igual. Lo que tienen que hacer es adaptarse y saber dibujarse tal y como el navegador considere más oportuno en función de las reglas de diseño especificadas.”

Cita: “Intentar que un diseño se vea igual siempre es MALA IDEA. Hay que convencerse de que no ha de ser así. Ganaras calidad de vida y satisfacción de cliente. “

Aparte de estas dos citas, en mi opinión debemos tener claro que psd/photoshop es un único fichero que como imagen se vera igual siempre independientemente del visor/navegador.

Luego la realidad es que:

* El html/css/javascript Tiene limitaciones que el photoshop no tiene

* Los tres lenguajes(html/css/javascript) son interpretados y ejecutados de forma distinta según cada navegador que tiene sus propios motores de renderización.

* Una maquetacion estricta y al píxel, hace que se pierda flexibilidad en la interfaz (Especialmente importante en proyectos con muchos idiomas, muchas combinaciones posibles de módulos, etc.)

* Una maquetacion muy estricta y al píxel puede perjudicar a otros usuarios que accedan con navegadores que no son requisito hoy (Explorer 8, firefox3, flock…) pero si lo puedan ser mañana.

* Llegar al nivel de exigencia en el que la interfaz tiene que ser exactamente igual que el psd en todos los navegadores supone más trabajo, más código, mayor peso de la interfaz, mas horas de desarrollo, mas horas de mantenimiento…, cuando en realidad no tiene ningun sentido. Corregir que en firefox se vea una caja un px o dos mas a la derecha que en Ie, no mejorara la experiencia de uso, ni transmitirá una errónea imagen de marca, ni si quiera será percibido de ninguna manera en el 99% de los casos.
Este mismo ejemplo, desde el punto de vista de desarrollo FrontEnd, obliga a localizar el porque (se mueve un px) y realizar desarrollos a medida para cada navegador, para resolver algo que no tiene sentido.

¿que opinais vosotros?

El primero, el del justo precio a la calidad. Los programadores también nos solemos cargar la accesibilidad de las maquetaciones, sobre todo cuando hay AJAX, puesto que para mantenerla tenemos que redundar toda la funcionalidad, y es muy costoso. Se pueden hacer las cosas bien, pero no con los presupuestos actuales. Si los clientes no piden maquetación al píxel y accesibilidad expresamente, sólo tenemos dos opciones: o no lo hacemos, o lo convertimos en un estándar de calidad interno, repercutiéndolo automáticamente en los precios de los desarrollos. La segunda opción únicamente es factible si todo el sector en su conjunto la aplica. No soy muy optimista a este respecto, pues no ocurre ni con la accesibilidad AA de obligado cumplimiento en webs de la Administración.

El segundo debate que plantea tu comentario es sobre la medida de la calidad en los proyectos y los propios flujos de trabajo en el desarrollo. En la mayoría de los casos, la comunicación entre departamentos o equipos es, cuanto menos, muy mejorable. La necesidad de que se completen algunas tareas críticas para poder empezar otras, cuando es mal entendida, hace mucho daño. Se dice “Diseño ya ha terminado”, por ejemplo, y los diseñadores quedan fuera de planificación en ese momento, entre otras cosas porque se los necesita en otro proyecto.
En mi opinión, algunas prácticas y principios de las metodologías ágiles de programación deberían aplicarse a los desarrollos en su conjunto, como el famoso “refactoring” continuo, las pruebas, el feedback temprano del cliente,…

Bueno, espero que hablemos de estos temas, y de muchos otros, en la Monegros BBQ Party.