Tag Archives: layout

Sitio web de la Biblioteca Franciscana

Ahora que la web puede accederse desde una PC, una laptop, un SmartPhone o una tableta, se nos presenta una paradoja a los diseñadores: debemos creer en la estructura semántica del contenido de las páginas, pero también hay que cuidar más que nunca la presentación de la información considerando tanto al usuario como el dispositivo a usar.  Últimamente me ha llamado la atención estos sitios que aprovechan las ventajas del CSS para ajustar sus layouts dependiendo de su resolución, así que aproveché experimentar con un proyecto de rediseño web que tenía  pendiente: La Biblioteca Franciscana.

Mi solución es bastante artesanal y no tiene nada de sofisticada. Aunque hay artículos bastante completos sobre el tema, yo había leído alguna vez que tenía que ver con el viewport, y entre los resultados de mi búsqueda di con el uso del parámetro media y los CSS Media Queries. En los siguientes recursos está cómo emplear diferentes hojas de estilo dependiendo del medio:

http://css-tricks.com/6206-resolution-specific-stylesheets/

http://css-tricks.com/6731-css-media-queries/

http://www.w3.org/TR/css3-mediaqueries/

http://reference.sitepoint.com/css/mediaqueries

http://www.css3.info/preview/media-queries/

http://coding.smashingmagazine.com/2010/07/19/how-to-use-css3-media-queries-to-create-a-mobile-version-of-your-website/

http://www.thecssninja.com/css/iphone-orientation-css

En cuanto al diseño web, siempre tuve una preferencia por layouts fijos por tener un mayor control del espacio en ventana y por tomar en cuenta la resolución estándar de un usuario potencial. Nunca me había preocupado porque la información quedara bien acomodada en diferentes resoluciones; es un reto interesante conservar la estética reticular y mantener un flujo de lectura adecuado para cada resolución. Este tipo de soluciones requiere que tengamos una actitud algo quisquillosa y obsesiva, así como trabajar cada layout hasta quedar satisfechos.

Justo por el cambio de "paradigma" de fijo a adaptable, y ante una especie de "bloqueo ante la hoja en blanco", no quedaba conforme en (regresar a) maquetar primero en algún software de diseño, así que lo trabajé directo en pantalla. Un pro de esta decisión es que vas viendo "en tiempo real" como quedan las cosas en diferentes navegadores y resoluciones. Un contra es que podemos perder el control fácilmente —sobretodo si dejamos el proyecto un día o dos. Es importante hacer anotaciones en papel y documentar en las hojas de estilo para que recordemos por qué tomamos ciertas decisiones. En este proyecto, me resultaron —a mi juicio— muchas hojas de estilo y fui redundante en ciertas reglas, dejándolas en cada hoja porque no sabía como iba a verse "el final" en todas las resoluciones; algo así como "un cambio por aquí y luego ajusto por acá".

Con un layout fijo no considero útil que tengamos muchas hojas de estilo, pero dadas las múltiples resoluciones, parece ser necesario un mayor número de "enlaces". Un colega me sugirió hacer importaciones, pero al final descarté esta opción porque según hojeé, afecta el rendimiento:

http://www.stevesouders.com/blog/2009/04/09/dont-use-import/

Otro punto importante es verificar la compatibilidad de los CSS Media Queries. Originalmente estaba muy feliz —tipo the Oatmeal— porque IE se comportaba decente; pero por no leer, me llevo la sorpresa de que fuera de IE 9, simplemente no funcionan:

http://caniuse.com/css-mediaqueries

Ante esta situación, decidí dejarle un layout fijo a todos aquellos usuarios que tuvieran de IE 8 para abajo y tomando como resolución estándar 1024 px de ancho.

Luego está el asunto del iPhone y del iPad. Hay que poner una línea de código que indique qué va a pasar cuando el navegador sea Safari. Esta línea asocia la variable "ancho" empleada en el CSS Media Query con el "ancho" del iPad, iPod o iPhone —según sea el caso. Además, resulta que cuando pasamos de modo landscape a portrait, o viceversa, se hace un zoom medio raro y es posible que los textos se desplieguen de diferente tamaño a como los observamos en una computadora de escritorio. Para validar todo lo anterior está como referencia el siguiente recurso:

