Tzek Blog de Diseño

Las revistas de chismes del espectáculo son popularmente adictivas. En México existe una gran circulación de este tipo magazines, siendo TV y Novelas una de las más representativas y con más trayectoria. Una característica distintiva de éstas es sin duda la portada, la cual tiene que gritar para llamar la atención de los lectores potenciales. Y que mejor manera de hacerlo con textos en caja alta, colores vibrantes, falta de aire en la composición y enunciados estridentes.

Portada de TV y Novelas

Lo importante tiene que aparecer en la portada. Pero, ¿qué es lo importante? ¿quién lo determina? Quizá a muchos nos cruza por la cabeza la palabra editor y más aún, podríamos determinar que “él decide, él dirige, y punto”.

Si hacemos la analogía con la Web, la portada vendría siendo la página de inicio. ¿Cuáles son las respuestas a las mismas preguntas? El editor o webmaster sería quien determina qué, en qué orden y dónde van las cosas ¿no? Sin embargo, la Web es una de las entidades donde el poder del usuario final tiene más peso para lograr el éxito ¿o no?

Supongamos que el webmaster es en sí el “diseñador web”: el que se encarga no sólo del mantenimiento sino que ha participado tiempo atrás, tanto en la estructura como en el layout. Este caso es fácilmente visible en freelancing o en trabajos donde un equipo pequeño (incluso de una o dos personas) se encarga de un sitio completo.

Pues bien, la premisa del “lado del diseñador” sería “poseo los conocimientos para determinar cómo indentificar la estructura del sitio y la interfaz de este”; ergo, “aquí está el sitio propuesto, úsese”. Sin embargo, existe una contraparte: los stakeholders o las personas interesadas (en el sitio). No estamos hablando del usuario final. Entre estas personas puede estar quien encarga el sitio (contratista), el jefe, un comité que determina qué información se estará presentando, etc. Lo “sabroso” se da cuando la mente (y el ego, por qué no) del diseñador se encuentra con la de los stakeholders para determinar, entre otras cosas, qué incluye y cómo debe ser la página de inicio, la “gran carta de presentación”.

En ese cruce de “aires”, cual formación de tornado, suele darse un “Síndrome de portada TV y Novelas” en el index o página de inicio, el cual corrompe terriblemente la posible propuesta óptima de interfaz web por parte del diseñador. Todo es importante y todo debe resaltar. Claro, las opiniones son muy sesgadas dependiendo del stakeholder en cuestión. Justo ahí es donde entra el grado de influencia de cada uno de ellos; sin embargo, todos quieren tener visible el nicho de información de su interés.

La “homepage TV y Novelas”, le pone al usuario todo a la mano, eso debe ser bueno. Se pueden encontrar banners animados en flash y muchos botones o imágenes por todas partes, textos de gran tamaño, menús desplegables con muchas pero muchas opciones, más de 5 logotipos (por eso de mostrar que el sitio es importante), etc. 

El ying-yang de este asunto puede describirse así: el diseñador web no preparó la estructura (navegacional y visual) del sitio “a prueba de balas” y tampoco se preocupó por sensibilizar a los stakeholders hacia una cultura de la usabilidad y fucionalidad (¿qué queremos con el sitio? ¿para qué servirá?); por otro lado, las personas interesadas sí quitan autoridad al diseñador (aunque se les explique), debido a que lo “importante” es lo importante y tiene que estar en el index, cuanto más opciones, mejor. No se trata de armar “pleito”, ni de ver quién tiene la razón, sino de darse cuenta que un sitio web va más allá de “presentar información”, porque en la mayoría de las veces están ahí para usarse.

¿Y a qué lleva el último punto? La respuesta es simple: cuando los usuarios usan el sitio (valga la redundancia), se topan con una página de inicio saturada, con demasiada información, muchas opciones para seguir navegando y que pobremente responde a sus necesidades. Después, cuando llega la retroalimentación, sobretodo en esas situaciones donde se apremia “la calidad en el servicio”, los stakeholders se dan cuenta que la página de inicio y todo el sitio, están mal.  Como parte de este síndrome entra su desesperación por no quedar mal y demostrar que sí hay aptitud, que se tiene un sitio web bueno, usable y relevante. Es posible que en este punto se recurra de nuevo al diseñador para que “corrija” tales desperfectos.

El síndrome puede evitarse, pero requiere de la participación de los stakeholders y que sepan hasta dónde llega su autoridad, dejando lo pertinente al diseñador web, que en teoría es el experto y sabe lo que conviene pensando en los usuarios del sitio. Lo complicado está que se involucran aspectos emocionales (en particular de egocentrismo) tanto en el diseñador como en las personas interesadas, por lo que “sanar” es más difícil de lo que parece.

El diseñador para ponerse frío, hay que reconocerlo, debe hacer su chamba, documentar en la medida de lo posible (wireframes y blueprints, esquemas y diagramas, todo lo válido para comunicar por qué se hacen las cosas) y ser claro ante los stakeholders sobre lo que se pensó, lo que se tiene, lo que puede ser y lo que se podría hacer. 

¿Complicado o díficil? Sí. Pero es parte del show ¿o no?

