¿Cuál es el lugar del <h1>?

Intentaré resumir en este artículo el debate acerca del elemento <h1> que se generó en la lista de correo de Frontend Spain. ¿Dónde colocarlo?, ¿cuántos debe haber en una página? y ¿cuál debería ser su relación con el resto de los headings?

La pregunta de la que surgió el debate era sencilla: ¿cuál debería ser el lugar del <h1>?, ¿en el logo de la cabecera o en el titulo del artículo principal de la página?. Veamos las conclusiones que se alcanzaron.

¿Cuál es el elemento más importante de la página?

Esta es la pregunta que debemos respondernos a la hora de decidir que elemento irá marcado como <h1>. La W3C describe el elemento heading de la siguiente manera:

Un elemento heading describe brevemente el tema de la sección que encabeza (A heading element briefly describes the topic of the section it introduces).

En el caso del <h1>, al tratarse de el encabezado de mayor nivel, se entiende que la sección que encabeza es el contenido principal de la pagina.

A partir de aquí, podemos inferir que si se trata de la página principal, su objetivo es el de introducir el sitio, por lo que el <h1> se podría asignar a la sección de branding, mientras que si nos encontramos en una página de artículo dentro de un blog o en una ficha de producto en un sitio de ecommerce, el <h1> irá a marcar el título del articulo o el nombre del producto. En este excelente post del blog CSS Wizardry el autor nos da más información sobre como marcar el logo.

¿Cuántos <h1> puede haber en la misma página?

¿Y que pasa si en una página tengo varias secciones de igual relevancia cada una con su titular? En torno a este tema existe cierta confusión, pudiéndose leer en la web que es incorrecto que exista más de un <h1> en la misma página o que de haberlos, se está perjudicando al SEO.

La especificación oficial en ningun momento dictamina cuántos <h1> puede haber dentro de una página. La confusión se debe a que las pautas de accesibilidad WCAG 1.0 efectívamente limitaron este número y obligaban a ponerlo al principio de la página, pero con las WCAG 2.0 se rectificó.

En cuanto al tema SEO, es cierto que algunas extensiones como SEO Doctor, despliegan  una advertencia cuando encuentran más de un <h1> pero no llegan a considerarlo un error. Por otra parte Google mismo, a través de su canal de Youtube para webmasters responde que la cantidad de elementos <h1> en una misma página no afecta el Page Rank, siempre y cuando se utilicen de manera lógica de acuerdo a las necesidades de la página y no en un intento de engañar a los motores de búsqueda (lo que efectivamente puede derivar en una penalización).

¿Cómo deben relacionarse los <h1> con el resto de los Headings?

Lo importante, a la hora de repartir los headings dentro de una página, es no perder de vista su condición jerárquica. Al igual que pasa al poner más de un <h1>, algunas herramientas SEO arrojan advertencias si se coloca un elemento heading sin haber colocado antes otro heading de nivel superior, por ejemplo si ponemos en una web un <h2> sin tener por encima un <h1>.

Una vez más no hay nada en la especificación que diga que esto tiene que ser así y Google tampoco es particularmente estricto con este tema, por lo que entendemos que dependiendo el caso es perfectamente válido colocar un <h2> sin necesidad de tener previamente un <h1>, siempre y cuando se mantenga una cierta lógica de jerarquías.

Conclusiones

Está claro que la disposición de los headings no es algo que pueda tomarse a la ligera y requiere de una cierta planificación. Lo principal a tener en cuenta es ¿cuál es el elemento más importante de la página, su razón de ser? Una vez encontrado este elemento le asignamos el <h1> al titular que lo describa y de ahí hacia abajo vamos añadiendo el resto de los titulares siguiendo una estructura jerárquica. Si consideramos que hay más de una sección en la misma página podemos repetir esta estructura las veces que haga falta.

HTML5

