Responsive Web Design – One Web to Rule them All

La web es un mundo en constante movimiento, donde los cambios se dan vertiginosamente y en el que mantener el espíritu de siempre aprendiz es vital para mantenerse al ritmo.

La aparición del primer iPhone, y con él la era de los smartphones con navegadores de verdad fue una nueva vuelta de tuerca en una web donde nuestro querido CSS 2.1 y su atributo “media” (que nos permite aplicar una hoja de estilos específica para impresión, “handsets”, etc.) no pudo responder a los retos que se le planteaban, básicamente porque los fabricantes hacían poco o ningún esfuerzo por implementarlo correctamente.

Los dispositivos comenzaron a salir y el reto se hacía cada vez mayor: ¿Cómo adaptar nuestro sitio para que se vea bien en la mayor cantidad de dispositivos posibles? ¿Hago un sitio fijo y que cada quién lo vea como pueda? ¿Un layout líquido/elástico que se adapte a las distintas pantallas y resoluciones? ¿Mejor un diseño para cada dispositivo (móvil, tablet, monitor) y redirigir al que corresponda? Sí, las cosas se complicaron, y aún se complican.

En mayo de 2010, Ethan Marcotte escribió un artículo en A List Apart (y más tarde un libro con el mismo nombre que no me canso de recomendar) sobre lo que llamó: Responsive Web Design, inspirado por una tendencia de la arquitectura moderna, conocida como responsive architecture y el, en mi opinión, brillante artículo escrito en el 2000 por John Allsopp: A Dao of Web Design. En él presenta su propuesta de crear un sistema que permita adaptar nuestro sitio a los distintos dispositivos en los que será visualizado. Para ello, Ethan hace uso de tres técnicas:

1. Fluid Grids (Cuadrículas fluídas/líquidas).
2. Fluid Images (Imágenes fluídas/líquidas).
3. Media Queries.

La intención detrás del Responsive Design no es simplemente crear un sitio que pueda ser visto correctamente independientemente del dispositivo sino que además pueda ser también accesible, legible y usable en diferentes ambientes, sobre todo en un mundo donde la proliferación de tamaños, resoluciones y modos de uso aumenta cada vez más haciendo imposible predecir desde dónde será leída la información de nuestro sitio y por tanto crear una interfaz para cada caso una tarea insostenible o, cuando menos, sumamente costosa.

Por supuesto, a medida que aumentó la adopción de CSS3, RWD ha ido creciendo en popularidad, saltando incluso del campo de CSS hacia Javascript, para superar las dificultades que se han ido presentando en la implementación de un sitio responsivo.

En los siguientes artículos de esta serie profundizaremos en las técnicas de CSS que conforman el Responsive Web Design, al final hablaremos también de sus ventajas, sus desventajas, la forma óptima de aplicarlo y veremos luego algunos recursos que la comunidad frontend ha desarrollado a su alrededor.

Nota: La imagen que encabeza este post es tomada de Beginners Intro: Considering Responsive Web Design, por Harry Wiseman para Inspiration Feed.

Repensando la web móvil

Es verdad que la aparición de los smartphones y luego las tablets nos han hecho cambiar la forma como usuarios y desarrolladores miran la web. Un cambio que, de la mano con las redes sociales nos ha invadido de forma, a la vez, avasallante y emocionante.

HTML5, CSS3, Responsive Web, jQuery mobile, Sencha Touch, Titanium, Phonegapp, etc. dibujan un mundo nuevo y muy interesante para diseñadores y desarrolladores, no sólo por darnos un nuevo mercado sino por las características particulares que éste tiene, obligándonos a adaptarnos a las nuevas tendencias.

Sin embargo hay cosas que no han cambiado demasiado. Aún estamos pensando el mundo al revés –según creo– pasando del escritorio, de la “Web Completa” a los móviles, pensando en términos de Gracefull Degradation en vez de Progressive Enhancement. Esto, lejos de ser inocuo para la web, implica ciertos problemas, retos que aún no hemos superado porque enfrentar estos retos implica un cambio drástico, de 180º, en el modo como vemos y como desarrollamos la web del presente y perfilamos la web del futuro.

Hace ya casi un año, Bryan Rieger, nos mostró las implicaciones que este modo de asumir el mundo móvil trae consigo y la necesidad de repensar el modo como decidimos enfrentarnos a ella en su presentación Rethinking the Mobile Web, a pragmatic look at creating an accesible and inclusive mobile experience. Una verdadera joya que vale cada una de las 140 páginas que contiene.