http://stackoverflow.com/questions/2977550/iphone-safari-css-rotation-bug

A mi me divirtió mucho esta idea de presentar el mejor layout dado el ancho del iPod, iPhone o iPad. Sin embargo, siendo sinceros y "usables", la desventaja de jugar con diferentes acomodos de la información es que rompemos con la navegación (browsing) del usuario. Cuando alguno de estos dispositivos se rota 90 grados, debido a este re-acomodo, el usuario pierde vista la información de su interés. Lo anterior es más evidente en el caso del iPod/iPhone. Cognitivamente, lo que hacemos es "resetear"  el flujo de interacción; definitivamente algo no bueno para ningún usuario. En este proyecto, la mayoría de la información es estática y aquella que podría cambiar o agregarse durante el año, estará ubicada en la parte superior de las páginas correspondientes.

Una colega me señaló que estos ajustes automáticos no siempre convenían si trabajamos en una computadora de escritorio  —o en una laptop con pantalla grande — porque quizá el re-acomodo de la información podría perjudicarnos cuando llevemos a cabo una tarea más compleja, donde trabajemos con la información proveniente de diversas ventanas. Se me hizo un punto válido; por ejemplo, yo mismo he copiado y pegado información de una página web a Word o Excel. En este tipo de situaciones, debería de haber una opción para "fijar" el layout.

Por último, no olviden visitar http://ciria.udlap.mx/franciscana/ para enterarse de qué conferencias y exposiciones habrá en dicha biblioteca. Saludos :)

Señalización en Guanajuato

Guanajuato es una ciudad mexicana patrimonio de la humanidad, la cual es muy particular debido a su topografía. A grandes rasgos la ciudad parece estar asentada en un bol, por lo que quedan casas prácticamente unas encima de otras, lo cual deriva en muchos callejones y aún más, existen túneles para movilizarse en carro.

Guanajuato Capital desde el funicular y Pípila

Ciudad de Guanajuato México

Vistas de la ciudad de Guanajuato.

Aunque los sitios turísticos son fáciles de encontrar, el municipio dispuso de un conjunto de páneles a lo largo de ciudad para orientar a sus visitantes. Me interesó y gustó mucho como está presentada la información, ya que de primera mano, al existir tanto recoveco, los turistas podrían pensar que es muy complicado caminar en la ciudad.

Señalización de Guanajuato Capital.

Señal turística en Guanajuato.