Para finalizar hay que apuntar que en HTML5, con la introducción de nuevos elementos estructurales como <section> o <article> podremos tener ordenada de manera más clara nuestra jerarquía de titulares dentro de cada sección. Además contaremos con el elemento <hgroup> para agrupar varios headings a modo de título y subtitulo. Más información en HTML5Doctor:

¿Cómo asignáis vosotros los titulares? Escuchamos vuestras opiniones.

Publicado en Maquetación | 2 comentarios

Y además, usable

If the point of contact between the product and the people becomes a point of friction, then the industrial designer has failed. If, on the other hand, people are made safer, more comfortable, more eager to purchase, more efficient -or just plain happier- the designer has succeeded.

Esta frase de Henry Dreyfuss me la dio a conocer el maestro Javier Cañada y resume a la perfección qué es el diseño de interacción y la experiencia de usuario. Bien podría haber sido una frase de Nielsen, Wroblewski o Don Norman, pero la escribió este diseñador industrial a mediados del siglo pasado en su libro Designing for people.

Después de casi 60 años de esta frase todavía seguimos hablando de las bondades de la usabilidad y la experiencia de usuario, llegando a ser algo que viene “de serie” cuando en muchos casos no lo está. Lo cierto es hoy todo el mundo quiere tener una web usable y centrada en el usuario, incluso sin saber lo que eso significa.

El diseño de interacción no es arquitectura de información, ni test de usuarios, ni prototipos, es la suma y la consecuencia de todo lo anterior (y más). Incluso el concepto moderno de diseño se queda corto, ya que sí, el diseño debe cumplir una función, eliminar el ruido que la impida, pero también debe ser una solución a problemas de negocio como dijo Cordell Ratzlaff en el primer número de Want magazine.

Para las personas que usan la web en lo que se traduce es en una aplicación web eficiente, amigable, hermosa (en lo que al fluir se refiere), en definitiva, un lugar que responde a todas y cada una de sus necesidades sin provocar esa fricción de la que hablaba Dreyfuss.

El cliente obtiene una herramienta perdurable, útil, que agiliza las tareas a las que antes le dedicaba el triple, que le facilita la información que necesita, que mantiene cerca y hace crecer el número de personas que utiliza su producto, y en definitiva, que le hace ganar dinero y tiempo.

Esperamos poder hablar en próximos artículos de cómo ir formándose e iniciándose en el diseño de interacción, en cómo hacer diseño de interacción y en cómo integrarlo dentro de tu empresa. Sirva este primer artículo como declaración de intenciones.

Publicado en Usabilidad, UX y AI | Etiquetado , , , | Deja un comentario

Desarrollo en HTML5 y CSS3

Adam de Boor (Gmail) comentó su intención de reducir sus 443.000 líneas de código JS, actualizando su frontend a HTML5 y CSS3, haciendo que Gmail sea un 12% más rápido. ¿Es el momento de dejar atrás los navegadores más antiguos y desarrollar sólo en HTML5 y CSS3?

HTML5, al contrario que la especificación XHTML2, está pensada para ser retrocompatible (el Doctype es la mínima expresión aceptada por los navegadores antiguos: <!doctype html>; si tu navegador no soporta input type=”mail”, cae por defecto a input type=”text”… pero no se rompe).

Los nuevos tags (article, nav, section, etc) tienen un problema con IE por debajo del 9: no aceptan estilos porque el navegador no los concibe como elementos estilables. Se arregla con una pequeña línea de JS que diga document.createElement(“article”) (para cada nuevo elemento) o directamente agregando la librería desarrollada por Remy Sharp.

Muchos elementos aún no tienen un soporte completo en todos los navegadores, como canvas. Si no puedes evitar usarlos, siempre puedes usar javascript para tener un fallback en caso de no-soporte. Si añadimos también librerías como selectivzr, para poder usar selectores css3, las posibilidades a la hora de maquetar se multiplican.