A principios de la década, a mi juicio, uno de los mejores recursos para los interesados en el diseño y desarrollo web era Webmonkey, gracias a sus buenos tutoriales y otros artículos. Entre los primeros se encuentra el “Tutorial de Arquitectura de Información Web“.

Si necesitas conocer qué es y cómo se aplica este concepto en un sitio web, te recomiendo echarle un vistazo a este tutorial; su contenido es presentado con claridad, cubriendo los puntos necesarios en forma concisa.

Liga:
http://www.webmonkey.com/tutorial/Information_Architecture_Tutorial

¡Qué bien que Webmonkey está de vuelta! Un portal dónde se aplicaba bien el concepto de que el contenido es el rey. Espero que en esta versión se repita la historia.

Francesco Mugnai ha puesto en su blog una lista de 26 sistemas administradores de contenido para votar. Aunque en los resultados Wordpress va ganando con el 27.5%, de verdad que hay opciones para todos: basados en php, coldfusion, java, dependiendo si quieres algo personal o empresarial, entre otros factores.

Aunque el post que recién escribió Armando Sosa se llama “Cuando los estándares nos alcancen“, en sí puede tomarse como una reflexión, aunque personal, sobre la interacción, servicios y tecnología que tenemos hoy y sus implicaciones en el mañana. 

Muy ameno, espero puedan darse una vuelta para leerlo.

Por cierto, Sosa estará en un congreso llamado Mexico Web 2.0, donde vienen autoridades-practicantes del desarrollo web, estándares y servicios 2.0. 

Dado el post anterior que me dejó reflexionando, sobre cómo aprender a diseñar páginas web, comento con un colega: 

No estoy seguro si comenzar un curso de diseño web deba incluir manejo de tablas. Sino empezar directo con CSS.

Es como aprender a montar bicicleta. Puedes aprender con “rueditas” o sin ellas. Al final es lo mismo, acabas sabiendo como montar bicicleta.

Nota contextual: El “pecsi” tiene que ver con la premisa de que a los diseñadores les cuesta trabajo aprender “código”… Jum. ¿Quién habrá inventado y diseminado esta idea?

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. 

Directo desde Ateneu Popular, Guepmascle, nos ofrece una cheat sheet o chuleta de conceptos básicos de CSS. Recomendable cuando se está empezando con esto de los CSS.

Acceder en: 
http://www.ateneupopular.com/2008/05/22/chuleta-css-conceptos-basicos

Como diseñadores de información, interacción o de interfaces en general empleamos términos como usabilidad o accesibilidad. No dudo que demos importancia a estos aspectos y consideremos que sí los aplicamos como parte de nuestros diseños, ¿pero realmente son parte de nuestro proceso? ¿estamos sensibles a ellos? Por ejemplo, diseñamos sitios web “para nuestros ojos” como diría Costa, en este caso, nuestros ojos occidentales. ¿Qué pasaría si te pidieran el diseñar la misma información también para Arabia Saudita? ¿Sería diferente el proceso? ¿Seguro? ¿Podrías afirmar por qué?

El experimento va así: entrar al sitio de la KAUST, darle una escaneada rápida al homepage y de ahí identificar qué fue relevante para nuestros ojos. Ahora, buscar la opción “en árabe”. ¿cómo se siente ese cambio? Podemos regresar y repetir la operación un par de veces… ¿se siente raro? ¿no normal? ¿se te ha cruzado en la cabeza términos como “curioso” o “por qué hacen X o Y cosa? Página de inicio de KAUST, versión occidental:

Página de inicio de Kaust, versión árabe:

Acercamiento de esta página:

• Como diseñadores de identidad, ¿podrías decir por qué es relevante que primero se lea la marca en extenso y luego el imagotipo? ¿que no da igual poner KAUST y luego el nombre largo? Si observamos la versión en árabe, no crea mayo conflicto, al contrario, entiendes KAUST y te quedas entonces con esa marca en la cabeza, aunque no sepamos bien que significa.
• Lo mismo sucede con la foto de del profesor. Si estuviéramos diseñando un portal similar, ¿por qué es importante que aparezca la foto primero? ¿estamos conscientes de por qué tomamos ese tipo de decisiones?
• ¿El menú debe ir a la derecha o a la izquierda? En los sitios web actuales, fuera de nuestra “occidentalidad” de leer de izquierda a derecha y de arriba hacia abajo, encontramos menús del lado derecho o izquierdo. En este caso el “What’s KAUST?” es quien determina la prioridad de lectura de este chunk de información… ¿cuántas veces sabemos que priorizamos contenido en sitios web de forma adecuada? Si fuera un menú común y corriente, da igual que sea derecha o izquierda..?

Parece que pasar de español a árabe consiste en un “flipeo” del layout… Ok. Puede ser. Pero si vemos el sitio en árabe, ¿no es curioso como rompe con nuestra “normalidad” de cómo diseñar para occidente? 

elBarbón! de NiceFuckingGraphics ha publicado su Top 100 Blogs de Diseño. Para checar, curiosar y tenerla a la mano, lista para book-markear…

URL: http://nicefuckinggraphics.blogspot.com/2008/04/top-100-blogs-de-diseo-en-espaol.html