Archivo de Categoría «General»

Taxonomía y Navegación

General

Para algunos esto puede ser obvio, pero para quienes recién se introducen en Arquitectura de Información es una fuente de confusión constante: la estructura de contenidos no necesariamente es equivalente a la estructura de navegación de un sitio.

La estructura de contenidos o taxonomía de un sitio no tiene por qué, obligatoriamente verse fielmente reflejada en la estructura de navegación principal de un stio. De hecho, un sitio puede presentar múltiples formas de navegación, desde el clásico menú principal, pasando por menús contextuales, vínculos en el contenido, etc., hasta sistemas de búsqueda.

El objetivo de la taxonomía es organizar los contenidos de manera lógica utilizando diversos criterios. Esto permite ordenar los contenidos en un sistema estructurado, relacionado y eventualmente jerarquizado. Pero los modos que dispondremos para utilizar estos contenidos siguen patrones diferentes.

En el caso específico del patrón de menú de navegación principal se presentan secciones o categorías de contenido que se desea destacar, pero que pueden no corresponder exactamente a la misma estructura de clasificación de la taxonomía del sitio.

pict.taxynav.01

El diagrama muestra una estructura simple de contenidos en una relación jerárquica.

El diagrama anterior nos presenta una estructura de contenidos simple con subcategorías. No todas las categorías de primer nivel formarán parte del menú principal de navegación, sólo aquéllas que sea necesario destacar.

pict.taxynav.02

La ilustración muestra un esquema simple del patrón menú de navegación principal que utiliza algunas de las categorías representadas en el diagrama de contenidos anterior.

El esquema de navegación que presentamos arriba pretende ilustrar la situación que estoy tratando de exponer: la estructura de navegación utilizará algunas de las categorías de la taxonomía, pero no necesariamente todas y tampoco será necesario que pertenezcan al mismo nivel.

El criterio mediante el que seleccionaremos los contenidos de la navegación estará relacionado con el modo en que pretendemos guiar el recorrido de los contenidos, aquellos aspectos que necesitamos destacar particularmente. La taxonomía, en tanto, utilizará criterios de organización lógica.

La taxonomía, en cambio, tendrá un rol relevante en el uso de otros mecanismos, como los motores de búsqueda y sistemas facetados de navegación, como catálogos de productos y directorios entre otros. Uno de los lugares en que más probablemente observemos la evidencia de la taxonomía de un sitio será en el uso de los menús de rastros, que representarán la jerarquía de los contenidos en forma descendente hasta la página actual.

Menú de Navegación Principal

General

Problema

Se necesita un mecanismo que permita al usuario navegar globalmente los contenidos de un sitio de un modo consistente y visible desde todas la páginas.

Por qué

El sitio posee un número de categorías de contenidos que se desea destacar y exponer al usuario para facilitar la navegación directa y la localización de la información deseada.

Cuándo

Cuando la estructura de contenidos de un sitio presenta múltiples secciones o categorías que deben ser localizadas fácilmente por el usuario, permitiendo de este modo un acceso directo a las páginas interiores del sitio.

Solución

Utilizar un listado de las secciones más destacadas a las que se desea dar acceso directo. Este listado de categorías o secciones suele presentarse como una barra horizontal en el sector superior de la página, con nombres suficientemente breves, aunque clarificadores y en un número normalmente no superior a 7 ítemes. Aunque el modo más frecuente de disposición es horizontal, también es común que se le utilice verticalmente.

Es común, aunque no particularmente recomendado por factores de usabilidad y accesibilidad, el utilizar sistemas jerarquizados que permiten desplegar subniveles mediante tecnologías de scripting.

Este patrón de navegación está compuesto principalmente por vínculos textuales, sea en forma de texto real o mediante imágenes que representen textos para obtener efectos gráficos específicos.

Ejemplos

pict.menunav.05

La ilustración presenta un menú de navegación en su forma más común por su disposición (cafebabel.com).

