Estas son algunas etapas que se sugieren para diseñar eficientemente un sitio; es conveniente no comenzar a escribir ninguna línea de código HTML antes de completar las primeras etapas.

Delimitación del tema
Esta es la etapa crucial, se define de qué se va a tratar el Web, que cosas se incluirán y qué no. También es el momento para definir tanto las audiencias (normalmente es más de una) y los objetivos (intentando priorizar entre objetivos primarios y secundarios).

Si no se evalúa adecuadamente la cantidad de tiempo que se dispone contra la cantidad de tiempo requerida para elaborar un sitio de la magnitud deseada, el resultado puede ser desastroso. Muchos proyectos Web fracasan porque comienzan a crecer y crecer sus especificaciones, sin que haya detrás un trabajo ordenado de delimitación de contenidos.

Obsérvese lo siguiente: la mayoría de los sitios que son premiados con distinciones como "Lo mejor de …", "La mejor página de la semana …", "Top 5% del Web", son sitios que se dedican a temas muy específicos. La gente no quiere un montón de sitios que tengan referencias a otros lugares, la gente lo que busca es el contenido.

Recolección de la información
En esta etapa se recolecta la información que se va a poner en el Web, de acuerdo a la especificación hecha en la etapa anterior. Es conveniente asociarse con alguien como un "proveedor de contenido", puesto que como mencioné antes hay mucha gente que si bien le tiene aversión a los computadores y que dispone de valiosísima e interesante información. Las organizaciones en general producen grandes cantidades de información, también en esta etapa hay que delimitar cuanta de la información histórica, que ya no es relevante, sera incluida en el sitio web, por ejemplo, se puede definir que la información de mas de 3 años de antigüedad no sera incluida, etc.

Agregación y descripción
Una vez que tenemos la información que irá en el sitio, comenzamos una clasificación apropiada. Aquí hay que encontrar un adecuado balance entre la linealidad y la jerarquización.

Aplicamos una clasificación de tipo lineal a fragmentos de información que requieren que la persona que los lee vaya avanzando poco a poco en el conocimiento de algo, como en un libro. Usualmente los pondremos en una misma página, usando FRAMES o una técnica similar si se estima apropiado. Aplicamos una clasificación de tipo jerárquica a trozos de información que sean complementarios o que dependan uno de otro, como secciones y subsecciones. Usualmente los pondremos en diferentes páginas.

Es importante aquí no centrarse en una única forma de clasificar los documentos. Una serie de descriptores tienen que ser definidos. Ademas, un mismo documento puede pertenecer a varios valores de un mismo descriptor. Si nos encontramos en esta etapa discutiendo sobre si un elemento de información va en una u otra parte, es que estamos cometiendo un error: debe ir en todas las partes donde un usuario razonable esperaría encontrarlo.

Estructuración
En este punto se estructura la manera en que se unen las diferentes páginas, de acuerdo a la agregación de contenidos realizada en la etapa anterior. Se provee de ayudas para la navegación, de enlaces que permitan la jerarquización que diseñamos y de enlaces entre elementos de una misma jerarquía si se desea. También es importante proveer de indices para cada descriptor que haya sido diseñado. Desde este punto en adelante se puede trabajar en la implementación HTML propiamente tal.

Metáfora
Existen muchas páginas que esperamos sean accesadas desde diferentes partes de nuestro servicio (por ejemplo: un glosario o una ayuda). Quizás en alguna parte del documento mencionamos a otra página y sería interesante que el usuario pudiera hacer click en esa referencia para ir a la página que estamos referenciando.

A esta etapa le llamamos "metáfora" pues permite referirse a una misma entidad (en este caso, una página HTML) en diferentes contextos. Estas paginas deben ser diseñadas cuidadosamente puesto que seran importantes para los usuarios al permitirles "saltar" dentro del sitio desde zonas logicamente distantes.

Diseño y estilo gráfico
Un estilo gráfico adecuado puede ser algo importantísimo a la hora de hacer que la persona que nos visita se sienta cómoda, y como una manera de alivianar el contenido y hacerlo más digerible. Un sitio por mas contenido que tenga si no tiene un buen diseño gráfico difícilmente lograra un lugar destacado entre otros sitios del mismo tipo.

En cuanto a la cantidad y tamaño de las imágenes, hay que adoptar un equilibrio. Hay sitios que se basan casi por completo en grandes y lentas imágenes GIF, otros que se ven bastante pobres pues son casi sólo texto, con lo que se desaprovechan los métodos multimediales . El esquema que se adoptará, (que se encuentra en algún lugar entre ambos extremos) varía de diseñador a diseñador y es un punto importante a considerar.

Otro punto importante en la etapa de definición de la parte gráfica, es intentar en lo posible mantener una cierta coherencia gráfica, y atreverse a innovar en cuanto a ella. Un color de fondo, un fondo o una distribución interesante de los elementos dentro de una página es algo que no se olvida con facilidad.

Ensamble final
En este punto concretamos el diseño, con los últimos enlaces que sean necesarios e incorporamos el estilo gráfico a las páginas, se ensambla el sitio con una portada que sea capaz de presentar en una sóla página física al menos lo más relevante del sitio, se instalan links hacia la página personal del autor y/o su dirección de correo electrónico.

Testeo
Finalmente, es necesario revisar la coherencia general del sitio, que no hayan links "rotos" que no conduzcan a ninguna parte; revisar la redacción y ortografía de las páginas, hacer los ajustes necesarios para separar las páginas que sean demasiado extensas en páginas más pequeñas.

Para esta etapa, lo mejor es tratar de buscar usuarios que vayan a utilizar el sitio en la practica, y si eso no es posible, ponerse en el lugar de las personas que vean los documentos, y seguir los pasos que suponemos que ellos seguirán.

Llegados a este punto necesita definir la organización de la información de tu sitio web. Es decir, ha llegado el momento de crear la estructura de tu web, su esqueleto, la base que soportará todo lo demás. La forma en que estructures el contenido de tu web será determinante para que los usuarios encuentren o no lo que buscan (algo muy relacionado con la usabilidad). Por tanto, ésta debe facilitar y agilizar al máximo la búsqueda de información de tus visitantes. Al mismo tiempo, también es importante diseñar la estructura de forma que actualizaciones futuras de la web no obliguen a cambiar muchas partes de la página.
Para crear la estructura, puede ser útil hacer un inventario de todo el material que vas a exponer en la página e ir organizándolo en un primero momento por temas para después construir gráficamente la estructura de la web.

Aunque poca gente lo hace, es muy útil construir varios prototipos (o bocetos) de tu web y probar la reacción de los usuarios ante ellos. Esto de comprobar la reacción parece más complicado de lo que crees, pero un método casero y sencillo que puede aportar información para saber si la estructura del sitio es fácil de comprender y manejar, es hacer varias plantillas con diferentes estructuras y pedir a amigos y familiares que naveguen por ellas y nos den su impresión. Cuál les resulta más fácil de entender, más atractiva, en cuál se encuentra mejor una determinada información, en cuál están más claros los contenidos a los que dirigen los enlaces, etc.

Página de inicio
La página de inicio es la principal puerta de entrada de visitas a tu página, por lo que debe poder atrapar al mayor número de visitantes que entren. Para ello, debes adaptar su estructura a tu público objetivo, haciendo bien visibles los contenidos que más pueden interesarles. También es importante dejar claro desde el principio el tema de la web, y para eso la página de inicio es una buena herramienta. Especifica claramente qué se va a encontrar el usuario al explorar tu página, a la gente no le gusta perder el tiempo y a ti no te interesan visitas de este tipo porque no aportan ningún beneficio a tu web.
Por otro lado, algo tan sencillo como incluir un enlace bien visible a la página principal en todas tus páginas facilita muchísimo la navegación. En este sentido, algo que se usa mucho y también ayuda a los usuarios a navegar por tu web es poner un enlace en el banner o logo de la cabecera que apunte a la página principal del sitio.