Un material que sin duda nos pone a pensar en qué es realmente la web móvil y en cómo incluir en ella todo un universo de smartphones que, si bien no son iPhones o Androids, son, no sólo más numerosos sino también dignos de ser parte de este modo de hacer web (y claro, también pertenecen a potenciales clientes).

Acá les dejo la presentación, espero que la disfruten tanto como lo hice yo.

Bryan Rieger es diseñador web, quien junto a su pareja Stephanie conforma Yiibu, una consultora sobre experiencia de usuario localizada en Londres, Inglaterra.

Consejos para Enfrentar un Proyecto Web – Del Mockup al CSS

Nota: Este post es parte de una serie titulada Consejos para Enfrentar un Proyecto Web y viene después de Consideraciones Generales.

Update: Hay una edición de este post en Cristalab: Cómo afrontar un proyecto web. Parte 1: Del Mockup al CSS.

En esta ocasión, trataremos tres partes del proceso que son fundamentales en el desarrollo de nuestro proyecto web. En este caso hablamos del diseño de un sitio web en XHTML, pero parte de las consideraciones escritas aquí valen también para otro tipo de proyectos/tecnologías.

1. Mockup: Piensa, Intenta, Borra, Piensa, Intenta de Nuevo.

   La ventaja de hacer mockups antes de comenzar a maquetar es que te permite experimentar diferentes estructuras para el sitio, buscar las fórmulas que funcionen mejor en cuanto a usabilidad, accesibilidad y legibilidad.
   Al contrario de lo que algunos piensan, el momento de la planificación inicial es uno de los más críticos en el proceso de realización puesto que mientras más tiempo inviertas en organizar tu sitio/aplicación, menos tiempo gastarás haciendo modificaciones de última hora o resolviendo imprevistos, como que de repente a tu cliente se le ocurra que quiere agregar un link a la cuenta de Twitter que su hijo le abrió el día anterior.
   Este es entonces el momento perfecto para hacer lo que se conoce como “análisis de software”. Pensar en cómo será el producto antes de comenzar a crearlo es avanzar el 50% del trabajo, sin haber escrito una línea.

2. Mientras Más Propuestas, Más Problemas.

   Aunque a primera vista te parezca que darle varias opciones a tu cliente te hará quedar como un genio y es -en sí- una gran idea, realmente no lo es, al contrario es una idea pésima. A excepción de unos muy pocos clientes, que debes atesorar el resto de tu vida, que tienen una cierta idea de lo que significa tener presencia en la web y cómo eso puede reportarles beneficios reales y -sobre todo- que tengan una idea más o menos clara de lo que realmente desean, la mayoría de los clientes son como niños que comienzan a entrar en el mar: No tienen real idea de lo que están haciendo y de cuánto puede influir el diseño en el éxito o fracaso de su sitio.
   Siempre recordaré a aquel cliente que una vez me dijo que quería tener muchas propuestas, como cuando compra un automóvil, que puede escojer entre una amplia gama. Tuve que explicarle que en su caso sería como pedir tener una amplia gama de automóviles hechos a mano para poder escoger: ninguna empresa hace eso porque la pérdida sería mayor a la ganancia.
   Lo que suele ocurrir la mayoría de las veces es que presentas una serie de diseños diferentes y la selección final es la combinación de partes de un diseño con partes de otro y así hasta el infinito. En otras palabras: más propuestas sólo aumentarían la indecisión del cliente y, por un lado atrasarían el proyecto (porque necesitaría más tiempo para decidirse), mientras por el otro hay más posibilidades de que la escogencia final sea un diseño completamente diferente, una especie de Frankenstein web hecho con piezas de tu propuesta.
   ¿Solución? Presenta dos -máximo tres- propuestas y prepárate.