pict.menunav.06

Menú de navegación principal en disposición horizontal simple de (zdnet.com).

pict.menunav.01

Wired.com utiliza un menú de navegación principal apoyado en íconos.

pict.menunav.02

AFP.com utiliza un menú de navegació principal jerárquico con el despliegue de un nivel adicional de contenidos.

pict.menunav.03

bews.bbc.co.uk presenta un menpu de navegación principal en disposición lateral a la izquierda de las páginas, en que despliega un número considerable de categorías de navegación.

pict.menunav.04

En computingcentral.msn.com se utiliza un menú de navegación principal lateral simple.

Observaciones

Existen variaciones de este patrón que trataremos separadamente, como aquéllos que utilizan una combinación de tabs o pestañas o sistemas jerárquicos complementarios para permitir el acceso a subniveles.

Referencias

Los logos y marcas que aparecen en esta página son propiedad de sus respectivos dueños. Las capturas de pantalla de sitios de terceros se presentan para efectos ilustrativos y no representan vinculación, aprobación ni otro tipo de relación.

Menú de Rastros

General

Problema

Se necesita un sistema que permita orientar al usuario sobre la ubicación de la página que está leyendo en un sitio web, respecto a la estructura de contenidos global. Esta información debe estar disponible en el contexto de la propia página, por lo que el mapa del sitio no soluciona el problema.

Por qué

Normalmente la estructura de navegación de un sitio no otorga información suficiente que permita ubicar precisamente una página dentro del contexto global de los contenidos de un sitio. Cuando el sitio tiene una estructura de contenidos compuesta de múltiples niveles resulta difícil reconocer la ubicación de las páginas interiores respecto a la arquitectura de información del sitio. Este problema se hace más evidente cuando un usuario ingresa al sitio desde páginas interiores, por ejemplo mediante un vínculo en una página de resultados en un buscador, pero es igualmente relevante para los usuarios que navegan el sitio de modo convencional.

Cuándo

Cuando la estructura de contenidos de un sitio presenta una profundidad mayor a dos niveles y resulta necesario entregar un refuerzo sobre la ubicación de la página respecto a la estructura de contenidos del sitio.

pict.breadbrumbs.01

El diagrama de arquitectura de información simplificado muestra una estructura de contenidos de varios nieveles de profundidad.

Solución

Proveer un sistema jerarquizado de vínculos a las secciones o páginas padre desde la página actual hasta la portada. El sistema debe:

  • Representar claramente la jerarquía descendente hasta la página
  • Utilizar un elemento separador que refuerce esa jerarquía entre cada vínculo
  • Estar orientado de izquierda a derecha y en la parte superior de la página, normalmente bajo el encabezado de la página y sobre los contenidos.

Ocasionalmente se observa el uso de textos como Usted está en: para reforzar la funcionalidad ubicación de este elemento.

pict.breadbrumbs.02

El diagrama muestra la ubicación común de los menús de rastros en una página.

Ejemplos

pict.breadbrumbs.03

Ejemplo de menú de rastros en NYTimes.com.

pict.breadbrumbs.04

Ejemplo de menú de rastros en PCWorld.com.

pict.breadbrumbs.05

Ejemplo de menú de rastros en Reuters.com.

Observaciones

Es preciso hacer notar que el nombre en inglés, breadcrumbs así como la traducción de menú de rastros resulta confuso, dado que el objetivo de este patrón no es informar sobre la ruta de navegación que ha seguido el usuario para llegar a la página en cuestión, sino que informar sobre la ubicación de la página en el contexto de la estructura de contenidos del sitio.