Diseño del menú de navegación
Una de las cosas más importantes a la hora de estructurar la página es el diseño del menú de navegación.
Echa un vistazo a la estructura inicial que creaste, ¿cuáles son las secciones más grandes?, ¿cuáles agrupan más contenido?, esas pueden ser las secciones que incluyas en el menú principal y que sería conveniente que aparecieran en cada página de tu web para facilitar la navegación. Ahora bien, una vez dentro de cada sección concreta, el menú puede modificarse para mostrar las opciones específicas que ofrece esa sección (además de enlaces a las secciones principales).
No hay que olvidar que otro tipo de páginas como información acerca de la web, aviso legal, política de privacidad, formulario de contacto, etc, deben estar convenientemente visibles, por lo que muchas páginas optan por incluir un menú horizontal a pie de página para enlazar con estas secciones.

Tipos de estructuras de sitios web
Ya se han comentado en este tutorial los principales tipos de estructuras que se usan en la web, si te interesa puedes echarle un vistazo al primer artículo de este tema.

Qué es la compatibilidad web?
Que una web sea compatible con todos los navegadores significa que se vea igual (o muy similar) en todos ellos. Obviamente esto es bastante complicado, podremos estar satisfechos si conseguimos que se vea igual de bien en los más importantes, como Explorer, Firefox, Opera, Safari y Mozilla. Si consigues que se vea bien en estos 5, conseguirás que el 99% de tus usuarios vea correctamente tu web.

El problema radical en que no todos los navegadores interpretan en código HTML y CSS de la misma manera, entre ellos existen pequeñas variaciones que son las que hacen que el resultado no sea el mismo de unos a otros. Algunas de esas diferencias son tan importantes que pueden hacer que partes de tu web no funcionen o no se vean, y como el propósito de hacer una web es que la vea el mayor número de personas (y que éstas la vean correctamente), nos interesa que la web funcione en el mayor número de navegadores posibles.

Por tanto, a la hora de hacer una página web no es suficiente con preocuparse por centrarnos en la audiencia adecuada, registrar un nombre de dominio rompedor o tener un diseño agradable al usuario. Todo esto puede verse ensombrecido si un usuario no ve la página correctamente al entrar con un navegador que no has tenido en cuenta al crearla.

Para que veas un ejemplo leve de lo que hablamos, aquí puedes apreciar como se ve una página web en diferentes navegadores. Por supuesto es ficticia y el diseño está hecho descuidado a propósito:

Como hemos dicho, hay casos de incompatibilidad más graves en los que el diseño se desajusta, no cabe completo en pantalla, scripts o menús que se comportan de manera diferente de un navegador a otro… en fin, un desastre, sobre todo si tu web es un negocio en línea o una página de empresa que requieren cuidar el aspecto al máximo para atraer al cliente.

Mejorar la compatibilidad con navegadores
Validar el código de tu sitio web
Validar el código de tu web en base a los estándares del W3C es un buen hábito que conviene que cojas cuanto antes mejor. Básicamente consiste en escanear tu web en busca de errores de programación para una vez detectados poder corregirlos. Además, a parte de detectar errores de codificación te proporciona una breve explicación del error, por lo que aprenderás cosas nuevas validando tu web. Tener una página sin errores es importante porque maximiza la compatibilidad entre navegadores al mismo tiempo que te asegura que tu código siga valiendo para futuras revisiones de HTML, CSS, etc.
Tómate tu tiempo para validar el código CSS de tu web. Eso hará que te sea más fácil conseguir que tu sitio se vea igual en los distintos navegadores ya que hará que tengas un código más limpio y sobre todo sin errores.

Para validar tu CSS lo mejor es usar las herramientas disponibles, ya que si te propones hacerlo manualmente la tarea será difícil y larga. Además, es muy sencillo que se te pasen errores, mientras que usando herramientas online no ocurrirá. El validador de CSS del W3C es la mejor opción para ello, ya que esta entidad es la que se encarga de crear los estándares de la web.

Resetear los estilos CSS
Si no usas ningún estilo CSS en los elementos de tu página igualmente tendrán un aspecto determinado. Los títulos tienen una tamaño según su importancia (H1, H2, H3…), los márgenes tienen un tamaño determinado, las citas llevan sangría, etc. Muchos de estos valores por defecto, son iguales de unos navegadores a otros pero otros no, y esos precisamente son los que te crearán problemas a la hora de conseguir que tu web se vea igual en los diferentes navegadores, ya que por mucho estilo que les des, su valor predeterminado sigue contando.

Por eso, resetear tu hoja de estilos es una de las mejores medidas que podemos adoptar para prevenir el problema de la incompatibilidad entre navegadores, ya que por defecto, todos los elementos HTML tienen unos atributos CSS predeterminados. Así, los márgenes, espacios y tamaños de fuente de títulos (entre otros) pueden tener diferentes propiedades por defecto de un navegador a otro y provocar que se vean diferentes por mucho formato que le demos nosotros. Al resetear el CSS digamos que ponemos a cero esos valores por defecto y podemos empezar desde el principio a dar el formato que nosotros queramos, controlando el aspecto de cada elemento mucho mejor. Para resetear el CSS se escribe un código CSS al principio de tu hoja de estilos, y después todo lo que tu vayas creando. El código de Eric Meyer es una de las formas más conocidas que tenemos de resetear el CSS de nuestra web, muy efectivo:

Por otro lado, una forma más sencilla, aunque no tan completa, de anular los valores por defecto que más problemas suelen dar (margin y padding) es poner el siguiente código al principio de tu hoja de estilos y luego las reglas que vayas creando:

Lo que hace este código es dar un margin y padding de 0 a todas las propiedades CSS.

Evidentemente no es tan completo como el anterior código, pero si no quieres complicarte mucho la vida o necesitas ahorrar espacio reduciendo la hoja de estilos, este código también quita muchos problemas.

Usa técnicas soportadas
CSS ofrece un montón de técnicas para mejorar el aspecto de nuestras páginas web, pero no todas son bien soportadas por los navegadores. Lo mejor es intentar evitar el uso de propiedades que puedan causarnos problemas con algunos navegadores, en especial con los más usados por los visitantes (IE, Firefox…). En general, usando buenas prácticas en CSS minimizamos el riesgo de incompatibilidades entre navegadores.

Diseñar para Firefox, no para Explorer
Una de las cosas que han hecho a Firefox tan popular es que es uno de los más completos navegadores en cuanto a respetar los estándares web se refiere. Y como él hay muchos otros (cada vez más) que se preocupan por seguir al máximo los estándares del W3C. Por tanto, diseñando para Firefox estamos minimizando el uso de reglas indebidas o malinterpretadas, ya que el aspecto que nos devuelve el navegador de lo que programamos se acerca mucho más a la regla general que diseñando en Internet Explorer.

Diseñar optimizando para Firefox hace de nuestro código un código más limpio, más estándar, y por tanto más universal. Una vez funcione en Firefox, puedes empezar a pensar en que tu sitio se vea bien en Explorer. Si lo haces al revés, cuando consigas que se vea bien en Explorer tendrás que ir arreglando el código para que se vea bien uno por uno en el resto de navegadores, mucho más trabajo ¿no?.

Arquitectura de la información

Arquitectura de la información es la tarea de organizar la información dentro de un proyecto interactivo.

Todo empezó con Jesse James y el diagrama de la experiencia del usuario.

El esquema resume los pasos a seguir para realizar un buen diseño centrado en los usuarios.

Estos pasos son los elementales y son los que nos deben marcar la pauta en nuestro desarrollo.

En este artículo vamos a desarrollar el primer paso.

Entender las necesidades del usuario y los objetivos del sitio web.

Las necesidades del usuario