Remy Sharp llamó “Polyfills” a estas librerías capaces de rellenar huecos de compatibilidad en los navegadores. Aquí hay una lista con un montón de polyfills.

Respecto a que no se vea igual en todos los navegadores, Andy Clarke escribió en un artículo llamado “Ignorance is Bliss” que si no enseñas un mockup en psd a los clientes, sino directamente la maqueta (con sus diferencias entre navegadores, pero que se vea bien en todos), el cliente a veces ni se da cuenta de que su página no se ve igual en IE7 que en Safari, porque solo utiliza un navegador. Está llevado un poco al extremo, pero el caso es que es real, la gente no ve la página en un navegador y luego abre otro para comprobar si es idéntica (sólo lo hacemos nosotros :P), así que con respetar unos mínimos es suficiente, y no hace falta que las esquinas redondeadas de 2px se vean en todos los navegadores.

Sobre la definición del estándard, Jeremy Keith, explica las peleas entre dos consorcios, uno el open source, formado por Firefox y compañía y otro formado por Apple, Microsoft etc. En ese momento había dos estándares, HTML5 y HTML 5 (nótese la diferencia del espacio) puesto que había problemas con la utilización del códec h264 por el cual el consorcio open source no quería pagar derechos de autor por el códec.

En resumen, hoy en día hay fallbacks para casi todo y ya se puede utilizar HTML5 y CSS3, el único “inconveniente” (y viene de lejos aunque se incrementa más con CSS3) viene de parte de algunos clientes que no entienden la naturaleza de la web y pretenden que una web se vea igual en cualquier navegador, hay que saber valorar (y vender!) el “progressive enhancement”como un extra de calidad (que lo es), más que un problema “porque no se ve igual que en IE6″.

Publicado en Maquetación | Etiquetado , , | 1 comentario

La importancia del equipo de frontend en un proyecto web

Siempre se ha valorado la importancia del SEO, del marketing y de la programación de un proyecto web, pero el frontend es precisamente un factor que suele descuidarse bastante, por no conocer el valor que puede aportar.

El  equipo de frontend tiene repercusión en todas las fases de un proyecto:

  • SEO: una buena maquetación ayuda a tener una estructura clara de las páginas a nivel SEO y de la relación entre ellas, ayudando a los bots a mejorar la indexación y reduciendo el peso de las páginas. Además se ayuda a los bots a entender mejor el contenido y la estructura del site.
  • Experiencia de Usuario (UX): El diseño y la arquitectura de la información tienen como misión persuadir al usuario, que se sienta atraido por la página y se sienta cómodo navegando por nuestro portal
  • Backend: Gracias a una maquetación clara, el coste del backend se reduce considerablemente, ya que resulta más fácil y comprensible para los desarrolladores de backend trabajar con el código.
  • Sistemas: Una maqueta limpia, puede reducir el código HTML, CSS y JS entre un 20% y un 60% aproximadamente, reduciendo el peso de cada página y por tanto, liberando carga a los servidores.
  • Márketing: Si el diseño y las campañas definidas por el departamento de márketing están alineados, la efectividad de estas aumentan considerablemente.
  • Finanzas: La reducción del coste de desarrollo del backend y la cantidad de datos transferidos, reduce notablemente el coste económico de un gran proyecto.

Déjate asesorar por profesionales de frontend, pues pueden ayudarte muchísimo con tu proyecto.

Publicado en General | 4 comentarios

Bienvenidos a Frontend Spain

Frontend Spain es la Asociación de desarrolladores frontend y diseñadores web de España y su objetivo es promocionar los perfiles profesionales del desarrollador frontend y el diseñador web.

Frontend Spain realizará encuentros periódicos y organizará charlas formativas y conferencias para dinamizar el sector en España.

La actividad de la asociación se puede seguir a través los siguientes canales:

Para cualquier consulta, puedes ponerte en contacto con la asociación

Publicado en General | Deja un comentario