Esto último incluso nos lleva un poco más lejos: en un sitio con una cantidad importante de contenidos, la arquitectura de información no necesariamente reflejará la estructura de navegación. La clasificación de los contenidos puede generar una estructura que no se refleje fielmente en el menú de navegación, por cuanto éste estará compuesto por categorías de navegación que idealmente contendrá accesos directo a zonas de interés específico en el sitio. La decisión entonces es ¿usar categorías de navegación o la clasificación de los contenidos del sitio? Creo que se debería utilizar la clasificación de contenidos del sitio, así como en el mapa del sitio.

Cabe también citar el ejemplo que presenta Jesús Carreras del uso para representar navegación en Tipos de Breadcrumbs, o cómo orientar al usuario, aunque personalmente no estoy consciente de haber encontrado otros ejemplos similares.

Referencias

Los logos y marcas que aparecen en esta página son propiedad de sus respectivos dueños. Las capturas de pantalla de sitios de terceros se presentan para efectos ilustrativos y no representan vinculación, aprobación ni otro tipo de relación.

Patrones y Diseño Web

General

En un Alertbox reciente, Nielsen evidencia la importancia de los estándares en el diseño web:

Users expect 77% of the simpler Web design elements to behave in a certain way. Unfortunately, confusion reigns for many higher-level design issues.

Los estándares se refieren a elementos o funcionalidades comunes utilizados frecuentemente y que por la exposición, uso y finalmente acostumbramiento, los usuarios terminan identificando y utilizando de modo espontáneo, asumiendo naturalmente sus características. Por el contrario, cuando un usuario espera que algo opere de un modo específico y esto no ocurre, se genera confusión y pérdida de confianza.

Estos estándares y convenciones constituyen patrones de diseño, que contribuyen a la generación de modelos mentales respecto a elementos específicos o incluso a tipos de sitios en general. La importancia de los patrones radica en la automatización del uso de las interfaces e interacciones, lo que simplica la realización de tareas y permite que el usuario se concentre en los aspectos más importantes, más que en resolver cómo resolver los problemas más básicos, como lograr completar correctamente una tarea específica.

Como indica Nielsen en el artículo antes citado, el uso de estándares o patrones garantiza que los usuarios se sentirán en control, sabrán qué esperar de una tarea particular, se sentirán cómodos y utilizarán de un modo más apropiado un sitio web.

La lógica detrás de un patrón de interacción está dada por la construcción de modelos mentales, que nos permiten identificar y reconocer fácilmente aquellos elementos que hemos aprendido y asociado a través de la experiencia. En la medida que este proceso se concreta, se eliminan una serie de factores innecesarios, asociados a procesos congnitivos que se traducen en que nos enfrentamos a esquemas similares, conocidos, de resolver un problema. Este proceso nos permite pasar de un mecanismo que podría tomas algunos segundos, a un reconocimiento que ocurre en fracciones de segundos. Esto no es irrelevente si pensamos en que estos segundos de diferencia, y la calidad de la experiencia que ellos constituyen, tienen una relación directa con el éxito de una venta en linea, el envío correcto de un mensaje de contacto para un potencial negocio, la venta de una suscripción para un medio de noticias, etc.

Los patrones en el diseño web son precisamente uno de los aspectos que me interesa cubrir y explorar en EFH. Si el tiempo me acompaña, espero pronto comenzar a publicar temas relacionados con estos patrones. Mientran eso ocurre, los dejo con un conjunto interesante de sitios dedicados a la exploración de patrones en el web:

CSS y Semántica

General

Uno de los aspectos más importantes de la separación de contenido y presentación mediante el uso correcto de HTML, es la descripción semántica del contenido mediante elementos con valor propio. De este modo el contenido gana una nueva dimensión.

El uso apropiado de HTML para marcar los contenidos nos permite asignarle un valor especial a cada elemento, que lo contextualiza, le asigna jerarquía y lo describe. Un ejemplo típico es el de los títulos: el apropiado uso de h1 nos indica explícitamente que lo que está contenido en este elemento es un título de primer nivel, que la página trata sobre este tema. Luego, un h2 nos dirá que este contenido es importante, aunque no tanto como el h1. Así, prácticamente todos los elementos presentes ya en XHTML tienen un valor semántico específico.