¿A quién nos dirigimos realmente? ¿Qué quieren? ¿Qué buscan?

El cliente de nuestra empresa es el mismo que el cliente de nuestra web

Un aspecto a tener muy claro es que por estar en internet no tenemos que cambiar nuestros objetivos, forma de comunicar, vender.

Que nuestra empresa esté en internet sólo quiere decir que el canal es internet. Nuestro público objetivo, sus necesidades no tienen porque ser nuevas o diferentes al canal offline.

Al principio de Internet se podía decir que el usuario de la web eran los "usuarios avanzados" y que por tanto el contenido a poner en Internet debía apelar a este usuario. Ahora los usuarios de Internet son tantos que se puede decir que representan a la sociedad "offline" de forma fiel y por tanto no debemos pensar que la audiencia en Internet va a ser muy diferente a la audiencia offline.

Mantener el tono de voz

Dar el paso a Internet no quiere decir que la empresa tenga que transformar su presencia, tono de voz, etc...

Al principio de Internet muchas empresas cambiaban su nombre, forma de comunicar, etc... para posicionarse en internet sin debilitar su presencia offline.

Los casos más notorios fueron los de los bancos que sacaron marcas nuevas para tener una presencia en internet alejada de la marca offline.

Actualmente la presencia web se ha normalizado y ya todas las marcas mantienen el tono de voz e identidad offline y online.

Identificando las necesidades del usuario

Es muy importante llegar a identificar los tipos de usuario objetivo de la web y las necesidades reales de estos.

Aun así, una vez tengamos definido el tipo de usuario y sus necesidades deberemos seguir puliendo los detalles hasta encontrar los aspectos que harán al usuario actuar, interesarse, fidelizarse, opinar, etc...

Supongamos los siguientes escenarios.

El País. Público objetivo. Entre 15 y 85 años, todos los niveles económicos. Información general.

Alzado.org. Público objetivo. Entre 20 y 40. Todos los niveles económicos. Información sobre desarrollo web.

Big head, long tail

La perfilación de usuarios que hemos puesto como ejemplo son las del "Big Head". Esta perfilación es la útil para desarrollar campañas de comunicación o venta "al viejo estilo". Es decir, si uno tiene que lanzar un spot en televisión que se supone va a ser expuesto a millones de televidentes, uno debe apuntar al "Big Head".

¿Cúal es el problema del "Big Head"?

Que el Big Head como tal va desapareciendo. Incluso en los medios tradicionales (televisión, radio, prensa) las audiencias se van especializando y el "big head" desaparece.

Ahora aparece el "Long Tail".

El long tail es la gran masa de usuarios dispersos que es algo más complejo encasillar.

El "long tail" aparece por todas partes y su presencia es cada vez más clara gracias a las nuevas herramientas de medición que nos permiten conocer mejor a la audiencia.

La concentración de la audiencia es cada vez más baja. Cada vez es mas barato lanzar canales de comunicación haciendo que la audiencia se fraccione en millones de nichos.

Para poder aprovechar el Long Tail son necesarias nuevas herramientas, nuevos sistemas y sobre todo nuevas formas de pensar.

Las empresas que han sabido desarrollar sistemas de comunicación, venta, gestión más automáticos, pueden aprovechar el "Long Tail" de usuarios ya que es rentable y sencillo diseñar productos para nichos de mercado en lugar de desarrollar únicamente productos para el "Big Head".

En el caso del País, supongamos las siguientes necesidades del usuario.
• Que ha pasado hoy. En España, Europa, el mundo, sectores.
• Que pasa cerca de donde vivo.
• Leer columnas que me gustan.
• Secciones específicas de información "útil" (televisión, tiempo...).

No es un desglose especialmente brillante, pero podría ser un punto de partida... y entonces uno se pregunta... ¿por qué tienen esta barra de navegación como elemento principal?

Miremos el caso de Alzado.org

En alzado tenemos un perfil de usuario antes definido. Pero podríamos matizar algo más.
• Gente que nos usa como una revista. Gente del sector, bastante profesional y que viene a alzado a ver "noticias" del sector.
• Gente que nos usa como libro. Gente del sector, quizás menos profesional y que quiere saber como hacer cosas.
• Gente que nos encuentra. Gente del sector (con y sin experiencia) que buscando un dato nos encuentra vía Google.
(En el caso del País no he incluido Google porque diría que el tráfico de Google hacía el País debe ser menos del 10%).
• Al primer grupo les intentamos servir artículos nuevos semanalmente y últimamente estamos consiguiendo tener 2 o 3 por semana.
• Al segundo grupo les ofrecemos el "directorio" de términos clave y el buscador interno.
• Con el tercer grupo es con el que más pinchamos ya que las páginas finales de artículo no están bien diseñadas para enganchar a este tipo de usuario. El usuario que llega a un artículo final no encuentra fácilmente más artículos relacionados (puede consultar los del autor, pero el usuario ha llegado buscando un contenido, no un autor y por tanto el elemento de dirección debería ser "más contenido").

Pero podríamos seguir matizando en detalles para poder afinar más y es aquí cuando entran los "cuadros o mapas de usuarios".

Esta técnica es bastante sencilla y nos permitirá desarrollar conceptos sobre usuarios y contenidos a desarrollar.

La técnica se basa en crear un eje de coordenadas y plantear valores sobre el mismo y en torno a esos valores posicionar contenidos.

Por ejemplo:

En este cuadro pretendemos ilustrar el caso de poner como objetivo satisfacer las necesidades de "gestores de proyectos". Hemos creado la división entre internos (trabajan dentro de la compañía) y externos (trabajan como proveedores de un servicio tipo consultoria) y entre webs transaccionales y de información.

Quizás los conceptos puestos no sean del todo acertados pero pretenden demostrar como podemos ir pensando en "temas" de interés para esta audiencia y en desarrollar secciones, apartados, etc... que sirvan para satisfacer a este sector que pueda resultar estratégico.

Este ejercicio nos debería ayudar a perfil tipos de usuarios y necesidades. La idea de este ejercicio es hacer tantos como escenarios posibles. En el caso de Alzado podríamos tener los siguientes casos.

• Programadores
• Diseñadores
• Gestores de proyectos web
• Inversores
• Clientes de empresas de desarrollo web
• Arquitectos de la información
• Consultores
• Estudiantes...

Y a todos estos perfiles les podríamos cruzar con los siguientes valores.

• Ingresos
• Edad
• Localización
• Estudios
• Situación laboral
• ...

Con este esquema obtenemos cientos de cuadros que nos darán una idea concreta de que contenidos pueden adecuarse a cada grupo y ante esa "foto" poder decidir que priorizamos, que podemos atender sin problemas, que puede ser mas rentable...

Esta idea es importante ya que la web se desarrolla más en torno al "Long Tail" que en torno al "Big Head". La web es la herramienta perfecta para captar miles de micro nichos que las ediciones offline no pueden captar (por distribución, precio, etc...).

Es importante desarrollar cuadros de necesidades de usuarios por cientos y luego con las herramientas adecuadas ser capaces de empaquetar el contenido en un formato que satisfaga a estas audiencias.

Los objetivos del sitio web

Sobre este punto debemos desarrollar algunas ideas.
La arquitectura de la información de la mayoría de lo sitios web sólo responde a las necesidades del propio site.

La comunicación, el lenguaje, los menús, suelen responder principalmente al orden y estructura interna de la propia empresa.

Podríamos decir que Google es un ejemplo de este tipo de organización.

Google ha ido incorporando aplicaciones a su sitio web sin ningún tipo de orden con el único criterio de "lo hemos lanzado".

Algunas aplicaciones están accesibles desde la portada, otras desde el "more" y dentro del more la división responde a un criterio interno de Google de "Services" y "Tools".

Por lo general es muy complicado reorganizar la estructura de una empresa para acomodar las necesidades del usuario.