3. Maqueta de Forma General y Flexible.

   Tu mejor arma es pensar fuera de la caja, ir más allá que cobrarle por hacer ese pequeño portal de lindos colores y grandes imágenes. Si tu cliente te resulta fiel, querrá que te encargues de cosas como el mantenimiento del sitio o de sus futuros rediseños. Si no quieres que estas futuras tareas se conviertan en un verdadero dolor de cabeza, lo mejor es buscar una forma de maquetar (y con maquetar me refiero a (X)HTML) de tal manera que los futuros cambios no impliquen ninguna o la menor cantidad posible de cambios en la estructura del sitio. No importa lo fácil o difícil que resulte cambiar o no una o dos etiquetas, si la estructura está bien hecha ¿por qué deberías cambiarla? Lo ideal siempre sería que un cambio en el diseño pueda realizarse con CSS y/o cambiando las imágenes correspondientes, sin necesidad de tener que repensar sobre la estructura o la legibilidad de tu sitio.
   Por otro lado, mantener una estructura general y flexible siempre te permitirá crear plantillas/snippets que funcionen en casi todos tus proyectos, haciendo más eficiente la reusabilidad.

4. Semántica, Estándares, Validaciones.

   Sí, quizá yo sea un purista (aunque espero por el FSM que no sea así), pero al menos en los dos primeros casos me parece que lo mejor es apegarse a la norma; en el tercero acepto cierta flexibilidad. Aún recuerdo a Freddie diciendo una gran verdad: Si un sitio cumple su objetivo (generar dinero) ¿Qué demonios importa si el sitio es válido?
   No puedo decir que Freddie no tenga razón, después de todo, es un negocio de lo que hablamos, pero también es cierto que un etiquetado y un css válido permiten una interpretación más fiel en los navegadores y ayudan a conservarlos en el tiempo. Personalmente me preocupo por la validación pero dando prioridad a la funcionalidad. Sé que hay gente que piensa que no sirve de nada, incluso he oído gente que cuestiona los estándares por ser impuestos por la W3C, pero en ese caso, lo dejo a criterio de cada quien. si te funciona, está bien por mí, pero, por amor a lo más sagrado, ¡deja de maquetar con tablas!
   Ahora, sobre la semántica y los estándares, creo que nisiquiera merece la pena la discusión. Creo que es más que obvio que estas dos herramientas juntas son prioridad sobre todo en orden al SEO y la accesibilidad.

   Personalmente, procuro maquetar siempre bajo XHTML Strict, lo que me ayuda a descubrir posibles errores (como que olvide cerrar una etiqueta o colocar un “alt” a una imagen) y  CSS2.1.

5. Inspírate en Quienes Quieras, No te Copies de Nadie

   Nadie quiere ser reconocido por robarse el trabajo de otros, aunque de un tiempo a esta parte parece estar de moda creer que es válido tomar cualquier cosa de internet y hacer creer que son propias, o peor aún, pedir a otros que “nos regalen” la solución a nuestros problemas, como si preguntar en un foro equivaliese a encontrar una manada de esclavos que hagan el trabajo por el que yo voy a cobrar. No, nadie quiere ser reconocido de esa forma.
   Sin embargo, es perfectamente válido mirar el trabajo de otros, ver cómo solucionan los retos que sus proyectos representan, decubrir nuevas paletas de colores o formas ingeniosas de lidiar con el proyecto. Nadie puede acusarte de inspirarte, pero copiarte sólo te dará mala fama en internet (de eso puedes estar seguro) y, en algunos casos, hasta acarrearte problemas legales.

6. Usa un CSS Reseter

   Todos los que hemos maquetado sitios sabemos el dolor de cabeza que significan los navegadores y sus interpretaciones particulares del CSS, por lo que un Reseter que nos permita partir de un punto en común resulta un gran aliado a la hora de solucionar problemas con esto. No siginifica que todos los problemas de modelo de caja quedarán resueltos (el trabajo no puede ser tan fácil), pero sí que ayuda mucho a resolver al menos los más comunes.
   Aquí veo venir la pregunta obvia: ¿Cuál reseter usar? Hay cientos en internet. Lo mejor que puedo hacer es hablar de mi experiencia: Comenzar usando uno relativamente general y luego irlo personalizando de modo que funcione de la mejor forma posible para tus proyectos. Algunos de los más populares (que conozco) son el Tripoli Reset (en este artículo de Daniblog se explica muy bien y en español), el CSS Reset de Eric Meyer y luego, frameworks CSS como 960, YUI o el muy popular Blueprint.

   ¿Por qué personalizarlo? No es que sea obligatorio, pero quizá haya cosas que no te gusten del Reseter que selecionaste (como que quite el “bold” a la etiqueta “strong” o que elimine las viñetas de las listas), si ese es el caso, bien puedes irlo ajustando a tus necesidades y forma de trabajar.