La primera característica que se me hizo muy acertada fue el contraste. Las señales tienen un color terracota (chedrón o copper redad hoc a la ciudad pero que además hace un buen contraste cromático con los textos, los cuales se presentan en color blanco y usando una fuente tipográfica de palo seco, muy limpia y legible. Los demás colores empleados (en el mapa y esquemas) también facilitan la lectura de la señal.

Cada panel está divido en cuatro partes claramente identificables. La primera corresponde al nombre del lugar donde se encuentra la persona. La alineación a la izquierda,  jerarquía tipográfica y el aire alrededor ayudan determinar que "ese texto" (el título) corresponde al nombre del lugar.

Señal en Guanajuato Capital

Lista de lugares importantes cercanos al sitio actual.

Debajo del texto correspondiente al nombre del lugar, se encuentra una lista de los lugares más cercanos. Su alineación a la izquierda resulta más conveniente que emplear una alineación centrada, ya que se arma una línea vertical imaginaria que agiliza la lectura de dicha lista. Esta lista ocupa una columna central en el panel, de forma que quedan dos pequeñas columnas, una a la izquierda y otra a la derecha. Dependiendo si se tiene que caminar hacia la izquierda o hacia la derecha, se coloca en la columna correspondiente una flecha de dirección (←,→,↑ ,↓) para cada elemento de la lista.

Se que suena bastante intuitivo, pero este tipo de detalles simples reafirman el sentido de orientación espacial.

Mapa topográfico en la señalización de Guanajuato Capital

Mapa de tipo topográfico en la señalización en Guanajuato.

Ya debajo se presenta un mapa, cuya intención es situar al usuario en el espacio físico. En español, francés e inglés, se le indica con etiquetas como "Frente a ti" y "Detrás de ti" la relación entre lo que observa en el mapa y el entorno que lo rodea. El camino principal se resalta con color amarillo, dando evidencia a las formas de éste; muy útil para entender "cuando dar la vuelta". También se muestran, mediante contraste cromático, los sitios importantes en el área incluyendo los de la lista. Además se marca el norte como símbolo estándar de orientación.

Tube map o Pipe map tipo Beck's London en Guanajuato Capital

Mapa tipo Beck's London Underground

Mapa esquemático a la Henry Beck de un recorrido en la ciudad de Guanajuato.

La cuarta y última sección de cada panel corresponde a un esquema conocido también como mapa de tubo,  idea formidable presentada por Henry Beck en los 30s. En éste también el usuario se orienta en cuatro direcciones (←,→,↑ ,↓), pero le brinda la ventaja de identificar rápidamente que lugares se encuentran conectados con respecto al camino principal y mediante qué calles. La legibilidad para ir del punto A al punto B sin duda se incrementa con este tipo de mapas. De nuevo, lo importante se contrasta mediante el color, tanto para el camino principal como los lugares importantes. Los textos tienen su mayor contraste en este sentido con la aplicación del color blanco.

Este tipo de iniciativas me gusta mucho en los casos en los que uno no desea tomar recorridos y la ciudad, como Guanajuato, es adecuada para caminarse. Así vas tomando en cuenta qué lugares vas vistando y cuáles han llamado tu atención, previa investigación en la red o bien con una guía en mano. Sólo espero que no acaben destruidos o bien, que no se les de mantenimiento y acaben siendo un elemento deteriorado y visualmente desagradable al paso de los visitantes de esta colonial y especial ciudad.

Razones para no maquetar web en Photoshop

Casi me voy de espaldas cuando leí el título que puso Elías en Isopixel: Razones por las que NO hacer un mockup con photoshop para un trabajo web. De la traducción libre que está en blog tomé los siguientes puntos:

1. Photoshop limita completamente el trabajo, no se pueden incluir enlaces, áreas “clicables” o menús. Con el papel pasa lo mismo. Lo ideal es [añadido por mi] primero hacer un planteamiento muy básico sobre el papel [/añadido por mi] y luego pasarlo a CSS/XHTML, donde representaremos lo que se hizo en papel más resto de funciones básicas como navegación, enlaces etc.

  • Si estamos hablando de una maqueta o mockup, ya desde el papel y lápiz, es buena herramienta. La idea está en maquetar el sitio, hacer una disposición de los elementos, es el pensar cómo quedarían. Justo cómo ha mencionado un alumno de Javier Cañada dentro del programa Vostok. Lo que sí, viendo una maqueta como prototipo de baja fidelidad, en Photshop es posible concentrarse en los detalles visuales, esto es, enfocarse mucho en la forma. Aunque es tardado, su ventaja podría ser el dar una mayor calidad final en el prototipo a diferencia de tomar lápiz y papel. No hay que olvidar que en el prototipeo lo relevante es obtener, de ser posible, resultados sobre aspectos de usabilidad; ahí el photoshop es un arma de dos filos, es más fácil para este caso optar por lápiz y papel o un wireframe simple. No importa si se puede "cliquear".

2. Photoshop proporciona muchas herramientas para conseguir detalles y justamente buscamos lo contrario, no queremos dar detalles concretos, solamente lo esencial. El programa nos distraerá en cosas que ahora no tocan hacer.

  • Efectivamente, pero justo se repite mi apreciación en el primer punto. ¿Qué tipo de calidad se requiere en el prototipo y con qué propósito se está realizando? Un detalle curioso es que si el proyecto lo amerita, un prototipo simple con CSS no puede competir con uno visualmente más preciso (de preferencia con una versión más simple en papel o wireframe ya evaluada).

3. La fuente de un sitio forma parte imprescindible y es muy probable que necesites cambiarla varias veces. Photoshop hace más complicado este proceso: abrir el .psd, seleccionar la fuente del lugar concreto que queremos cambiar, cambiarla, exportar a .png .jpg para poder enseñar los cambios a, por ejemplo, un cliente etc. Además de queen photoshop las letras NUNCA se comportan igual que en la web, a pesar de darle la misma fuente con las mismas características en el programa se ve de una forma y en la web de otra [añadido por mi] (nunca entendí porque pasa esto) [/añadido por mi].

  • Con respecto a la fuente, es claro que no todos los textos pueden ser arbitrarios, esto es, utilizar la fuente que quiera y luego pasarlo a imagen. Vale para ciertos encabezados y es obvio que hay que tomar en cuenta qué tanta sustitución con imagen habrá de hacerse en los textos y por qué sería conveniente tomar este tipo de decisiones. Para los textos "comunes", esas cosas no se pueden probar mejor que con texto "en vivo", que se está viendo en el browser y eso sí tiene que hacerse con CSS (referente a familia tipográfica, puntaje, interlineado y variantes).

4. Photoshop se enfoca en la producción y no en la productividad. En este primer paso se busca conseguir los puntos esenciales para crear un sitio accesible, claro etc. Luego nos preocuparemos de darle un aspecto “bonito”.

  • Eso no lo voy a negar. Si se maqueta en photoshop, cuestiones accesibilidad, navegación y usabilidad tienen que tenerse en la cabeza "en segundo plano" (como en cómputo, un proceso corriendo ahí atrás) mientras se diseña. Esto implica que no importa tanto la herramienta (photoshop o lápiz de papel) sino la integración de los conocimientos sobre diseño visual, diseño web, diseño de información, arquitectura de información, accesibilidad y usabilidad. Insisto, ¿para qué va a servir el prototipo o maqueta en cuestión?

5. Perderemos tiempo en pasar el mockup de photoshop a css/html.

  • Otra gran verdad. Llego a una conclusión rápida que este es un vicio, el cual tengo y esto casi seguro que tienen muchos que empezaron con esto de la web en los 90s cuando el ensamble de las interfaces venía en forma de tablas. Lo que creo que este punto puede ser evidente dependiendo de tu forma de "aprender web"; si desde el principio rompes con la maquetación en photoshop y te acostumbras a hacer "drafts" a partir de una lógica-de-ensamble vía CSS/HTML, entonces tu perspectiva/proceso sobre cómo ir diseñando, definitivamente cambia. La estructura mental para esta tarea cambia. Al comenzar a hacer la "integración" que menciono arriba con una maqueta hecha en photoshop, los tropiezos te enseñan a discernir cuáles áreas "no deben o tienen por qué tocarse". Pero sí es interesante ver como el cambio en el paradigma de diseño web en cosas que a gente más reciente en estos rollos (post-liberación-de-las-tablas) hace que tengan soluciones creativas que pueden pasar por obvias para ellos.

6. Con html/css podremos seguir un flujo de trabajo mucho más productivo: Hacemos el cambio, guardamos y refrescamos.

  • Esto está relacionado con el punto anterior. En ese sentido, estoy de acuerdo. Aunque una vez pasada la migración de photoshop, esas áreas "intocables" tienen que trabajarse siempre como se plantea en este punto.

7. Photoshop es poco práctico, aunque lo manejes desde hace mucho tiempo, es complicado hacer las cosas de forma simple.

  • Si es el caso de un prototipo visualmente complejo, es tardado, pero no creo que ese sea el punto general de estos siete, sino identificar quién implica a quién, si photoshop luego CSS/XHTML o primero CSS/XHTML luego CSS. Sí son dos formas de pensar/diseñar diferentes. Y también hay que recordar el contexto, el usuario y el cliente. Mis comentarios van enfocados a sitios web "usables" por no decir cuasiplanos visualmente, no tanto a esos "interactivos" ganadores de premios y llenos de factores de diseño emocional y metáforas navegacionales rebuscadas. De una u otra forma, concuerdo en que hay que obtener un equilibrio.

Y la razón por la que casi me voy de espaldas, es porque, usualmente tengo que "concretar visualmente" una maqueta en photoshop, justo como estoy diseñando algo de web en estos días. Aunque, admito que en momentos de frustración, sobre todo por el trabajo "talachero" de pasar de PSD al ensamble CSS/XHTML donde a veces suele suceder que no queda justo como "habías pensado". Un debate interesante el asunto.

PD. Ya está el foro de discusión en Isopixel al respecto.

Actualización.

CyberGus nos comparte también su opinión sobre este tema, con comentarios bien enfocados.