Este problema viene del origen propio de las empresas. Hay muy pocas empresas que se dirigen a consumidores finales. La mayoría de las empresas se dedican a B2B y una gran mayoría de todas las empresas en general están dirigidas por personas que están centradas en aspectos de producción, fabricación o distribución y no en el marketing o comunicación.

La arquitectura de la información para este tipo de empresas suele ser un proceso complejo de digerir.

Su lenguaje se basa en aspectos internos, productos, sistemas, fabricación.

Este lenguaje interno de la empresa asumirse inicialmente como válido intentando darle su lugar dentro de una arquitectura con un lenguaje algo más claro.

Un método de trabajo

Con las empresas el método de trabajo suele pasar por conocer su lenguaje y entorno.

Como hemos dicho antes, la mayoría de las empresas se dirigen a otras empresas y por tanto el lenguaje del sector suele ser el apropiado. Un lenguaje técnico, profesional, directo es el adecuado y por tanto debemos escuchar y aprender del cliente lo que tenga que decirnos sobre como comunicar su producto.

Este lenguaje se ha de contrastar con el del sector y sobre todo con los líderes del mismo.

Por lo general existen muchas dudas a la hora de posicionar productos o servicios en la web.

¿Se ha de comunicar el servicio, los productos resultantes, las herramientas (en caso de ser conocidas)...?

Aquí es donde el arquitecto de la información entra en juego y ha de resolver el problema proponiendo soluciones que ayuden a expresar de la manera más acertada posible la información del cliente.

Podríamos decir que la solución suele pasar por emplear todas las posibilidades de comunicación priorizando aquellas que puedan ser más relevantes.

Ejemplo:

Esta empresa a su vez tiene especial potencial en el flash.

Un arquitecto de la información debería conocer las necesidades de los usuarios (como hemos visto antes) y junto a eso ordenar las necesidades del cliente.

Por las necesidades del usuario podrían aparecer términos como "folleto", "diseño", "logotipo"... y cosas así.

Con todos estos términos el Arquitecto de la información debería plantear el siguiente esquema.

Para convertir esto en una navegación, uno tendría que ver webs de la competencia y entonces podría proponer algo del siguiente estilo...

Con esta navegación ya podemos empezar a pintar el site y las páginas de contenido que son los siguientes pasos en el esquema de Jesse James.

Resumen de los pasos iniciales de la Arquitectura de la Información

1. Conocer las necesidades del usuario.
1.1. Conocer al usuario de Internet en su contexto real.

2. Conocer las necesidades de la empresa.
2.2. Escuchar al cliente por que en un 80% de los casos el lenguaje de la empresa es el correcto.

3. Resolver los problemas dentro de este contexto y no inventando nuevos productos, términos que sean ajenos a la empresa.

Creo que es muy importante que la labor del Arquitecto de la Información esté dentro del contexto real de la empresa. Si uno sabe como resolver la arquitectura dentro de la terminología propia de la empresa el producto final es más creíble y por otro lado es más cercano a la propia empresa y por tanto será mejor desarrollado en el futuro. Si el producto final es ajeno a la jerga propia de la empresa, será complejo de mantener, actualizar, mantener.

---

Las vírgenes tienen muchas navidades pero ninguna Nochebuena.

Uno de los temas más comentados en cualquier foro en los últimos meses es el papel que juegan los enlaces recíprocos en Google. Un tema de consideración ya que el carácter recíproco de los enlaces es algo muy común en muchos intercambios de enlaces. Desde la conocida actualización Florida, que Google llevo a cabo hace un año, han surgido diversos rumores sobre los intercambios de enlaces y las posibilidades de que los enlaces recíprocos estén devaluados o hayan perdido todo su valor.

Los enlaces recíprocos no están devaluados, ni penalizados, ni han perdido valor. Los intercambios de enlaces (recíprocos o no) siguen jugando un papel fundamental en la metodología SEO.

¿Páginas o Webs?
Debemos distinguir entre web y páginas (o página web). Web es un conjunto de páginas alojadas bajo un mismo dominio. Página es cada uno de los documentos individuales -normalmente con URL propia- de un dominio (de la web). Google, a la hora de proporcionar los resultados de una búsqueda, nos devuelve páginas concretas, no dominios (webs). Google posiciona las páginas de las webs individualmente. El papel de otras páginas del mismo dominio puede jugar a nuestro favor, pero a la hora de que una página sea listada en Google, el resto de páginas del dominio son vistas como factores externos. Nosotros, en nuestras webs, podemos verlas como factores on the page, porque están bajo nuestro control, y podemos jugar con la estructura de la web, con el anchor text que apunte a una página determinada, con el número de enlaces que reciba a nivel interno del propio dominio, etc. Pero Google, ve una página, y en sus resultados la posiciona individualmente, independientemente del resto de los contenidos del dominio. Si todo el dominio habla del mismo tema que esa página, sólo jugará a su favor, si tiene enlaces hacia esa página desde otras páginas (si están relacionadas mejor) del dominio. A efectos de posicionar una sola página de una web, tener 1000 páginas en el mismo dominio que hablen de lo mismo, pero que no estén enlazadas entre ellas, sería como tener 1000 páginas diferentes en dominios diferentes sin enlazarlas.

Hay un caso en el que Google favorece a las páginas del mismo dominio. Cuando hay dos páginas de un misma web dentro de la página de resultados de búsqueda, Google agrupa la que ocupa el peor lugar justo después de la primera. Me explico: si tenemos configurado Google para mostrar 10 resultados por página, y yo tengo una página en la segunda posición de una búsqueda, si otra página de ese dominio alcanza la décima posición, automáticamente pasa al tercer puesto, es agrupada de forma consecutiva con la otra página del dominio. Si tenemos Google configurado para mostrar 100 resultados por página y tenemos la quinta posición y la nonagésimo novena, ésta última saldrá listada en la sexta posición. Podemos establecer como regla general:

Cuando en la misma página de resultados de Google salen listadas dos páginas del mismo dominio en posiciones no consecutivas, Google agrupa las dos páginas, de forma que la que ocupa el peor puesto de las dos, es listada a continuación de la que ocupa el mejor puesto de ambas.

¿Qué es un Enlace Recíproco?
Ahora que hemos explicado que Google valora páginas individuales en sus resultados y no dominios, podemos establecer que un enlace recíproco es aquel que tiene sentido bidirecciónal entre dos páginas. Dicho de otra forma: La página "A" apunta a "B", y la página "B" enlaza a "A".

A veces se habla de enlaces recíprocos cuando hay enlaces bidireccionales entre dos dominios, pero no entre las mismas páginas. Explicado: Tenemos un dominio "D1" y un dominio "D2. "D1" tiene una página "A" que apunta a una página "C" del dominio "D2". "D2" tiene una página "B" que enlaza a la página "A" de "D1". Sean "D1" y "D2" dominios difentes, "A" una página del dominio "D1", "B" y "C" páginas diferentes del dominio "D2", y "z -> x" representa un enlace de "z" a "x". Tenemos:

D1.A -> D2.C y D2.B -> D1.A

¿Podemos considerarlos enlaces recíprocos? Si bien son enlaces entre dominios, no deben considerarse enlaces recíprocos, ya que hay infinitas posibilidades de que se dé este caso, y es prácticamente imposible de controlar. No representa ningún riesgo este tipo de intercambios. Pensemos en el mundo de los blogs, prácticamente todos los enlaces serían recíprocos, la mayoría hemos enlazado a casi todos los blogs que nos han enlazado en algún que otro post.