7. Ordena y Comenta tu CSS

   Hay pocas cosas tan molestas como encontrarse un código sin comentarios que te obliga a leerlo todo para entender por dónde van los tiros. El CSS (aunque no es código) no es la excepción. Escribir los estilos como se te vayan ocurriendo sólo te asegurará dolores de cabeza al tratar de arreglar algo después de haber cerrado el archivo o -peor aún- a la hora de hacer un rediseño.
   Es por eso que son tan importantes los comentarios como el orden en que se escriben los estilos (Recuerda que los estilos son en cascada, es decir, un estilo se sobreescribe con el siguiente en el orden en que aparecen en el CSS). No tienen que ser extensos comentarios explicativos, puede ser simplemente para separar el código. Yo suelo dividir mi CSS de esta manera:

   1. Reseter
   2. Etiquetas
   3. Layout (Estructura General del Sitio)
   4. Elementos (Los elementos internos del Header, el Contenido, el Footer…)
   5. Clases (Que no están necesariamente vinculadas con una parte específica del documento)

   En cada división coloco un comentario para localizarlas más fácilmente. Hay formas más elaboradas para hacer esto, pero yo prefiero cosas sencillas y efectivas. Lo realmente importante es que sea un documento legible y que evite tener que estudiar en el MIT para poder hacer cambios al CSS

8. ¿Progressive Enhancement (Mejora Progresiva) o Graceful Degradation (Degradación Agraciada?)?

   Otra de esas discusiones eternas con argumentos válidos de cada lado. Personalmente soy partidario del Progressive Enhancement, pero una vez más digo que no hay que cerrarse a diferentes perspectivas. Por lo tanto, mi consejo es evaluar qué es mejor para cada proyecto y utilizar la técnica que resulte más efectiva para cada caso. Esto sobre todo es cierto cuando se trata de rediseñar un sitio, puesto que te encuentras frente a algo que ya ha hecho otro (o tú mismo) desde una de las dos perspectivas. Si me permites el consejo, dale prioridad al Progressive Enhancement sobre todo si vas a construir el sitio desde cero.

Bien, creo que con esto tenemos bastante, como siempre, hay cosas que se quedan en el tintero y cosa que podrían profundizarse más, pero este artículo sería interminable y no es la intención. Sería de gran ayuda leer sus impresiones y críticas, además de nutrirnos todos con sus experiencias.

En nuestro próximo encuentro, charlaremos acerca de Javascript.

Etiquetas Technorati: diseño, arquitectura web, progressive enhancement, proyecto web, css, xhtml, mockup

Consejos para Enfrentar un Proyecto Web – Consideraciones Generales

Nota: Este post es parte de una serie titulada Consejos para Enfrentar un Proyecto Web y viene después de Intro.
Bien, comencemos con consideraciones que debemos tener en cuenta incluso antes de comenzar a trabajar. Debo decir que esta lista la he hecho pensando en freelancers (porque yo mismo lo soy), pero muchas de las cosas que están aquí son válidas para no-freelancers también:

1. Procura hacer un cuestionario corto y preciso, que te permita luego crear un brief.

   La clave de un buen cuestionario es usar pocas preguntas, fáciles de contestar. Por lo general, tu cliente quiere dejar la mayor parte del trabajo tedioso de tu parte; además, si es una persona ocupada, no querrá agregar a su lista de tareas la de tener que hacer grandes cuestionarios o supervisar lo que estás haciendo, así que lo mejor para él (y para ti) es que le facilites lo más posible su parte del trabajo en la creación del proyecto. Eso sí, una vez que tengas el brief listo, no olvides enviárselo para que te dé su visto bueno.

2. Ten al menos una reunión con tu cliente para hablar sobre el proyecto.

   Esta puede ser presencial, vía telefónica u online (Skype, GTalk, Messenger, etc.) La reunión no puede ser por escrito. No significa que todas deban ser de esta manera, pero al menos la primera debe serlo. Todos sabemos que una conversación donde pueda -al menos- escucharse la voz de la contraparte resulta más fluida y productiva que una conversación escrita, que es más estructurada pero no permite la inmediatez de la primera; a eso hay que incluir ese “extra” que significa el tono de la voz y la capacidad de ganar la confianza de tu cliente a través de una buena conversación. Si puedes tener un par de conversaciones más con tu cliente, no las desaproveches. Ese tipo de contacto genera relaciones que duran en el tiempo (si te portas bien, claro).

