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: , , ,

Abrir Nueva Ventana en (X)HTML Strict II (mantener la usabilidad)

(Atención: Este post es una continuación de Abrir Nueva Ventana en (X)HTML Strict; aunque no es obligatorio que lo hayas leído, es recomendable para entender el contexto.)

Ya en el post anterior (Abrir Nueva Ventana en (X)HTML Strict) habíamos mostrado una forma de conseguir que nuestros vínculos se abriesen en una nueva ventana sin saltarnos el estándar de (X)HTML Strict, por medio del atributo rel y javascript. Sin embargo, tenemos un problema: ¿qué pasa si nuestro usuario tiene desabilitado javascript? Bueno, de eso se trata este update.

Nota: Esto está enmarcado en el proceso de realización del proyecto cesarfrick.com (ya pronto, ya pronto…), así que lo mostraré en este contexto, si tu necesidad difiere un poco de lo que aquí se muestra, debes hacer las adaptaciones pertinentes. También puedes decir que fue tu idea, no creo que haya sido el único loco en pensar en esto ;)

He aquí el código (esto va en un archivo externo, que yo he llamado external_links.js):

function openExternal(){
var anchors = document.getElementsByTagName('a');
for(var i = 0; i < anchors.length; i++){
var thisAnchor = anchors[i];
if(thisAnchor.getAttribute('href') && thisAnchor.getAttribute('rel') == 'external'){
var parent = thisAnchor.parentNode; //Referencia al contenedor del hipervínculo.
var a = document.createElement('a'); //Creamos un nuevo Hipervínculo.
var space = document.createTextNode(' ');
a.innerHTML = '(Abrir en una Nueva Ventana)'; //Colocamos el texto que aparecerá
a.href = thisAnchor.href;
a.title = thisAnchor.title;
a.target = '_blank';
parent.appendChild(space);
parent.appendChild(a);
}
}
}
window.onload = openExternal;

Ok, expliquemos esto paso a paso. Lo que hace este código no es que cada link con el atributo rel=”external” se abra en una ventana nueva, en este caso lo que haremos es crear un nuevo link, que será el que abra en una nueva ventana, al lado del que ya hemos creado en (X)HTML. ¿Cómo lo hace?

  1. Guarda en un Array todos los hipervínculos de nuestro HTML:
    var anchors = document.getElementsByTagName('a');

  2. Si el array tiene un hipervínculo y su atributo rel es external:
    if(thisAnchor.getAttribute('href') && thisAnchor.getAttribute('rel') == 'external'){

  3. Guarda en una variable el elemento que contiene el hipervínculo:
    var parent = thisAnchor.parentNode;

  4. Crea un hipervínculo nuevo (que será el que se abrirá en la nueva ventana) y también un espacio:
    var a = document.createElement('a');
    var space = document.createTextNode(' ');

  5. Le coloca el texto “Abrir en Nueva Ventana”:
    a.innerHTML = '(Abrir en una Nueva Ventana)'

  6. Le agrega la misma dirección (href) y el mismo título (title) que el hipervínculo que creamos en HTML:
    a.href = thisAnchor.href;
    a.title = thisAnchor.title;

  7. Le asignamos el atributo target y le damos el valor _blank (lo que hará que abra el vínculo en una nueva ventana/pestaña)
    a.target = '_blank';

  8. Añadimos el espacio y el vínculo al contenedor:
    parent.appendChild(space);
    parent.appendChild(a);

  9. Procesamos la función en cuanto se carga el HTML:
    window.onload = openExternal;

La diferencia entre esta técnica y la mostrada en Abrir Nueva Ventana en (X)HTML Strict es que, si el browser del usuario tiene javascript desactivado, no se mostrará este hipervínculo, por lo que no tendrá la confusión de tener un hipervínculo que no haga lo que dice (abrir en una nueva ventana). Simplemente navegará en la misma ventana sin darse cuenta de nada. Creo que esto es una mejora a nivel de usabilidad porque no obliga al usuario a tratar de entender por qué tiene dos vínculos que hacen exactamente lo mismo…

Nota II: En mis pruebas, no he tenido problemas con Firefox, Opera ni Safari (para Windows), pero en IE6 (tenía que ser) crea el vínculo pero no le asigna el atributo href. Si encuentro alguna forma de conseguirlo se los haré saber; si alguien la encuentra, le agradecería mucho que la compartiera ;)

Update: Pues, revisando los foros de Cristalab he dado con la solución por pura casualidad. Al parecer, IE6 no acepta la asignación directa de un valor al atributo href, así que con lo que me encontré fue con el método setAttribute, con esta sintaxis:

objeto.setAttribute('nombre_atributo', 'valor atributo');

Por lo tanto, cambiamos la línea:

a.href = thisAnchor.href

por:

a.setAttribute('href', thisAnchor.href);

¡Y listo, ya funciona para El Maligno (léase IE6 ;) )

Abrir Nueva Ventana en (X)HTML Strict

Como ya lo había comentado en este post, voy a explicar acá una forma alternativa de abrir nuevas ventanas y al mismo tiempo no romper la validación de (X)HTML Estricto.