En este contexto, CSS nos permite modificar la apariencia de cada elemento, sin necesidad de contaminar el contenido con elementos presentacionales. Esto lo hacemos mediante una serie de recursos, aunque los más comunes por el soporte existente actualmente son los siguientes:

  • Selectores de elementos
  • Selectores contextuales
  • Selectores de ID
  • Selectores de clases

La forma más pura de modificar la presentación sin alterar en lo más mínimo el HTML es a través de los selectores de elementos. Para especificar reglas para el cuerpo del documento, por ejemplo los márgenes, usaremos body { margin: 10px; }.

Los selectores contextuales nos permitirán referirnos a elementos según su ubicación o contexto. Por ejemplo, para modificar el color a los vínculos que se encuentren exclusivamente dentro de un párrafo, usaremos:p a { color: #0000FF; }

Un elemento que declare el atributo id podrá ser referenciado mediante el valor de éste. Por ejemplo, un div id="menu" será afectado por una regla como #menu { display: block; }.

Es común que utilicemos el atributo id para identificar de modo único a un elemento dentro de un documento y esto es totalmente legítimo. Pero cuando comenzamos a hablar del último recurso que mencionamos antes, el atributo class, nos acercamos a tres de los problemas más comunes al trabajar con CSS. Me refiero primero a su uso para reemplazar la función de elementos legítimos de HTML. Un ejemplo clásico es usar engendros como <p class="titulo">. Esto es un error serio porque al reemplazar la función de un elemento perfectamente legítimo, como h1, por p class="titulo", estamos perdiendo la calidad semántica inherente al elemento h1: p class="titulo" no significa nada más que esto es un párrafo, no se entiende de ningún modo que tratamos de crear un título, en consecuencia, esto afectará a los robots y a los indexadores de los buscadores como Google que no podrán comprender la supuesta estructura que acabamos de crear. Esto finalmente nos creará problemas de indexación y malos resultados en los buscadores.

El segundo problema común que se comete al usar CSS es usar clases con un valor descriptivo visual específico, como class="izquierda", class="verde" o class="grande". El error aquí se produce porque aún no se logra generar la separación mental entre contenido y presentación. Las clases deberían llamarse según la función o contenido que describen. Si por class="izquierda" nos referimos a un grupo de vínculos que mostraremos como una columna a la izquierda, como un menú de navegación contextual o secundario, entonces usemos class="menu-navegacion". El problema práctico fundamental que ocurre en estos casos es que cuando nos enfrentemos a un rediseño de la presentación del sitio, es muy posible que el elemento con class="izquierda" termine arriba, abajo o a la derecha y la clase no tenga ninguna relación con el nuevo diseño.

Finalmente, el otro problema común es la clasitis, o la utilización en exceso de clases. En muchos casos se recurre a un uso exagerado de clases cuando es perfectamente posible utilizar selectores contextuales, de elementos o una combinación de selectores que no alteren el HTML. Nuevamente es necesario recordar que CSS debería utilizarse para separar la presentación del contenido. Con el soporte actual de selectores en los browsers más utilizados (si aún no queda claro, me refiero a IE), tarde o temprano recurriremos al uso de alguna clase que con un soporte completo de CSS sería innecesario usar. Pero la idea es reducir al mínimo la intervención del HTML. Para esto, una buena planificación de la estructura de nuestros documentos es esencial.

Hemos cubierto algunos de los problemas más comunes en el uso de CSS que de un modo u otro afectan al HTML de un documento y con esto al valor semántico de sus elementos. Para quienes ya han dado el paso de asumir el uso de estándares con la combinación de HTML y CSS, espero que estos detalles contribuyan a mejorar la estructuración de los documentos con todos los beneficios que esto conlleva. Para quienes están comenzando el camino, bienvenidos, espero que esto les ayude a evitar algunos de los problemas más frecuentes.

El Tamaño es Relativo: Ems

General

En una nota anterior comenté sobre las unidades de medida para fuentes en CSS. En esta oportunidad profundizaremos el tema refiriéndonos particularmente a una unidad, tal vez la menos conocida del grupo: ems.

Cuando se plantea el tema de cómo definir los tamaños del texto usando CSS varias cosas entran en juego. En primer lugar las consideraciones de usabilidad, en relación a la legibilidad del texto y la posibilidad de los usuarios de controlar el tamaño de despliegue para ajustarlo a sus necesidades. Por otro lado, el control sobre el diseño y presentación del sitio, normalmente defendido a dentelladas por los diseñadores.

Poniendo las cosas en perspectiva, lo primero que debemos entender, es que las necesidades del usuario son un requerimiento y no un elemento optativo en el desarrollo de un sitio. La usabilidad y accesibilidad son demandas del usuario y nosotros debemos oirlas.

El diseño debe estar al servicio de estos requerimientos. Punto.

Estas dos perspectivas no son necesariamente contradictorias, y es posible crear sitios accesibles, usables y estéticamente agradables. En esto el control y conocimiento de las herramientas disponibles ayuda mucho, y CSS juega una parte importante.

Con CSS podemos lograr textos con tamaños relativos, es decir, no fijos, modificables por los usuarios utilizando los controles normales del browser (las opciones Text Zoom o Text Size dependiendo del browser). Para ello contamos con tres unidades de medida definidas como relativas:

em
En la práctica, el tamaño por omisión definido en las preferencias del browser. La definición real de un em es el ancho del caracter m según el tamaño de texto actualmente en uso (activo). Esto normalmente se refiere al tamaño del elemento padre, el que contiene a aquél al que nos estamos refiriendo.
ex
ex se refiere a la altura del caracter x respecto al tamaño de texto activo.
px
Para sorpresa de muchos, se considera al píxel como una unidad de medida relativa, esto respecto a diversos dispositivos de visualización. Por ejemplo, un píxel en un PC de escritorio no será del mismo tamaño que en una Palm. Incluso será de tamaño diverso en distintos tipos de monitores.
%
Pese a no estar directamente asociado a los elementos anteriores como unidad de medida, el porcentaje se relaciona siempre con otros valores, como por ejemplo, píxeles. Al definir un porcentaje, se necesita conocer un valor de referencia, por ejemplo, el 10% de 125 píxeles.

Lo que hace especial a em lo podemos resumir en la siguiente lista:

  • se trata de una unidad relativa, que se escala proporcionalmente
  • que no depende directamente de otros elementos, como los porcentajes
  • que no es exclusivo para uso en un medio particular, como pt o px
  • que permite un total control al usuario

El problema sobre el control del diseño persistirá si insistimos en desarrollar diseños que requieran de precisión absoluta. La solución es diseñar tomando en cuenta estos factores, y teniendo consciencia de que finalmente y en condiciones más o menos extremas, para un usuario (y para nosotros como responsables de un sitio) es preferible ser capaces de acceder a un contenido, que de ver un diseño agradable, pero quedar impedido de leer la información a la que supuestamente sirve.

Texto y Unidades de Medida en CSS

General

Juan Carlos escribe una nota bien documentada, como es usual, sobre tipografía en el web. Su objetivo es tratar de entender las razones detrás del uso de fuentes con o sin serif, pero un comentario secundario capturó mi atención y no puedo evitar el entrar en detalles sobre esto.

De momento, aunque con poca base científica detrás, yo sigo recomendando escribir el cuerpo de los textos más o menos largos en letra sans serif, preferiblemente Verdana o Arial, y en un tamaño de 12 puntos (mejor puntos que pixels, pues los puntos permiten al usuario modificar fácilmente el tamaño del texto).

Evidentemente lo que ha hecho que mis alarmas suenen es la recomendación de usar puntos por sobre otras unidades de medida. Desde hace bastante tiempo que el tema de las unidades de medida para textos se viene discutiendo con bastante pasión en los círculos de die-hards de CSS. En resumen este asunto se puede resumir en lo siguiente, al menos desde mi perspectiva:

  • pt (puntos) es una unidad de medida eminentemente (tipo)gráfica, sin embargo no es apropiada para la pantalla, por varias razones, entre ellas el hecho de que no es proporcional, pese a que browsers modernos realicen un escalamiento proporcional (Mozilla, Opera). Adicionalmente, un punto no siempre es exactamente equivalente a un píxel: en Windows un punto se traduce a 1.3 píxeles y en Mac el equivalente es uno a uno, por lo que los resultados en diversas plataformas son imprecisos. En conclusión, es mejor utilizar esta unidad de medida para especificar hojas de estilo especiales para impresión.
  • px (píxeles) es una unidad de medida absoluta y mapeada directamente a la resolución del monitor. Si bien es posible (y aconsejable) escalarla, IE no es capaz de hacerlo, al menos hasta la versión 6.
  • em es una medida inherentemente tipográfica y proporcional, y es la más apropiada para la pantalla.
  • % (porcentaje) es una unidad de medida relativa que se ajusta perfectamente al uso en monitor, pero que puede llevar a ciertas impresiciones conceptuales. Prefiero utilizar porcentajes para especificar bloques en lugar de textos.

Para sostener estos argumentos y comprobar cómo se tratan las distintas unidades de medida de texto he publicado una página de prueba con texto en puntos, píxeles, ems y porcentajes. Para nadie será sorpresa que Mozilla maneja las unidades de medida de manera formidable, escalando cada una de ellas de modo apropiado. En IE, en cambio, puntos y pixeles no son escalables.

Modelos Mentales y Aplicaciones Web

General

modelomentalweb

Ventana de diálogo para guardar archivos en Mozilla luego de presionar Control+S. Atrás, formulario de edición de contenidos de WordPress.

Indefectiblemente cada vez que estoy concentrado editando o generando contenido en alguna aplicación web como el CMS que soporta este sitio, WordPress,o cualquier otro, tengo el reflejo natural de presionarControl+S para guardar los contenidos. Naturalmente esto activa la función Guardar Página del navegador (Mozilla en mi caso) en lugar de guardar aquéllo que estoy elaborando. Este es un condicionamiento producto de años de trabajo digital, en que he aprendido por la fuerza a proteger mi trabajo de potenciales problemas que terminen en la pérdida de horas de dedicación. Creo que a todos nos ha pasado.

El problema es que el modelo mental que formamos para trabajar en las aplicaciones tradicionales de escritorio, con interfaces bastante estandarizadas, no se aplican al entorno web. Sin embargo, necesitamos guardar o registrar nuestro trabajo o las selecciones que hayamos realizado, la configuración que hemos modificado, etc. Aquí, no obstante, el modelo es otro: debo recordar que estoy trabajando en un formulario web y que cualquier acción debe ser procesada por un script en el servidor, llamado mediante botones más o menos reconocibles, dependiendo del diseño único de cada aplicación web.

Aquí quedan expuestos claramente dos problemas que debemos tener muy claros al desarrollar interacciones en la plataforma que nos ofrece el web:

  1. Necesitamos dejar muy en claro, de modo explícito, que este es un medio diferente, con reglas propias.
  2. Debemos ser claros, consistentes y establecer un modelo que resulte en un aprendizaje rápido y fácil para el usuario: no debemos inducir a errores al usuario.

Esto que acabo de plantear no es algo nuevo, pero me comenzó a dar vueltas en la cabeza desde que comencé a publicar este weblog y me ha hecho replantear o repensar algunas cosas que daba por sentado. Y si me sucede a mí, de seguro que no soy el único. El asunto de fondo es, en consecuencia, cómo resolver la ambigüedad y partucularidad del formato que nos ofrece el web para realizar tareas que en el contexto familiar de las aplicaciones de escritorio nos resulta a esta altura natural.

No pretendo tener una respuesta, pero tengo la pregunta. Volveré al tema en la medida que lo elabore un poco más.

Diseño de las Cosas Cotidianas

General

Desde hace un par de meses que estaba en la lista de espera de mis lecturas el libro de Donald Norman The Design of Everyday Things. Finalmente comencé a leerlo y la espera no ha sido en vano. Ya desde el principio me encontré con una anécdota que vale mencionar.

design-of-everyday-things-book-cover

Portada de El Diseño de las Cosas Cotidianas con su título actual.

Cuenta Norman que originalmente el libro se llamó La Psicología de las Cosas Cotidianas, pero su editor le hizo notar que la palabra psicología hacía que en las librerías y bibliotecas éste se catalogara junto a los libros de psicología en lugar de aquéllos relacionados con interacción humano/máquina. Norman se dedicó a conversar con bibliotecarios y personal de librerías y comprobó la situación.

La anécdota de esto es que incluso él, que había escrito un libro sobre el diseño centrado en el usuario, había cometido un error considerable: no pensar en sus lectores, sino en sus colegas académicos, a quienes el título evidentemente complacía. Fue entonces que decidió cambiar el nombre en futuras ediciones a El Diseño de las Cosas Cotidianas.

Para sumar a la anécdota, es posible encontrar copias de ambas ediciones en Amazon: la primera versión, La Psicología de las Cosas Cotidianas y la segunda, El Diseño de las Cosas Cotidianas.

Cito la anécdota de Norman no como un acto de autoindulgencia sino, por el contrario, como algo a tener en cuenta, un recordatorio de que hasta en las cosas más simples, no debemos olvidar al usuario o destinatario final.

Más comentarios sobre el libro en cuanto avance la lectura.

Citas en HTML

General

HTML provee de un conjunto de elementos estructurales para definir citas. Una cita, según su acepción como mención es:

Recuerdo o memoria que se hace de una persona o cosa, nombrándola, contándola o refiriéndola.

Estructuralmente podemos definir tres tipos de citas:

  • Un bloque extenso de texto referido desde algún texto, publicación o cualquier otra fuente externa
  • Una referencia breve de un contenido de una fuente externa
  • Una referencia a otras fuentes, sin citar necesariamente contenidos específicos

Estos tres tipos de referencia tienen su representación en HTML en los elementos blockquote, q y cite respectivamente.

Uno de los aspectos interesantes de estos elementos es el hecho de que el contenido que definen gana un valor semántico importante: cualquier procesador automatizado o cualquier persona que lea el código reconoce que estas estructuras se refieren a un contenido que está siendo referenciado. Es decir, reconoce el sentido y relación de este contenido respecto al documento.

Más aún, podemos utilizar el atributo cite para blockquote y q para indicar la fuente de destino en la forma de una URI. Es importante no confundir el atributo cite, propio de los elementos blockquote y q, con el elemento cite.

El ejemplo de la definición de la palabra cita que aparece poco más arriba, utiliza blockquote junto con el atributo cite para indicar la definición en el sitio de la RAE.

Una distinción más sutil es la que marca la diferencia entre los elementos q y cite. q, así como blockquote definen un contenido extraído de una fuente externa, sólo que en el primero se trata de un texto breve, contenido dentro de un párrafo u otro elemento de bloque. cite, en tanto, tiene como objetivo el definir una referencia, o más bien la fuente de una referencia. Un ejemplo de esto es:

El elemento cite está definido en la sección de Texto Estructurado de la Especificación de HTML 4.01.

Estos elementos permiten enriquecer el valor semántico de los contenidos, en tanto que al identificarlos según su estructura podemos presentarlos apropiadamente usando CSS.