3. Prepara un contrato y no comiences el trabajo hasta tener la aceptación del mismo, por escrito, de parte del cliente.

   No hace falta tampoco que generes páginas y páginas para tu contrato, sólo procura que no falten los puntos esenciales: Descripción del Proyecto, Presupuesto, Forma(s) de Pago y Tiempos de cada etapa. Siempre es buena idea que te asesores con alguien sobre las formalidades requeridas en tu país. Por supuesto, para que un contrato sea válido debe estar firmado por ambas partes o al menos aprobado expresamente de algún modo.

4. Comienza siempre con un mockup.

   Ya sea que utilices el viejo pero bueno papel y lápiz, algún software o alguna herramienta online, no comiences a diseñar sin crear antes un mockup. A diferencia del proceso de diseño, en el mockup preocúpate por cosas como la navegación, la distribución del contenido, el formulario de búsqueda, etc. Luego tendrás tiempo para el proceso de diseño como tal. Además, el mockup te permitirá volver a plantearte la estructura o parte de ella con facilidad.

5. Ten siempre presente la posibilidad de que el cliente retrase el trabajo.

   Personalmente, mi problema principal a la hora de intentar mantener los tiempos es que el cliente entregue el material, haga las revisiones en el tiempo establecido, etc. Para paliar ese problema suelo hacer dos cosas (no necesariamente al mismo tiempo):

   1. Colocar tiempos de revisión -normalmente de una semana- por parte del cliente, advirtiéndole que cada día de retraso implicará un cambio en la fecha de entrega y/o un recargo (de un 1%, máximo) en el precio final. Si quieres que se apure, tócale los bolsillos.
   2. Preveer estos retrasos, dándole más tiempo a los lapsos de entrega de material o revisiones. Esto no es la mejor solución, pero si conoces más o menos a tu cliente, puede funcionar.

6. Piensa en el usuario final, que tu sitio sea usable y accesible.

   El cliente a veces tiene la razón, pero es tu obligación hacer lo mejor que puedas por él. Hazle recomendaciones, dile por qué tiene sentido tu diseño. Eso sí, ten cuidado con terminar defendiendo tu diseño sólo porque lo hiciste tú y estás enamorado de él. No tengas como prioridad satisfacer a tu cliente sino a su cliente, que será quien tenga que interactuar con lo que hayas hecho. Ten en cuenta que el 80% de tus clientes no entieden que un sitio web es un medio de comunicación y no sólo una tarjeta de presentación.

7. Sé un profesional o no te vendas como tal.

   Sí, suena duro, pero eso cierto. Todos sabemos el dolor de cabeza que significa “el sobrino que sabe de computadoras”.
   No estoy diciendo que te vendas como el mejor diseñador/desarrollador del mundo, pero tampoco debes hacer pensar a tu cliente que no estás calificado para el trabajo o que simplemente eres su sobrino de 12 años. Si te vendes por centavos, no sólo te perjudicas tú (porque siempre esperarán que te vendas por centavos) sino a todo el mercado, creando el precedente de que el diseño web es cuestión de limosnas.
   Por otro lado, debes estar consciente de tu papel, tu cliente espera que resuelvas un problema, no que los crees; aún cuando estés comenzando, debes tener la suficiente seguridad para evitar que te vea como un repartidor de pizzas, si tú no te respetas ni respetas tu trabajo, tu cliente tampoco lo hará (ni la comunidad).

8. Estudia, lee, aprende.

   Una de las cosas más fascinantes de la tecnología es que está en constante desarrollo. Siempre hay cosas nuevas que aprender, los horizontes están en constante expansión. Si quieres permanecer en el mercado, ya sea que te dediques al diseño, al desarrollo o ambos, debes mantener “mente de principiante”, debes querer aprender cosas nuevas. Claro que no te volverás un experto en todo, pero al menos debes saber un poco de diseño, de desarrollo, de SEO, de estándares… esas son las cosas que marcarán la diferencia… o no.

En fin, ni esta lista ni las que vienen pretenden -ni mucho menos- ser la última palabra sobre este tema, hay cosas que faltan, cosas que pueden profundizarse y quizá cosas inútiles. Si les place, me encantaría saber su opinión al respecto.
Una vez dichas estas cosas generales, la próxima vez hablaremos más en profundidad sobre el Mockup.

Etiquetas Technorati: diseño, arquitectura web, progressive enhancement, proyecto web