¿Qué se ha devaluado?
Hace una año eran muy comunes los intercambios de enlaces desde todas las páginas de una web hacia la página principal de otra web, y desde todas las páginas de esta segunda web también se enlazaba a la página principal de la primera web, con esto se conseguía un importante aumento del PageRank, así como un buen número de enlaces con el mismo texto. Era una forma rápida y efectiva de lograr miles de enlaces intercambiando con una sola web. Google ha devaluado los enlaces que provienen desde las IPs que tienen en común los tres primeros bytes. Así que ese método de intercambio ha perdido mucho valor, ya que se lograban sólo enlaces desde una misma IP por cada web con la que intercambiábamos. Ahora es mucho más interesante la idea de conseguir sólo 5 enlaces desde 5 IPs (variando los tres primeros octetos) diferentes, que 1000 enlaces desde una misma IP.

Éste fue uno de los motivos que impulsó la creencia de que los enlaces recíprocos estaban devaluados. Era fácil comprobar que esos enlaces no funcionaban para mejorar posiciones como lo hacían antes, pero lo devaluado no era el enlace en sí por el hecho de ser recíproco, era la procedencia de enlaces masivos desde la misma IP.

Recíprocos vs. No Recíprocos
Es muy frecuente leer que es mejor un enlace unidireccional que bidireccional, que es mejor un enlace no recíproco que uno no recíproco. Esto es falso, y lo que debe imperar es el sentido común. Lo mejor son los enlaces que se ponen de forma natural, sin realizar intercambios, los enlaces entre páginas relacionadas, y que aportan algo al usuario que está leyendo los contenidos de la página donde va el enlace. Está comprobado que estos enlaces son siempre los que más visitas proporcionan a otras páginas web. Son los enlaces donde más fácil nos resulta hacer un click de ratón. El carácter recíproco del enlace no tiene nada que ver con su valor, hay muchos más factores: la posición del enlace, el texto que lo rodea, el tener más enlaces desde esa misma IP, etc.

Los enlaces entre páginas relacionados son la mejor forma de subir posiciones en Google, ya sean recíprocos o no. Simplemente porque el que sean recíprocos no perjudica en nada. Se pueden observar grandes beneficios con intercambios de enlaces entre páginas que compiten por la misma búsqueda. Estos enlaces son de gran valor para el usuario, y Google sabe valorarlos en su justa medida. Si lo que se valora son los enlaces naturales, lo adecuado es hacer intercambios de enlaces naturales. Tal vez no enlacemos a otra web por el simple hecho de que sea de la competencia, pero los usuarios, y por tanto los buscadores, saben valorar ese tipo de enlaces positivamente. Porque están relacionados, porque ofrecen una continuación a ese página, porque es una aportación de contenido útil, y si el enlace se hace recíproco... ¿Qué importa?

Peligros
No representa ningún peligro utilizar enlaces recíprocos en intercambios de enlaces. Lo peligroso son los grandes anillos que a veces se forman. Las webs que intercambian enlaces suelen hacerlo siempre con las mismas, de forma que es una rueda que crece. Primero empiezan 10, luego 20, 30, etc, y más tarde Google detecta que hay una red de páginas con un número de enlaces entre ellas nada natural, y decide que pierdan valor. No llega a banear, o a realizar una penalización, detecta esas páginas como afiliadas, y todo el peso de los enlaces, todo lo positivo que nos aportaban en temas de posicionamiento, se pierde. Es algo normal, porque es poco natural que 50 páginas se enlacen todas entre sí, y no digamos si enlazan entre todas las páginas que contiene cada web, pero en su justa medida sigue siendo un arma muy efectiva en temas de posicionamiento en buscadores.

Las penalizaciones a grandes anillos de enlaces en los que participan un número muy elevado de páginas... ¿tienen algo que ver con los enlaces recíprocos? No.

Dicen que un mal artesano siempre le echa la culpa a sus herramientas. Y tienen razón. No importa lo buena que sea la herramienta, es la destreza de la persona que la utiliza lo que produce buenos resultados.

Este artículo esboza los cinco pasos necesarios para obtener resultados más profesionales con Dreamweaver MX.

Paso 1: Exporte JavaScript y CSS a archivos externos

Aunque crea que mantener todo el código en una página base es más conveniente para la edición, es un gran desperdicio de ancho de banda. Si retira el código JavaScript y CSS de la sección <head> de cada página y lo pone en archivos centrales, logrará dos cosas útiles:

• Centralizar el código. Si tiene que hacer cambios al código, sólo tiene que hacerlo una vez en lugar de una vez para cada página que lo utiliza.
• Ahorrar ancho de banda. El navegador cliente sólo descarga los archivos de JavaScript y CSS una vez, en lugar de una vez por página.

Para lograr esta tarea, primero busque las funciones de JavaScript en la sección <head> de su documento. El siguiente es un ejemplo típico:

Copie cualquier función en un nuevo archivo de texto y guárdelo con el nombre common.js, por ejemplo. Cree vínculos al mismo en la sección <head> de cada página de su sitio (o póngalo en su plantilla), como sigue:

Busque el código CSS en la sección <head> de sus páginas, cópielo al nuevo archivo de texto y guárdelo con el nombre mystyles.css, por ejemplo. Lo siguiente es lo que hay que buscar en la sección <head>:

Vincule el archivo CSS a la página web mediante un vínculo al archivo CSS en la sección <head> de la página:

Paso 2: Exporte su sitio sin marcación de plantilla
Dreamweaver MX usa comentarios HTML para almacenar metadatos dentro de documentos. Estos comentarios permiten que funcionen las características tales como plantillas y elementos de biblioteca. Si bien estas características son muy útiles mientras se crea un sitio, estos comentarios pueden desperdiciar ancho de banda y dar a sus páginas un aspecto poco profesional una vez que sus archivos se encuentren en el sitio web de producción.

Dreamweaver puede retirar estos comentarios y producir una nueva versión limpia del sitio. (Pero no pierda los comentarios de la versión en la que está trabajando, de lo contrario la plantilla podría romperse.) Para hacer esto, elija Modificar > Plantillas> Exportar sin formato desde su sitio. Navegue a una nueva ubicación para su sitio ya limpio y haga clic en Aceptar.

Paso 3: Prepare su sitio para el futuro con XHTML
HTML ha llegado al final de su vida y ya no se desarrolla como un lenguaje de marcación. Su reemplazo es HTML ampliable (en inglés) (XHTML): una implementación de XML que funciona en todos los navegadores, tanto los antiguos como los nuevos. Aunque XHTML es puro XML, sus etiquetas y atributos son tan similares a HTML que los navegadores antiguos no notan la diferencia. El uso de XML tiene ventajas porque es una norma moderna y preparada para el futuro.

Si hace codificación manual, hay unas cuantas cosas que debería saber acerca de XHTML antes de convertir los archivos. Por ejemplo, la norma XHTML prefiere atributos que no estén vacíos y etiquetas correctamente emparejadas y anidadas.

Si trabaja en un entorno visual como la mayoría de usuarios, es fácil convertir sus páginas en maravillas de XHTML:
• Si está por empezar una página nueva, no deje de marcar la opción Hacer el documento compatible con XHTML en la esquina inferior de la ventana Nuevo documento.
• Si tiene una página existente en HTML, conviértala a XHTML seleccionando Archivo> Convertir > XHTML.
Facilísimo.

Paso 4: Ordene el código con el comando Aplicar formato de origen

En las páginas largas y complejas, el usuario no tarda en desorientarse usando la vista de código. Cualquier programador profesional le puede decir lo importante que es tener código bien presentado y con sangrías cuidadosamente insertadas.

Los siguientes son algunos de los beneficios de tener un código con un buen formato:
• Nunca se sabe quién va a hacer cambios al código una vez que usted termina. ¿Qué pasa si su cliente solicita cambios mientras usted está de vacaciones? Su compañero de trabajo debería poder mirar la página y entenderla.
• Lo que parece claro hoy día, podría no serlo de aquí en cuatro meses. Aun si usted mismo edita la página dentro de unos meses, es posible que su familiaridad con el código ahora ya no sea igual y no le ayude a entender el código más tarde. Un formato de código ordenado le permite leer el código con mayor claridad.
• ¿Qué pasa si le entra la curiosidad al cliente y mira el código fuente en su sitio? ¿Prefiere que vea un gran desorden o un código ordenado que da la impresión que cada etiqueta hubiese sido colocada con el mayor cuidado posible? (Me sospecho que lo segundo.)
Esto no quiere decir que se tiene que pasar siglos ordenando su página antes de cargarla en el servidor. Dreamweaver MX le facilita las cosas: elija Comandos > Aplicar formato de origen después de editar una página, y ya está.