Nota: Éste post es una continuación del mencionado anteriormente, donde explico las razones por las que me parece un método válido de trabajo. Dándolo por sabido, sólo procederé a explicarlo si extenderme en las razones.

Muy bien, como ya sabemos, la recomendación de (X)HTML Estricto ha eliminado el atributo target en la etiqueta de hipervínculo (<a>), por lo que su uso en el código HTML o XHTML impedirá que nuestros sitios sean válidos ¿Pero cómo resolver el problema cuando realmente necesitamos (sin tener en cuenta los molestos pop-up) que nuestro vínculo se abra en una ventana/pestaña aparte? La respuesta: echando mano de un nuevo atributo de hipervínculo (el atributo rel) y de un pequeño código en Javascript.

El Atributo rel:

Ya existente en la etiqueta link, es añadido a la etiqueta a para darle significado semántico a los hipervínculos. En otras palabras, permite establecer la relación entre la página donde está el vínculo y la página a donde lleva. Aunque tiene algunos valores determinados, es permitido colocar valores personalizados por parte del diseñador/desarrollador.

Esta flexibilidad del atributo rel ha permitido darle otras aplicaciones por parte de los buscadores como Google o Yahoo!, que han acordado no hacer seguimiento de los hipervínculos cuyo atributo rel sea “nofollow”, para ayudar a combatir el endemoniado spam (Yeah! :D ), o el caso de Technorati, que promueve el uso del valor “tag” para ayudar en la búsqueda por etiquetas.

Esta misma flexibilidad es la que usaremos para nuestra técnica. ;)

Vamos a lo Nuestro

Ok, lo primero que debemos hacer es agregar a nuestras etiquetas <a> el atributo rel, al que asignaremos el valor que usaremos para saber cuáles son los hipervínculos que queremos abrir en una ventana nueva (no es obligatorio, pero dado que se ha estado volviendo un estándar, usaremos el valor external). Por ejemplo, si queremos aplicar esta técnica a un hipervínculo a cesarfrick.com, colocaríamos:

<a href="http://www.cesarfrick.com" title="César Frick - Diseño Web y Multimedia" rel="external">cesarfrick.com</a>

Una vez hecho esto, creamos un documento .js donde escribiremos el código javascript que hará “la magia” ;) . En él escribiremos esto:


function openExternal(){
if(!document.getElementsByTagName) return;
var anchors = document.getElementsByTagName('a');
for(var i = 0; i < anchors.length; i++){
var thisAnchor = anchors[i];
if(thisAnchor.getAttribute('href') && thisAnchor.getAttribute('rel') == 'external'){
thisAnchor.target = '_blank';
}
}
}

window.onload = openExternal;
Expliquemos un poco el código:

Lo primero que hacemos es crear una función (en este caso la he llamado “openExternal”). Esta función es la que:

  1. Chequeará que haya etiquetas en nuestro (X)HTML. Si no las encuentra, sale de la función sin devolver ningún resultado.
  2. En caso de encontrarlas, las almacenará en un Array
  3. Por medio de un Bucle for, chequeamos dos cosas:
    1. Que el vínculo tenga un atributo href.
    2. Que el atributo rel sea “external”.
  4. Si ambas condiciones son ciertas, agregamos al vínculo el atributo target y le asignamos el valor _blank.

Esta sería toda la función. Ahora lo único que nos queda es llamarla cuando se cargue la página para que se ejecute después que todos los vínculos han sido cargados y antes que el usuario haga algo.

Una vez escrito el código, guardamos nuestro archivo y le colocamos un nombre que nos permita identificar qué hace (yo llamé al mío external_links.js).

¿Por qué guardarlo en un archivo aparte? Por dos razones:

  1. Hacemos nuestro (X)HTML más limpio separando la maquetación (el HTML como tal) de la programación, así se lee mejor y podemos dedicarnos a cada cosa (la maquetación o la programación) separadamente sin afectar el otro archivo. Esta es la misma razón para usar archivos .css para dar estilo a nuestro HTML.
  2. Hacemos nuestro código reusable porque, al estar en un archivo aparte, si lo necesitamos en otro proyecto sólo tendremos que copiarlo en la carpeta del siguiente proyecto sin tener que copiar y pegar el código cada vez.

Ahora lo único que nos falta es asociarlo a nuestro archivo .html, lo que hacemos a través de la etiqueta <script>, colocando entre las etiquetas <head> y </head>:

<script type="text/javascript" src="scripts/external_links.js"></script>

En este caso asumo que el archivo está dentro de una carpeta llamada “scripts”, que está en la raíz del sitio, si lo guardas en un sitio diferente, debes cambiar la ruta por la tuya.

¡Y eso es todo! Espero que les sea de ayuda ;)

Como dije también en el post anterior, es recomendable, por razones de usabilidad, al menos advertir al usuario que los links se abrirán en una ventana nueva, o darle la opción de abrirlo también en la misma ventana, si así lo desea.

