Cómo afrontar un proyecto web. Parte 1: Del Mockup al CSS

Continuando con los consejos para enfrentar un proyecto web, en esta ocasión compartiré con ustedes varias observaciones sobre aspectos fundamentales del proceso de desarrollo de proyectos web. Este es el primero de varios artículos referidos a dicho tema y aborda, concretamente, aspectos a tomar en consideración al momento de emprender un proyecto de diseño de un sitio web en XHTML. Las referidas consideraciones igualmente pueden aplicarse a otros proyectos y/o tecnologías.

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 y 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 desarrollo, 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 por ejemplo, que de repente tu cliente quiera 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.

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 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 poseen cierta idea de lo que significa tener presencia en la web y cómo eso puede reportarles beneficios reales y, sobre todo, que conocen más o menos lo que realmente desean, la mayoría de los clientes, no tienen 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 y puede escoger 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ía la indecisión del cliente, atrasando el proyecto porque necesitaría más tiempo para decidirse, y acrecentaría la posibilidad de que la selección final sea un diseño completamente diferente, una especie de Frankenstein web hecho con piezas de tu propuesta.

¿Cuál es la solución?

Presenta dos, máximo tres, propuestas y prepárate.

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 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.

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 el esquema 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.

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.

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.

¿Cuál reseter usar?

Hay cientos en internet. Basado en mi experiencia, lo mejor que puedo recomendarte es 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.

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.

¿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, es aplicable principalmente 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.

Como siempre, hay cosas que se quedan en el tintero y cosas 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.

¿Sabes SQL? ¿No-SQL? Aprende MySQL, PostgreSQL, MongoDB, Redis y más con el Curso Profesional de Bases de Datos que empieza el martes, en vivo.