Paso 5: Valide la página para buscar errores básicos
Le sorprendería saber cuántos desarrolladores profesionales del web no saben que existen herramientas para ayudarles a arreglar su código. Se pueden eliminar la mayoría de los problemas de compatibilidad de navegadores de una página con sólo verificar si el código es correcto, pasándolo por un validador. La parte más difícil de corregir problemas pequeños es encontrarlos en primer lugar. Para eso sirve el validador.

Los usuarios de Dreamweaver MX tienen dos maneras de validar su código. La primera manera es en Dreamweaver. Asegúrese de que ha guardado la página en la que está trabajando. Luego seleccione Archivo > Comprobar página. Seleccione ya sea Validar formato si la página es HTML o Validar como XML si la página es XHTML. El panel Resultados aparecerá con una lista de los problemas que ha encontrado.

La segunda manera de validar la página es utilizar la herramienta de validación en línea del World Wide Web Consortium (W3C). Puede validar todos los tipos de HTML y XHTML, así como archivos CSS. Los validadores se encuentran en el sitio web del W3C:
• Servicios de validación de HTML y XHTML (http://validator.w3.org/ (en inglés) )
• Servicio de validación de CSS (http://jigsaw.w3.org/css-validator/ (en inglés) )

Es realmente asombroso ver la diferencia en la página después de corregir errores menores. Por ejemplo, una etiqueta mal anidada puede impedir que aparezca una página en un navegador pero permitir que aparezca sin problemas en otro. Sólo esto es una gran razón para dejar que los validadores de código hagan el trabajo difícil por usted.

Pff… Ahora si que he estado desaparecido mi gente. Me disculpo, pero he tenido un periodo de mucho estrés, sustos, trabajo, gastos… en fin. Me ha sido imposible postearles algo por aquí. Pero heme aquí, haciendo un tiempesito para revivir el blog un poco.

Cansado de ver muchas prácticas poco aconsejables (y que, honestamente, hasta hace poco yo también cometía) y como la excusa perfecta para darles a conocer que sigo vivito y coleando (aunque aún sumamente ocupado), he decidido escribir sobre los 8 grandes errores del diseño web actual. Estas son prácticas que el mundo de la web 2.0, los estándares web y, por sobre todo, la idea de separar la presentación del contenido nos han metido en la cabeza y la mayoría de las veces las hemos seguido sin ponernos a pensar un poquito en las consecuencias.

Primero que nada, vamos a definir diseño web. Diseño web abarca ya no solo lo visual; es toda una ciencia que involucra accesibilidad, apariencia, presentación, contenido, contexto, mensaje e interactividad (si no es que más). Un diseñador web debe ser capaz de, a partir de una idea, generar una solución virtual. Ojo con la palabra: solución. Y para generar una solución, necesitamos tener un problema para empezar. En el caso generalizado de la web, el problema a resolver es el manejar información. Ya sea presentando o editando, visual o auditiva, útil o no tanto; la web es información y nada más. Cómo la manejamos depende de las necesidades que tengamos, y es aquí donde cometemos los 8 grandes errores del diseño web:

¡Las imágenes también son contenido!
Técnicas como Fahrner Image Replacement han hecho una maravilla para reemplazar texto por imágenes. Ya no tenemos que depender de la fuente que tiene instalado el usuario, sino que hacemos nuestra imagen como queramos y todo queda bello y ahora también podemos crear código “semanticamente correcto”. Pero como con toda gran solución, viene un gran problema… en este caso, dos.

No me malentiendan. La técnica (o más mejor bien dicho, las técnicas) en si es muy buena y cumple su cometido, además de ser un excelente impulsor visual para nuestras páginas. Los dos problemas que nos encontramos vienen de nuestro lado, de la práctica y no la teoría.

Mal uso de la técnica
El primer problema es el mal uso de la técnica. Muchos pensaran “¡Obviamente! Cualquier cosa mal usada es un problema.” y tienen toda la razón, pero aquí la cosa es que el 99% de las personas que reemplazan imágenes por texto usando CSS no tienen idea de que lo están haciendo mal. Y no la tienen porque no la ven. Ven su texto reemplazado y bien alineado y la dejan por la paz. ¿Pero y si alguien intenta accesar a la página mediante otro dispositivo? Todas las técnicas conocidas al día de hoy tienen un problema con algún dispositivo (vamos, que incluso con algún navegador). Acciones como imprimir la página, verla en un celular, usar IE5, accesar la web usando un screen reader, etc. pueden verse afectadas por esta técnica al grado de perder completamente la información que queremos mostrar con nuestra imagen. ¡Imaginen que el logo de su empresa no aparezca cuando alguien manda a imprimir una página de su web! Simplemente no es aceptable.

¿Y por qué digo que es un mal uso? Pues porque la técnica de reemplazo de imagenes es para un tipo de media, y uno solo: screen (que significa pantalla). Una impresora no debería tener el image replacement. ¿Por qué? Porque la impresora no va a imprimir la imagen de fondo ni el texto escondido; tendremos un espacio en blanco. Lo mismo para un screenreader; es muy probable que ignore el contenido. Si vamos a usar el image-replacement, deberíamos de definir que es solo para el screen y no otro tipo de media, o definir diferentes reglas para los diferentes tipos de media.

Abuso de la técnica
Hace unos cuantos días me topé con una web de negocios donde tenían un bonito recuadro con una imagen flotando a la derecha que describía su más reciente promoción. Al intentar copy-pastear el contenido me dí cuenta de que era una imagen de fondo. Después de investigar un poco más a fondo, me dí cuenta, horrorizado, de que era un párrafo con texto reemplazado. Eso mismo me hizo recordar varios ejemplos, el más drástico siendo una galería de imagenes que reemplazaba párrafos por una imagen según su id. Ahora bien, yo les pregunto, ¿qué la imagen no es contenido también? ¿Qué poner la tag <img> es tan malo? ¿Qué el atributo ala y title no son suficientes para describir la imagen?

Y vamos, que no solo nos vamos a imagenes de contenido. Otro ejemplo es el logo de una compañía. Un anchor con una imagen dentro y unos buenos atributos ala y title son más que suficientes (y semánticamente correctos) para el logo de una web; e incluso nos da la oportunidad de convertir el tag h1 en lo que verdaderamente es: el título de la página (y no el nombre de la empresa y/o de la web). De esta manera, el logo y el nombre de la empresa serían una imagen hasta arriba, y nuestra tag <h1> sería el título de la página que estamos viendo (por ejemplo: el título del post en un blog).

Mi recomendación:
Analicen bien la técnica que están utilizando para reemplazar texto por imágenes y encuentren sus debilidades; una vez detectadas, contraarrestenlas y no den lugar a fallos. La información de la web es muy importante, y perderla por una mala maquetación habla muy mal del desarrollador y de la empresa. Algunas de las soluciones para la mayoría de los problemas sería:
• Utilizar otras hojas de estilos para diferentes tipos de media.
• El uso apropiado de la tag <img> y de los atributos alt y title.
• Analizar correctamente la página y decidir en qué momento usar una imagen y en qué momento usar texto para disminuir el abuso.

¡No todo es una lista!
Todos sabemos que con CSS y una simple lista en HTML podemos hacer maravillas y menús que nunca nos habríamos imaginado. Pero parece que tendemos a abusar de esta flexibilidad al punto de perder el contexto por meter listas.

El punto es que no todo es una lista. Los menús son una lista de secciones a las que puedes acceder; lo mismo con un breadcrumb, por ejemplo; pero ¿una oración sería una lista de palabras? Digo, es un ejemplo algo drástico, pero es para demostrar el punto: abusamos de esta técnica. Al punto de que he visto (y también me declaro culpable de esto) una lista de DOS links: login-register. ¿Eso les parece una lista? Claro que no, porque no lo es.

La idea de que “un menú es una lista” se ha desviado mucho de su realidad. Muchos desarrolladores meten listas al por mayor y, en algunos casos, limítan la cantidad de elementos que pueden entrar por cuestiones de dimensión. También se da el caso de tener problemas al cambiar una propiedad global a la tag <ul> y afecta a nuestras otras listas, teniendo que agregar un estilo que sea inversamente proporcional al que asignamos globalmente.

Un ejemplo
¿Te sonó confuso lo anterior? Vale, vamos a poner un ejemplo:

Supongamos que tenemos el siguiente HTML:

Y su CSS:

Como pueden ver, la tag <li> no tiene el atributo margin declarado. Ahora vamos a pensar que queremos darle estilo a todas nuestras listas de contenido, y por alguna razón, necesitamos agregar el atributo “margin-left: 50px“. Simplemente agregaríamos algo como esto a nuestro css:

Si volvemos a nuestro menú verás que se ha roto. Para corregir el error, tendríamos que ir a nuestro CSS y especificar claramente que para esta lista el margen izquierdo es 0:

Incluso tal vez tendríamos que usar el !important para hacer que funcione. Esto fue un ejemplo burdo, pero imagínense tener que arreglar 5 o 6 menus que tienen el mismo problema. Ahora imagínense tener que corregir no solo uno, sino varios atributos para cada menú. El resultado sería un CSS enorme y poco práctico, o un HTML lleno de clases o ids. Y si la especificidad (¿Cómo diablos se dice “specificity” en español?) de los elementos no fue la adecuada, los problemas crecen todavía más.

Mi recomendación
Usar menos listas para los elementos. No todo es una lista, y debemos aprender a identificar cuando usarlas y cuando no.

Mi nombre es h1 h1′ h1”
Encabezados. Esos dichosos encabezados. Esos elementos que separan los segmentos de nuestra web y hacen que la misma sea lineal y jerárquica. Vamos, que es como poner númeraciones (2, 2.1, 2.2, 3, 3.1, 4, 4.1, 4.1.2, etc.), pero aquí podemos asignar colores, tamaños, margenes, etc.

Tenemos seis niveles de titulares. SEIS. Sin embargo, casi nunca llegamos a ver ni siquiera el 3 en la mayoría de las webs. Y no digo que TENGAMOS que usarlos; podemos tener una web con pocos contenidos; pero caemos en un problema enorme al momento de usar los titulares: repetimos los niveles.

Los niveles desde mi punto de vista
Pondré el ejemplo más práctico que se me pudo ocurrir: miren esta web. Si si, la misma que estás leyendo en estos momentos. ¿Cómo dirías que se llama la web? Ah, pues fácil, miras arriba de tu navegador y miras lo que dice: “sitioweb » Blog Archive » Algunos errores del diseño web” Ah, muy bien. Pero eso es como un breadcrumb. Esta página, la que estás viendo en ESTOS momentos, ¿Cómo se llama?

Aquí entramos en un poco de discusión: ¿El título de la página es el nombre del sitio (sitioweb) o el nombre del post que estoy viendo (Algunos errores del diseño web)? No vamos a entrar mucho en detalle, ni yo mismo estoy seguro de esto; pero una cosa si es segura: sea cual sea, solo existe
UN título de la página.

Para este ejemplo, diré que el nombre del blog es el nombre de la página que estamos viendo. Por lo tanto, dentro de nuestra tag <h1> iría “sitioweb”. Este <h1> debería ser el ÚNICO de toda la página; pues no existe ningún elemento de mayor o igual jerarquía que él. Debajo de este pueden ir infinidad de <h2>, <h3>, <h4>, <h5> y <h6>’s que podemos agregar a diestra y siniestra; y aquí vamos a ver un nuevo problema: la mala jerarquización de nuestras páginas.

Jerarquías en tu web
Estructuralmente hablando, lo lógico es que no exista un <h3> en tu código si no existe un <h2> y un <h1> antes del mismo. Esto también tiene un poco de debate, puesto que puede que en tu HTML tengas en desorden los encabezados, pero usando CSS los coloques correctamente; aunque globalmente hablando, no debería de pasar.

El problema que quiero mencionarles es la mala colocación de los encabezados. Veamos el ejemplo anterior: El título de la web es <h1>sitioweb</h1>; el siguiente sería el título de la página que estamos viendo, es decir, <h2>Algunos errores del diseño web</h2>. Aquí es donde empiezan los conflictos, y es que la gente suele usar <h2> para los títulos de los menus (incluso otro <h1>), digamos; y no están al mismo nivel jerárquico. Hay que determinar bien qué elemento va en qué nivel de jerarquía.

La solución
Analizar bien el documento antes de empezar a codificaro. Debemos determinar perfectamente bien qué elemento es un encabezado y qué jerarquía tiene. Esto va a variar mucho de web en web, pero lo que si es seguro es que NO debemos tener más de un <h1> por HTML.

Los hacks no son una solución, son un problema
Hace tiempo ví en la web unacuriosa gráfica que mostraba el tiempo empleado desarrollando una web. Todavía no puedo evitar sonreír al verla. En esta gráfica verán que el punto más grande y el que toma más tiempo (y lo más triste es que no es exageración) es el de “Intentando que el maldito sitio web funcione en el puto Internet Explorer“.

Una de cada dos veces, si no es que todas las veces, debemos corregir errores que Internet Explorer (u otro navegador) nos da al momento de mostrar nuestra web. Vamos, que con tantas opciones y tantos motores sería difícil que las diferencias no existieran. El problema es que, muchas veces, el navegador que nos muestra el error es el ÚNICO navegador que muestra ese error. Todos los demás funcionan perfectamente. Esto quiere decir que tenemos que, de alguna manera, modificar solamente ese navegador y nada más que ese navegador.

Los hacks, ¿una solución?
Para este tipo de errores, nos dirigimos directamente a google y escribimos algo como “<nombre del navegador> <palabras clave del error> css hack”. Y google nos regresa un sin fin de resultados; todos solucionan nuestro problema, lo aplicamos y tenemos una página que se ve bien en todos los navegadores (aunque no necesariamente valide bajo la W3C).

El problema viene cuando el navegador saca una actualización y corrige el error que te orilló a usar el hack de primer instancia. ¿Qué pasa? Pues todo se jode. La nueva regla que usaste mediante el hack también es leída por la nueva versión del navegador y al aplicar el hack, se jode todo. (de ahí que considere que la elección de microsoft de eliminar el star hack fue una excelente decisión).
Dejando de lado el hecho de que la mayoría de los hacks no son válidos bajo la W3C) y que no sabemos las consecuencias que vayan a tener en otros navegadores; el simple hecho de que el mismo navegador para el que fue aplicado corriga el error y sea posible que el hack le afecte de manera negativa debería ser razón suficiente para no utilizarlo.

¿La solución?
Curiosamente, para casi todos los bugs que existen en cualquier navegador, existe una alternativa correcta y semántica. ¿Por qué no se usan? Porque la mayoría de la gente las desconoce. También es muy probable que el error sea por una mala elección en la manera de hacer el CSS (demasiados floats, por ejemplo).

Realmente no creo que haya una “solución” concreta para este caso, mas que el dejar los hacks como ÚLTIMO RECURSO, porque en verdad, a la larga, traerán más problemas que soluciones.

¡Hola! Me llamo “naranja”
Quizá el error más tonto de todos, pero también uno de los más repetidos. Digamos que queremos crear la siguiente caja:

Nada difícil. Nuestro HTML:

Y nuestro CSS:

Vamos, en teoría es fácil. Pero aquí está el error: “naranja”. ¿Qué putas es “naranja”? Pues un color (o una rica fruta). Pero no nos da una idea del contexto. Ni puta idea del contexto, en realidad. Solo nos dice “naranja”. Ok, es naranja. ¿Qué es naranja? ¿El borde? ¿El color de fondo? ¿El color del texto? ¿El desayuno? Un mejor nombre de clase sería “promocion”. Así ya sabemos que esa división es una promoción, y no un “naranja” (que nos deja muy vagos).

La solución
Si bien en algunos casos el poner un nombre como “naranja” es la mejor opción, también es cierto que muchas de las veces podemos nombrar las clases y/o id’s con títulos mucho más adecuados y contextuales.

¿A none voy?
Ajax nos ha abierto las puertas a un nuevo mundo de aplicaciones, efectos y herramientas para nuestras interfaces de usuario. Es increible la cantidad de cosas que podemos lograr con un poco de javascript, CSS y XHTML.

Una de estas nuevas mejoras es la de enviar formularios automaticamente, sin necesidad de un boton de submit. Esto hace que las consultas ean mucho más rápidas y no se tenga que recargar toda la página.

El error que viene aquí es el no usar javascript no obtrusivo. En terminos burdos, un javascript no obtrusivo (unobtrusive javascript) es aquel que NO es indispensable para la accesibilidad de la web. Vamos, que puedes enviar el formulario sin necesidad de tener javascript activado.

El error en detalle
Como andamos usando de ejemplo el formulario, voy a explicar más o menos de qué trata. Como les dije, ajax nos permite enviar el formulario sin necesidad de enviar el mismo (darle ENTER o pulsar el boton de ENVIAR). Como no necesitamos enviar el formulario, muchos desarrolladores simplemente no lo ponen (o incluso omiten el atributo action en el tag <form>). ¿Qué pasa con los usuarios que tienen javascript desactivado? Se quedan con un formulario que no sirve de nada.

Pero el problema no se limita a formularios. Algunas funciones que jalan con la tag <a> también sufren de este problema. Un ejemplo es la web emuxperts. Si desactivan javascript y visitan la web, no podrán navegarla; pues todos sus hipervínculos son generados por javascript.

Otro ejemplo que encontré fue la pequeña clase para mootools, mootabs. Es un excelente script para generar tabs dinámicas usando javascript, pero tiene un enorme fallo: no utiliza enlaces para generar las tabs. De hecho, si intentas agregar un hipervínculo al <li> (que es lo que usa para generar las pestañas), se llega a romper. Claro que existen soluciones; pero el script en esencia no utiliza enlaces, lo cual te genera un código inaccesible para los usuarios y, peor aún, para los buscadores.

La solución
Siempre que vayas a crear una web, hazla por pasos: primero el contenido, luego el estilo, al final las aplicaciones. De esta manera te asegurarás de que la accesibilidad no sea sacrificada al momento de crear las aplicaciones. Las aplicaciones deben adaptarse al contenido, no al revés. Si tienes un formulario que se envía solo, agrega el menú en tu código y eliminalo o desactivalo en tu javascript; pero dejalo en el código.

Este es un error que muchos desarrolladores están aprendiendo a omitir, y gracias a la tendencia del javascript inobtrusivo, está desapareciendo poco a poco; pero aún se repite mucho y es la razón de que esté en esta entrada.

¡No soy gordo! ¡Soy funcional!
Con la llegada de los frameworks de javascript hemos visto tanta variedad que es difícil elegir una sola librería. Tenemos mootools por aquí, prototype y scriptaculous por acá, jquery por allá, google web tool kit por acuyá… en fin, tenemos miles de opciones.

Lo bonito de todas estas librerías (y el origen de este problema) es la gran variedad de scripts que se han creado. Como ejemplo basta ver la cantidad impresionante de clones de lightbox que existen. Y como estos, tenemos miles de scripts que podemos usar.

El problema
Con tantos efectos y aplicaciones en la web, es difícil no caer en la tentación de querer usarlos. Y como no, si son más amigables de usar para los usuarios, incrementan la accesibilidad, aceleran y facilitan la navegación. Vamos, son una maravilla. El problema viene cuando usamos scripts de más.

Vamos, creamos nuestra web y queremos tener un lightbox hecho con mootools, los chorrocientosmil efectos de scriptaculous, un script independiente para ordenar tablas, uno para generar directorios en forma de árbol, uno para buscar mientras el usuario escribe y eliminar el botón de enviar… en fin, llenamos nuestra web con javascript y, en el peor de los casos, con más de una librería.

¿El resultado? Una web impresionante, visualmente hablando, con miles de funciones y elementos que pretenden aumentar la accesibilidad y dejar al usuario contento; pero que pesa cerca del medio mega en puro código. El simple hecho de meter una librería de javascript a tu web aumenta el peso de la misma en unos 50kbs, aprox. A eso hay que sumarle los scripts que le vamos añadiendo, cada uno oscilando entre los 3 y los 25kbs. Sumale el peso de tu XHTML, de tu CSS, las imagenes… pff. Terminas con una web demasiado pesada para lo que en realidad debería ser.

¿La solución?
Usar solo el javascript absolutamente necesario. No dejar de usarlo, solo dejar de usarlo TANTO. Si un script no está en la librería que están usando, intenten crear el suyo propio. Y, por sobre todo, no olviden orientar su web al público al que van dirigídos y al tráfico que tienen contemplado. Analicen bien su aplicación.

Las tablas no son de satanás, ¡úsalas!
Por la web circula la palabra “tableless” para referirse a un diseño web sin tablas (es decir, estructurado a puro div). Miles de páginas de desarrollo web han recalcado hasta el hastío que las tablas no deben ser usadas para el layout de una página web, y no podrían tener más razón.

Pero los desarrolladores web han caído en la idea de que las tablas son malas, y deben evitarse a toda costa. Incluso he visto gente que ha intentado crear una tabla usando divs y CSS nada más. Eso ha sido el peor error de semántica que yo haya podido presenciar en mi vida.

El problema de las tablas
Digamos que tienes una web de hospedaje y quieres mostrar una comparación rápida de los planes que ofreces. Tienes 3 planes diferentes y unas 10 características que quieres mostrar. La manera correcta es haciendo una tabla, y nada más. La cosa es que muchas veces he visto a los desarrolladores querer usar divs para esto, y obviamente terminan frustrados por no lograr lo que querían.

Ahora bien, no solo existe este problema. Tambien tenemos que, al momento de usar las tablas, no pueden aplicarle el estilo que desean. Vamos, que el simple hecho de aplicar un borde de 1px a las celdas es un poco menos obvio de lo que parece. Mas cuando queremos agregar estilos a las celdas, a los encabezados, etc. Terminamos usando cientos de clases diferentes para algo que nos tomaría solo una o dos clases. El problema es que no sabemos darle estilo a nuestras tablas. Es más, nos abemos ni siquiera todos los elementos que la tabla puede tener y que nos sirve para darle estilo a la misma.

¿La solución?
Entender que las tablas no son malas cuando las aplicas para lo que deben de ser aplicadas: datos tabulares. Tambien debemos aprender todos los elementos que nos sirven para darle estilo a nuestras tablas y poder tener un buen manejo de las mismas mediante CSS.

Con esto termino este post. Algo largo, y me faltó profundizar un poco en algunas cosas, pero el tiempo a duras penas y me da para escribir esto. Espero poder escribir más seguido, ¡mi gente! Que tengo varias entradas guardadas por ahí. Entre ellas una revisión a varios post que he hecho antes, con mejores y apuntes que no conocía al momento.