Update: En vista de la observación que hice en el párrafo anterior respecto a la usabilidad, hice unos cambios al script en este post.

(X)HTML Strict y Abrir Vínculos en Nuevas Ventanas

Trabajando en el proyecto cesarfrick.com se me ocurrió (como me pasa cada vez que deseo hacer un proyecto que me resulta especialmente interesante y me permite investigar) adecuarme a las normas, en este caso a la recomendación XHTML Strict 1.0 de la W3C.
*Sí, tienes razón, esto va a ser muy geek ;)
Pues eso, me pongo a trabajar y decido colocar en la página principal algunos de los trabajos que he realizado, como una forma de dar al visitante una idea rápida de mis “habilidades” :lol:
Entonces me surge un gran problema: Para evitar que el usuario se “escape” de mi site al visitar los proyectos que están en línea, decido utilizar lo que todo Diseñador Web conoce desde el principio:
<a href="direccion" target="_blank">El Link </a>
Esta simple línea haría lo que necesitábamos de ella: abriría “direccion” en una página nueva.
El problema surge al darme que cuenta que en XHTML Strict, el atributo “target” se ha eliminado, lo que hace que el site no valide a causa de esto.
Como siempre, primero que hice fue ponerme a investigar, por lo que apelé a San Google para averiguar si existía alguna forma alterna de hacer lo que buscaba, o si debía simplemente seguir las directrices de la W3C y permitir que todos los vínculos se carguen en la misma ventana/pestaña.
Lo primero de lo que me dí cuenta es que es un tema sumamente discutido y que, por supuesto, hay multitud de opiniones: desde los puristas que aplican sin chistar todas las especificaciones de la W3C, hasta los me_importa_una_… para quienes lo único importante es que el site se vea bien en todos los navegadores y haga lo que quiero que haga. No voy a llenar este post con esta discusión, porque se alargaría hasta el infinito, y para eso ya me basto yo solo.
Fue así como llegué a un artículo escrito por Kevin Yank, llamado New-Window Links in a Standards-Compliant World, en sitepoint. En él su autor, además de ofrecer un modo de resolver este problema por medio de un pequeño Javascript, argumenta las razones por las que, según su criterio, esto no es una especie de hack al estándar y que (al contrario de lo que piensan algunos puristas) no hace que, al final, el código siga siendo inválido.
En resumidas cuentas, Yank expone que (hago una traducción libre del artículo en este punto):

Como un jodido perfeccionista, mi primer impulso cuando aprendí esta solución fue preguntarme, “¿existe realmente una diferencia?”. Y sí, suelo hablar conmigo mismo mientras estoy investigando. [Nota del Traductor: ¡Yo también! :lol: ]

Quiero decir, si el atributo target de la etiqueta <a> está siendo descartada ¿realmente hace alguna diferencia crearla por medio de Javascript, en vez de por HTML? Claro, la página validará al contrastarla con las Definiciones de Tipo de HTML 4.0 Estricto y XHTML 1.0 Estricto ¿pero no estamos haciendo una trampa técnica? La respuesta es no.

El Modelo de Objeto de Documento (DOM), que gobierna los objetos del documento y sus atributos que están disponibles para el código Javascript, es un estándar totalmente separado de (X)HTML. Considere también que el estándar DOM 2.0 que fue publicado en Enero de 2003 (bastante después de XHTML 1.0, por no hablar de HTML 4.0) incluye este atributo. Parece claro que, si bien se ha previsto descartarlo en (X)HTML, podrá accederse a través del DOM en el futuro previsible.

Esto me parece un argumento bastante aceptable (y no sólo convenientemente aceptable), puesto que usando esta técnica nos mantenemos dentro de los estándares, no sólo de (X)HTML Estricto, sino también del DOM. Claro que seguramente ésto no zanjará la polémica entre puristas y no-puristas, pero me parece que es una alternativa coherente y que no rompe con un trabajo limpio y seguidor de las normas.
El único punto que no podremos evitar será que el usuario seguirá abriendo los links en la misma ventana si tiene Javascript desabilitado en su explorador, pero teniendo en cuenta que la mayoría de los exploradores lo soportan, el número de usuarios a los que les ocurrirá esto será realmente mínimo.
Un punto respecto a la usabilidad: Como norma general, deberías agregar una nota o un icono advirtiendo a tus usuarios que el vínculo se abrirá en una nueva ventana, así le evitas sorpresas desagradables. De hecho, lo ideal sería darle la opción de abrirlo en la misma ventana si lo desea.
Bueno, después de toda esta perorata, me dispondré a explicar esta técnica, pero eso lo haré en otro post, éste ya está demasiado largo… ;)

Update: Conversando sobre este tema con Inyaka, me dí cuenta que dejé este post huérfano y no coloqué los links de seguimiento del tema, así que aquí lo tienen:

La aplicación de la técnica: Abrir Nueva Ventana en (X)HTML Strict

Una adaptación que hice para resolver el tema de la usabilidad (que al final fue el script que usé): Abrir Nueva Ventana en (X)HTML Strict II (mantener la usabilidad)