Este post está escrito en el blog interno de HCI de Indra, pues mi comañero Pedro Cos, ha sacado este tema tan interesante, que me entran ganas de reflejar aquí. Su titulo era:
¿Deben verse exactamente igual la interfaz en todos los navegadores?
En el que se explica las dificultades de los maquetadores y su “pelea” con navegadores, diseños no web, la visión del clientes, todo esto de cara a dejar un diseño maquetado al pixel.
Y la contestación era la siguiente:
Bueno, esto me pasa por hablar delante de Cos, a ver cómo salgo de ésta sin que los “fronteneros” me partan las piernas
Pues sí, Cos, el título de tu entrada en este blog no debería llevar interrogantes, debería ser, bajo mi punto de vista, una afirmación, en todo caso, una pregunta retórica de la que se sabe su contestación afirmativa.
A mi entender, cuando se desarrolla cualquier diseño, y la Web no es una excepción a esto, se establecen unas serie de reglas visuales dentro de este diseño que abarcan espacios, rejillas, distancias, colores, tipografías, etc. y todo ello sujeto a una decisión en ningún caso azarosa. Son elementos que los diseñadores trabajan de forma muy intensa para que su diseño tenga y transmita armonía e imagen de marca.
Para mí está claro que debe estar presente como horizonte final que el diseño trabajado al pixel sea maquetado al pixel. Éste debe ser el objetivo máximo de la maquetación en relación, no solo al diseño, sino a la calidad del producto.
Desde el principio de Internet (comercialmente hablando) hemos tenido que convivir con la existencia de varios motores y navegadores, que al no estandarizar, no facilitan el trabajo de los maquetadores. Esta parte está clara. Y sería genial que no fuera así. El hecho de que haya desarrolladores que hacen mal su trabajo, haciendo motores de software que no siguen la estandarización, no implica que tengamos que renunciar a hacer bien el nuestro.
Ésta debería ser la máxima a al hora de enfrentarse al trabajo diario.
Alguien podría pensar “pero… ¿y el diseño líquido?”, se adapta, crece, decrece en función de parámetros externos (resolución de pantalla, ubicación del modulo, etc.). Correcto. Si bien, no por ello lo hace de forma caótica y descontrolada, si el espacio que lo separa del modulo anterior es de 5px, cuando se expande esto no debería cambiar, en muchas ocasiones nos encontramos que ese espacio pasa a ser de 7px o 9px o 23px, cuando debería mantenerse en 5px; o si la zona de color del título crece o decrece su “width”, su “height” no debería estar botando de 23px en una página en otra 37 y en otra 12… o si todos los elementos empiezan en un punto de la vertical, los siguientes deberían comenzar en el mismo sitio, y no tener que ver, en más ocasiones de lo que me gustaría, esos dientes de sierra cuando uno hace scroll….y como éste una infinidad de detalles que en conjunto, si no se controlan, y se tiene una actitud laxa ante ellos, hacen que el orden y la armonización, que tanto esfuerzo a costado a los diseñadores, se queden en el PSD.
Sí es cierto, y los diseñadores somos sensibles a ello, que al manejar ciertos parámetros y querer que funcionen en varios navegadores, nos encontramos con dificultades, pero en casi ningún caso insalvables.
Partiendo de las premisas anteriores, todos tenemos claro, que dado el tiempo de los desarrollos, las entregas y el equilibrio del esfuerzo/resultado/coste , nos ponen a todos los que trabajamos en el “front” en disposición de intentar encontrar soluciones de compromiso, especialmente entre diseñadores y maquetadores, que nos permitan llegar en tiempos y con una calidad aceptable. Y claro está, siempre en elementos que visualmente no impacten en la armonía o en la transmisión de marca o producto de dicha web.
Nada más hay que ver como están maquetados los periódicos actuales, donde las distancias, las rejillas, y los espacios son un verdadero desastre, para darse cuenta de que ciertas decisiones tomadas en pro de la facilidad de maquetación, hacen que tiren para abajo la calidad visual del producto.
En ningún caso estoy hablando de diseños que no contemplen la propia idiosincrasia del entorno donde se van a desarrollar, en este caso la Web, como ocurría allá por los años 90. Yo creo que actualmente, salvo algunos casos (desgraciadamente para todos nosotros aún los hay), los diseñadores tienen en cuenta que lo que están planteando se tiene que poder llevar a buen término por las personas que lo tienen que maquetar.
Y sí, Cos, el píxel es importante.
Popularity: 95% [?]
- BROWSE / IN TIMELINE
- « Otro mundo es posible
- » Grupo MosEisley (Muesly)
- BROWSE / IN diseño General
- « Otro mundo es posible
- » Grupo MosEisley (Muesly)
COMMENTS / 4 COMMENTS
Javier added these pithy words on May 12 08 at 11:45 pmInteresante reflexión, que lleva a dos debates.
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.
cos added these pithy words on May 21 08 at 8:29 pmQue pasa Antonio? podias haber puesto el post original, no pasa nada… es mas, te pongo el post original como contestación
.
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?
Itten added these pithy words on May 21 08 at 9:02 pmCos, genial!… no sabía muy bien qué hacer…si ponerlo o no, como no era mío….
![]()
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í.
sdbsdb added these pithy words on Jun 22 08 at 2:39 pm
SPEAK / ADD YOUR COMMENT
Comments are moderated.

